Surveillance des fichiers journaux Linux dans System Center Operations Manager

Vue d’ensemble de la configuration

La surveillance des fichiers journaux nécessite les étapes suivantes. Les informations détaillées sont fournies dans les sections suivantes :

Installer le pack d’administration de surveillance des journaux

Installez le pack d’administration Microsoft.Linux.Log.Monitoring pour activer la surveillance des fichiers journaux Linux.

Configurer la surveillance des fichiers journaux Linux

Pour configurer la surveillance des fichiers journaux Linux, procédez comme suit :

4. Créez les dossiers dans les chemins d’accès suivants avec les commandes ci-dessous :

   # Create omsagent.d folder
   mkdir -p /etc/opt/microsoft/omsagent/scom/conf/omsagent.d
   
   # Create certs folder
   mkdir /etc/opt/microsoft/omsagent/scom/certs
   
   # Create log folder
   mkdir -p /var/opt/microsoft/omsagent/scom/log
   
   # Create run folder
   mkdir /var/opt/microsoft/omsagent/scom/run
   
   # Create state folder
   mkdir /var/opt/microsoft/omsagent/scom/state
   
   # Create tmp folder
   mkdir /var/opt/microsoft/omsagent/scom/tmp
   
   # Create fluent-logging folder (used for log file position file, this location is flexible)
   mkdir -p /home/omsagent/fluent-logging
   

5. Définissez la propriété sur chacun des dossiers ci-dessus sur omsagent:omiusers:

   # Change owner of System Center Operations Manager folder
   chown omsagent:omiusers /etc/opt/microsoft/omsagent/scom
   
   # Change owner of log folder
   chown omsagent:omiusers /var/opt/microsoft/omsagent/scom/log
   
   # Change owner of run folder
   chown omsagent:omiusers /var/opt/microsoft/omsagent/scom/run
   
   # Change owner of state folder
   chown omsagent:omiusers /var/opt/microsoft/omsagent/scom/state
   
   # Change owner of tmp folder
   chown omsagent:omiusers /var/opt/microsoft/omsagent/scom/tmp
   
   # Change owner of fluent-logging folder (used for log file position file, this location is flexible)
   chown omsagent:omiusers /home/omsagent/fluent-logging
   

   

6. Créez des fichiers omsagent et omsconfig :

   # Create omsadmin.conf file
   touch /etc/opt/microsoft/omsagent/scom/conf/omsadmin.conf
   
   # Create omsagent.conf file
   touch /etc/opt/microsoft/omsagent/scom/conf/omsagent.conf
   

7. Définissez la propriété sur chacun des fichiers ci-dessus sur omsagent:omiusers:

   # Change owner of omsadmin.conf file
   chown omsagent:omiusers /etc/opt/microsoft/omsagent/scom/conf/omsadmin.conf
   
   # Change owner of omsagent.conf file
   chown omsagent:omiusers /etc/opt/microsoft/omsagent/scom/conf/omsagent.conf
   

8. Modifiez le fichier /etc/opt/microsoft/omsagent/scom/conf/omsadmin.confet ajoutez les informations suivantes après avoir modifié les informations mises en surbrillance.

   WORKSPACE_ID=scom
   System Center Operations Manager_ENDPOINT=https://<mark>\<MSFQDN\></mark>:8886
   MONITORING_ID={274F8D7B-DBCA-8FC3-1451-8DCD55092156}
   

9. Redémarrez OMSAgent :

   /opt/microsoft/omsagent/bin/service_control restart
   

10. Vérifiez l’état dans le journal omsagent :

    tail -100 /var/opt/microsoft/omsagent/scom/log/omsagent.log
    

Activer le service OMED

Activez le service OMED sur chaque serveur d’administration du pool de ressources, gérant les agents Linux.

Le service OMED collecte les événements de Fluentd et les convertit en événements Operations Manager. Vous importez un pack d’administration personnalisé, qui peut générer des alertes en fonction des événements reçus des serveurs Linux.

Vous pouvez activer le service OMED à partir de la console Opérateur ou manuellement sur le serveur d’administration ou le serveur de passerelle.

Ajouter une règle de pare-feu OMED

Pour activer la règle de pare-feu OMED, vous avez deux options : ajouter le port (TCP/8886) automatiquement via PowerShell ou manuellement.

Set-NetFirewallRule -DisplayName "System Center Operations Manager External DataSource Service" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8886

Attribuer un certificat client pour OMSAgent

Vous avez deux options lors de l’attribution du certificat client pour OMSAgent.

1. Lien vers le certificat signé à partir de l’agent OMI.
2. Générez manuellement un certificat client pour l’agent OMS.

Sélectionnez l’onglet requis pour les étapes à lier au certificat signé à partir de l’agent OMI ou générez manuellement un certificat client à partir de l’agent OMS :

Créer un fichier de configuration Fluentd

Vous configurez l’opération Fluentd à l’aide d’un fichier de configuration. Pour utiliser la surveillance des journaux, vous devez créer un fichier de configuration. Le fichier de configuration inclut des informations telles que le nom du fichier journal source, le chemin d’accès et les filtres pour définir les données à collecter.

Le fichier de configuration master Fluentd omsagent.conf se trouve dans /etc/opt/microsoft/omsagent/scom/conf/. Vous pouvez ajouter directement la configuration de surveillance des fichiers journaux à ce fichier, mais devez créer un fichier de configuration distinct pour mieux gérer les différents paramètres. Vous utilisez ensuite une @include directive dans le fichier maître pour inclure votre fichier personnalisé.

Par exemple, si vous avez créé logmonitoring.conf dans /etc/opt/microsoft/omsagent/scom/conf/omsagent.d, vous devez ajouter l’une des lignes suivantes au fichier omsagent.d :

# Include all configuration files
@include omsagent.d/*.conf

or

# Include single configuration file
@include omsagent.d/logmonitoring.conf

Pour plus d’informations sur les fichiers de configuration Fluentd, consultez la syntaxe des fichiers de configuration Fluentd.

Les sections suivantes décrivent les paramètres dans différentes directives du fichier de configuration qui sont uniques à la surveillance des fichiers journaux. Chacun inclut des exemples de paramètres que vous pouvez coller dans un fichier de configuration et modifier pour vos besoins.

Un exemple complet de fichier de configuration pour la surveillance des journaux est disponible pour vous permettre de passer en revue et d’évaluer avant de créer votre propre fichier.

Source

La directive Source définit la source des données que vous collectez, c’est-à-dire l’emplacement où vous définissez les détails de votre fichier journal. Fluentd récupère chaque enregistrement écrit dans la source et envoie un événement pour celui-ci dans le moteur de routage Fluentd. Spécifiez une balise ici dans cette directive. La balise est une chaîne utilisée comme directions pour le moteur de routage interne de Fluentd afin de mettre en corrélation différentes directives.

L’exemple suivant montre les enregistrements syslog collectés et étiquetés pour le traitement par Operations Manager.

<source>

    # Specifies input plugin. Tail is a fluentd input plugin - http://docs.fluentd.org/v0.12/articles/in\_tail
    type tail

    # Specify the log file path. Supports wild cards.
    path /var/log/syslog

    # Recommended so that Fluentd will record the position it last read into this file.
    pos_file /home/user1/fluent-test/demo_syslog.log.pos

    # Used to correlate the directives.
    tag System Center Operations Manager.log.syslog

    format /(?<message>.*)/

</source>

Filter

La directive de filtre a la même syntaxe que Match , mais permet un filtrage plus complexe des données à traiter. Les événements collectés doivent correspondre aux critères de tous les filtres à ajouter à la sortie.

Six plug-ins de filtre sont décrits ici pour la surveillance des fichiers journaux. Utilisez un ou plusieurs de ces filtres pour définir les événements que vous souhaitez collecter à partir de votre fichier journal.

• Correspondance simple : filter_System Center Operations Manager_simple_match
• Correspondance exclusive : filter_System Center Operations Manager_excl_match
• Corrélation répétée : filter_System Center Operations Manager_repeated_cor
• Correspondance corrélée : filter_System Center Operations Manager_cor_match
• Corrélation exclusive : filter_System Center Operations Manager_excl_correlation
• Convertisseur Operations Manager : filter_System Center Operations Manager_converter

Sélectionnez l’onglet requis pour copier le code du plug-in de filtre respectif :

<filter tag>

    type filter_System Center Operations Manager_simple_match
    regexp1 <key> <pattern>
    event_id1 <event ID>
    regexp2 <key> <pattern>
    event_id2 <event ID>
    .
    .
    .
    regexp20 <key> <pattern>
    event_id20 <event ID>
</filter>

<filter tag>
    type filter_System Center Operations Manager_excl_match
    regexp1 <key> <pattern1>
    regexp2 <key> <pattern2>
    event_id <event ID>
</filter>

<filter tag>
    type filter_System Center Operations Manager_repeated_cor
    regexp <key> <pattern>
    event_id <event ID>
    time_interval <interval in seconds>
    num_occurences <number of occurrences>
</filter>

<filter tag>
    type filter_System Center Operations Manager_cor_match
    regexp1 <key> <pattern1>
    regexp2 <key> <pattern2>
    event_id <event ID>
    time_interval <interval in seconds>
</filter>

<filter tag>
    type filter_System Center Operations Manager_excl_correlation
    regexp1 <key> <pattern1>
    regexp2 <key> <pattern2>
    event_id <event ID>
    time_interval <interval in seconds>
</filter>

<filter tag>
    type filter_System Center Operations Manager_converter
    event_id <event ID>
    event_desc <event description>
</filter>

Correspondance

La directive de correspondance définit comment traiter les événements collectés à partir de la source avec des balises correspondantes. Seuls les événements avec une balise correspondant au modèle sont envoyés à la destination de sortie. Lorsque plusieurs modèles sont répertoriés à l’intérieur d’une balise de correspondance , les événements peuvent correspondre à l’un des modèles répertoriés. Le paramètre type spécifie le type à utiliser pour ces événements.

Cet exemple traite les événements avec des balises correspondant à System Center Operations Manager.log. ** et System Center Operations Manager.alert (** correspond à zéro ou plusieurs parties de balise). Il spécifie le plug-in Out_System Center Operations Manager , qui permet aux événements d’être collectés par le pack d’administration Operations Manager.

<match System Center Operations Manager.log.** System Center Operations Manager.event>

    # Output plugin to use
     type out_System Center Operations Manager

    log_level trace
    num_threads 5

    # Size of the buffer chunk. If the top chunk exceeds this limit or the time limit flush_interval, a new empty chunk is pushed to the top of the
    queue and bottom chunk is written out.
    buffer_chunk_limit 5m
    flush_interval 15s

    # Specifies the buffer plugin to use.
    buffer_type file

    # Specifies the file path for buffer. Fluentd must have write access to this directory.
    buffer_path /var/opt/microsoft/omsagent/scom/state/out_System Center Operations Manager_common*.buffer

    # If queue length exceeds the specified limit, events are rejected.
    buffer_queue_limit 10

    # Control the buffer behavior when the queue becomes full: exception, block, drop_oldest_chunk
    buffer_queue_full_action drop_oldest_chunk

    # Number of times Fluentd will attempt to write the chunk if it fails.
    retry_limit 10

    # If the bottom chunk fails to be written out, it will remain in the queue and Fluentd will retry after waiting retry_wait seconds
    retry_wait 30s

    # The retry wait time doubles each time until max_retry_wait.
    max_retry_wait 9m

</match>

<match System Center Operations Manager.log.** System Center Operations Manager.event>
type out_System Center Operations Manager

max_retry_wait 9m
enable_server_auth false

</match>

Copier le fichier de configuration vers l’agent

Le fichier de configuration de Fluentd doit être copié dans /etc/opt/microsoft/omsagent/scom/conf/omsagent.d sur tous les ordinateurs Linux à superviser. Vous devez également ajouter une @include directive dans le fichier de configuration maître, comme décrit ci-dessus.

Redémarrer omsagent

Vous pouvez exécuter la commande suivante pour redémarrer omsagent :

/opt/microsoft/omsagent/bin/service_control restart

Vérifier l’état de l’espace de travail System Center Operations Manager

Exécutez la commande suivante pour vérifier l’espace de travail System Center Operations Manager sur OMSAgent :

sh /opt/microsoft/omsagent/bin/omsadmin.sh -l

Journal des événements pour system Center Operations Manager External DataSource Service

Le journal des événements du service OMED System Center est créé uniquement lorsqu’un événement est envoyé avec succès au service OMED (External DataSource Service) system Center Operations Manager.

Créer des règles et des moniteurs

Le pack d’administration Linux ne fournit pas de modules pour collecter des événements à partir de FluentD, le pack d’administration Linux est fourni avec l’agent Linux. Il s’agit du module fluentd de l’agent Linux et du service OMED sur le serveur de gestion et de passerelle qui fournit les fonctionnalités de surveillance améliorée des fichiers journaux.

Vous devez créer votre propre pack d’administration avec des règles et des moniteurs personnalisés qui utilisent le module Microsoft.Linux.OMED.EventDataSource pour collecter les événements à partir de Fluentd. N’oubliez pas que le nom de l’ordinateur dans l’événement envoyé via le journal des événements du service OMED System Center doit correspondre au nom de l’ordinateur dans votre vue Ordinateurs UNIX/Linux. Si le nom de l’ordinateur ne correspond pas, vous ne recevrez aucune alerte.

Le tableau suivant répertorie les paramètres de Microsoft.Linux.OMED.EventDataSource.