Surveillance des fichiers journaux Linux dans System Center Operations Manager

Remarque

System Center Operations Manager ne prend pas en charge la surveillance des fichiers journaux fluentD lors de la mise hors service de l’agent OMS prévue pour août 2024.

System Center Operations Manager a désormais amélioré les fonctionnalités de surveillance des fichiers journaux pour les serveurs Linux à l’aide de la dernière version de l’agent qui utilise Fluentd. Cette mise à jour fournit les améliorations suivantes sur la surveillance des fichiers journaux précédents :

• Caractères génériques dans le nom et le chemin d’accès du fichier journal.
• Nouveaux modèles de correspondance pour la recherche dans les journaux personnalisables, comme une correspondance simple, une correspondance exclusive, une correspondance corrélée, une corrélation répétée et une corrélation exclusive.
• Prise en charge des plug-ins Fluentd génériques publiés par la communauté Fluentd.

Fonctionnement de base

L’opération de base de la surveillance des fichiers journaux dans Linux comprend les étapes suivantes :

1. L’enregistrement est écrit dans un journal sur un agent Linux.
2. Fluentd collecte l’enregistrement et crée un événement sur la correspondance de modèle.
3. L’événement est envoyé au service OMED sur le serveur d’administration et connecté au journal des événements du service OMED System Center sur le serveur d’administration. (Le Le journal des événements du service OMED System Center est créé uniquement lorsqu’un événement a été envoyé avec succès à partir d’un agent Fluentd)
4. Les règles et les analyses d’un pack d’administration personnalisé collectent des événements et créent des alertes dans 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.

Remarque

Si l’agent OMS est configuré et que vous essayez de désinstaller l’agent UNIX et LINUX à partir de la console, le composant OMS ne sera pas désinstallé de l’agent.

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.

Activer le service OMED à partir de la console Opérateur

1. À partir de la console Opérateur, accédez à l’état des>serveurs d’administration Operations Manager>Management Server.>
2. Sélectionnez le serveur d’administration dans l’état serveurs d’administration.
3. Dans Tâches, sélectionnez Tâches>du service d’intégrité Activer system Center OMED Server.

Activer le service OMED manuellement

Vous avez deux options lors de l’activation manuelle du service OMED sur le serveur d’administration, automatiquement via PowerShell ou manuellement.

Définir automatiquement avec PowerShell

Exécutez la commande PowerShell suivante en tant qu’administrateur pour définir le service De source de données externe System Center Operations Manager pour démarrer automatiquement et démarrer l’exécution :

Set-Service -Name OMED -StartupType Automatic -Status Running

Définir manuellement avec services.msc

1. Sélectionnez Démarrer dans la zone Démarrer la recherche, entrez services.msc, puis appuyez sur Entrée.
2. Dans le volet d’informations, cliquez avec le bouton droit sur le service System Center Operations Manager External DataSource Service, puis sélectionnez Propriétés.
3. Dans Général, dans le type de démarrage, sélectionnez Automatique, puis OK.
4. Dans le volet d’informations, cliquez avec le bouton droit sur Service , puis sélectionnez Démarrer.

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.

Ajouter automatiquement une règle avec PowerShell

Procédez comme suit pour ajouter automatiquement une règle avec PowerShell :

La commande suivante vous permet d’ajouter automatiquement la règle de pare-feu :

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

Ajouter manuellement une règle avec le Pare-feu Windows

Procédez comme suit pour ajouter manuellement une règle avec le Pare-feu Windows :

1. Ouvrez le Pare-feu Windows Defender avec Advanced Security.
   1. Cliquez avec le bouton droit sur l’icône Windows dans la barre des tâches, puis sélectionnez Exécuter.
   2. Entrez dans la zone d’exécution : wf.msc puis cliquez sur OK.
2. Sélectionnez Règles de trafic entrant.
3. Cliquez avec le bouton droit sur Règles de trafic entrant et sélectionnez : Nouvelle règle...
4. Sélectionnez Port, cliquez sur Suivant.
5. Sélectionnez TCP et sélectionnez Ports locaux spécifiques :. Saisissez 8886.
6. Sélectionnez Autoriser la connexion, cliquez sur Suivant.
7. Sélectionnez les profils appropriés pour appliquer la règle de pare-feu (domaine, privé, public).
8. Entrez System Center Operations Manager External DataSource Servicedans la zone nom, puis sélectionnez Terminer.

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 :

Lier le certificat de l’agent OMI à l’agent OMS

1. Définissez la propriété sur le omi.pem fichier omsagent:omiuserset omikey.pem sur :

   # Change owner of System Center Operations Manager-cert.pem file
   chown omsagent:omiusers /etc/opt/microsoft/omsagent/scom/certs/scom-cert.pem
   
   # Change owner of System Center Operations Manager-key.pem file
   chown omsagent:omiusers /etc/opt/microsoft/omsagent/scom/certs/scom-key.pem
   

2. Exécutez la commande suivante sur votre ordinateur Linux pour définir le certificat client de l’agent OMS sur le certificat OMI (certificat d’agent Linux Operations Manager) :

   # Link file omi.pem to System Center Operations Manager-cert.pem
   ln -s /etc/opt/omi/ssl/omi.pem /etc/opt/microsoft/omsagent/scom/certs/scom-cert.pem
   
   # Link file omikey.pem to System Center Operations Manager-key.pem
   ln -s /etc/opt/omi/ssl/omikey.pem /etc/opt/microsoft/omsagent/scom/certs/scom-key.pem
   

Générer un certificat client pour l’agent OMS

Procédez comme suit pour générer un certificat client pour l’agent OMS :

1. Générez le certificat et la clé dans le dossier omsagent :

   # Generate Certificate to omsagent Folder
   /opt/microsoft/scx/bin/tools/scxsslconfig -c -g /etc/opt/microsoft/omsagent/scom/certs/
   

   Remarque

   Le nouveau certificat doit être signé par le serveur d’administration. Pour ce faire, copiez sur le serveur d’administration, signez le certificat à l’aide scxcertconfig -signde , puis recopiez-le vers l’agent Linux.

2. Renommez le certificat généré côté Linux :

   # Rename omi-host-server.domain.pem to scom-cert.pem
   mv omi-host-server.domain.pem scom-cert.pem
   
   # Rename omikey.pem to scom-key.pem
   mv omikey.pem scom-key.pem
   

3. Modifiez la propriété du fichier de certificat :

   # Change owner of the scom-cert file
   chown omsagent:omiusers /etc/opt/microsoft/omsagent/scom/certs/scom-cert.pem
   
   # Change owner of the scom-key file
   chown omsagent:omiusers /etc/opt/microsoft/omsagent/scom/certs/scom-key.pem
   

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 :

Correspondance simple

Prend jusqu’à 20 modèles d’entrée. Envoie un événement à Operations Manager chaque fois qu’un modèle est mis en correspondance.

<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>

Correspondance exclusive

Prend deux modèles d’entrée. Envoie un événement à Operations Manager lorsqu’un enregistrement unique correspond au modèle 1, mais ne correspond pas au modèle 2.

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

Corrélation répétée

Accepte trois entrées : un modèle, un intervalle de temps et un nombre d’occurrences. Lorsqu’une correspondance est trouvée pour le premier modèle, un minuteur démarre. Un événement est envoyé à Operations Manager si le modèle correspond au nombre spécifié de fois avant la fin du minuteur.

<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>

Correspondance corrélée

Prend trois entrées : deux modèles et un intervalle de temps. Lorsqu’une correspondance est trouvée pour le premier modèle, un minuteur démarre. Un événement est envoyé à Operations Manager s’il existe une correspondance pour le deuxième modèle avant la fin du minuteur.

<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>

Corrélation exclusive

Prend trois entrées : deux modèles et un intervalle de temps. Lorsqu’une correspondance est trouvée pour le premier modèle, un minuteur démarre. Un événement est envoyé à Operations Manager s’il n’y a aucune correspondance pour le deuxième modèle avant la fin du minuteur.

<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>

Convertisseur Operations Manager

Envoie un événement à Operations Manager pour tous les enregistrements qu’il reçoit. Envoie l’ID d’événement et la description spécifiés dans le cadre de l’événement.

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

Correspond à

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>

Remarque

Pour désactiver l’authentification du serveur sur les ordinateurs Linux qui utilisent la communication Fluentd, ajoutez un paramètre enable_server_auth false au plug-in Operations Manager pour Fluentd, par exemple :

<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

Remarque

Sur le serveur d’administration exécutant le service OMED, vérifiez que le pare-feu sur le port 8886 est ouvert et que le magasin de certificats des autorités de certification intermédiaires contient uniquement des autorités de certification intermédiaires.

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.

Paramètre	Type	Description
ComputerName	Chaîne	Obligatoire. Spécifie le nom de l’ordinateur Linux pour lequel les événements doivent être lus. Le paramètre ComputerName est le plus souvent passé au module à l’aide de la notation $Target, bien qu’il puisse être spécifié comme n’importe quelle chaîne. Ce module tente de lire les événements générés par l’ordinateur Linux donné.
ManagedEntityId	Chaîne	Obligatoire. Spécifie l’ID d’entité managée de l’entité surveillée. Le paramètre ManagedEntityId est le plus souvent passé au module à l’aide de $Target\Id$.
EventNumber	Integer	facultatif. Indique le numéro d’événement de l’événement à récupérer. Si cette option est omise, le module retourne tous les événements générés pour cet ordinateur et cette entité gérée

Étapes suivantes

• Pour créer une vue personnalisée pour passer en revue les données de surveillance à partir de votre pack d’administration de fichiers journaux personnalisé, consultez Utilisation des vues dans Operations Manager.

• Pour savoir comment examiner les problèmes identifiés par votre pack d’administration de fichiers journaux personnalisé, consultez l’affichage des alertes actives et des détails.