Résoudre les problèmes de surveillance des ordinateurs UNIX et Linux

System Center - Operations Manager fournit une surveillance des ordinateurs UNIX et Linux similaires à la surveillance des ordinateurs Windows. Vous pouvez surveiller l’intégrité et les performances, obtenir des rapports, exécuter des tâches et mettre en place des instruments de surveillance personnalisés.

Vous pouvez analyser les aspects suivants des ordinateurs UNIX et Linux :

• Services et applications

• Système de fichiers, espace disque, espace d'échange, mémoire système

• Interfaces réseau

• Processus et attributs principaux

• Configurations clés

Avant de pouvoir surveiller les ordinateurs UNIX et Linux, vous devez effectuer les étapes suivantes :

1. Importez des packs d’administration en téléchargeant les dernières versions à partir du Centre de téléchargement Microsoft.
2. Créez un pool de ressources dédié pour la surveillance des ordinateurs UNIX et Linux.
3. Configurez les certificats pour chaque serveur d’administration dans le pool.
4. Créez et configurez des comptes d’identification.
5. Installez l’agent sur UNIX et Linux à l’aide de l’Assistant Découverte.

Après avoir effectué les étapes ci-dessus et détecté et déployé l’agent sur un ou plusieurs ordinateurs UNIX et Linux, vous devez vérifier qu’ils sont surveillés correctement. Une fois qu’un agent est déployé, les comptes d’identification sont utilisés pour effectuer des découvertes en cours d’exécution à l’aide des règles de découverte applicables, puis commencer la surveillance. Après plusieurs minutes, sous l’espace de travail Administration, accédez à Gestion des appareils/ordinateurs UNIX/Linux et vérifiez que les ordinateurs ne sont pas répertoriés comme inconnus. Ils doivent être découverts et montrer la version spécifique du système d’exploitation et de la distribution.

Par défaut, Operations Manager surveille les objets de système d’exploitation suivants :

• Système d’exploitation
• Disque logique
• Adaptateurs réseau

Vous pouvez fournir des fonctionnalités d'analyse et d'interaction supplémentaires avec vos ordinateurs UNIX et Linux gérés en utilisant les modèles de pack d'analyse UNIX et Linux. Pour plus d'informations, consultez UNIX or Linux Log File (Fichier journal UNIX ou Linux) et UNIX or Linux Process (Processus UNIX ou Linux) dans le Guide de création.

Résoudre les problèmes de supervision UNIX et Linux

La section suivante fournit des informations sur les problèmes qui peuvent survenir lors de la surveillance des ordinateurs UNIX et Linux dans Operations Manager.

Message d’erreur de signature de certificat

Lors de l'installation d'agents UNIX/Linux, vous pouvez voir l'erreur suivante.

Event Type: Error  
Event Source: Cross Platform Modules  
Event Category: None  
Event ID: 256  
Date: 4/1/2009  
Time: 4:02:27 PM  
User: N/A  
Computer: COMPUTER1  
Description: Unexpected ScxCertLibException: Can't decode from base64  
; input data is:  

Cette erreur se produit lorsque le module de signature de certificats est appelé, mais que le certificat est vide. Cette erreur peut être provoquée par une panne de connexion SSH au système distant.

Si vous voyez cette erreur, procédez comme suit :

1. Vérifiez que le démon SSH sur l’hôte distant est en cours d’exécution.

2. Vérifiez que vous pouvez ouvrir une session SSH avec l’hôte distant à l’aide des informations d’identification spécifiées dans l’Assistant Découverte.

3. Vérifiez que les informations d’identification spécifiées dans l’Assistant Découverte disposent des privilèges requis pour la découverte. Pour plus d’informations, consultez Informations d’identification que vous devez avoir pour accéder aux ordinateurs UNIX et Linux.

Le nom du certificat et le nom d’hôte ne correspondent pas

Le nom commun (CN) utilisé dans le certificat doit correspondre au nom de domaine complet (FQDN) qui est résolu par Operations Manager. Si le CN ne correspond pas, l’erreur suivante s’affiche lorsque vous exécutez l’Assistant Découverte :

The SSL certificate contains a common name (CN) that doesn't match the hostname  

Vous pouvez afficher les détails de base du certificat sur l'ordinateur UNIX ou Linux en entrant la commande suivante :

openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates  

Lorsque vous effectuez cette opération, vous verrez une sortie similaire à ce qui suit :

subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name  
issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name  
notBefore=Mar 25 05:21:18 2008 GMT  
notAfter=Mar 20 05:21:18 2029 GMT  

Validez les noms d'hôte et les dates et assurez-vous qu'ils correspondent au nom résolu par le serveur d'administration Operations Manager.

Si les noms d’hôte ne correspondent pas, utilisez l’une des actions suivantes pour résoudre le problème :

• Si le nom d'hôte UNIX ou Linux est correct mais que le serveur d'administration Operations Manager le résout de façon incorrecte, modifiez l'entrée DNS pour correspondre au FQDN correct ou ajoutez une entrée au fichier d'hôte sur le serveur Operations Manager.

• Si le nom d'hôte UNIX ou Linux est incorrect, effectuez l'une des opérations suivantes :

  • Indiquez le nom d'hôte correct sur l'hôte UNIX ou Linux et créez un nouveau certificat.

  • Créez un nouveau certificat avec le nom d'hôte de votre choix.

Modifiez le nom sur le certificat :

Si le certificat a été créé avec un nom incorrect, vous pouvez modifier le nom d'hôte et recréer le certificat et la clé privée. Pour ce faire, exécutez la commande suivante sur l'ordinateur UNIX ou Linux :

/opt/microsoft/scx/bin/tools/scxsslconfig -f -v  

L’option -f force les fichiers dans /etc/opt/microsoft/scx/ssl à remplacer.

Vous pouvez également modifier le nom d’hôte et le nom de domaine sur le certificat à l’aide des commutateurs -h et -d , comme dans l’exemple suivant :

/opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>  

Redémarrez l’agent en exécutant la commande suivante :

/opt/microsoft/scx/bin/tools/scxadmin -restart  

Ajoutez une entrée au fichier hosts :

Si le nom de domaine complet n’est pas dans le DNS inverse, vous pouvez ajouter une entrée au fichier hosts situé sur le serveur d’administration pour fournir la résolution de noms. Le fichier hosts se trouve dans le dossier Windows\System32\Drivers\etc. Une entrée dans le fichier Hosts est une combinaison de l'adresse IP et du nom de domaine complet (FQDN).

Par exemple, pour ajouter une entrée pour l’hôte nommé newhostname.newdomain.name avec une adresse IP de 192.168.1.1, ajoutez ce qui suit à la fin du fichier hosts :

192.168.1.1      newhostname.newdomain.name  

Problème lié au pack d’administration

Le paramètre ExecuteCommand ne prend pas en charge les opérateurs pipeline ou les alias

Lorsque vous utilisez un alias ou un opérateur de pipeline avec le paramètre ExecuteCommand , la commande échoue. Le paramètre ExecuteCommand ne prend pas en charge l’opérateur de pipeline, les alias et la syntaxe propre à l’interpréteur de commandes.

Dans les packs d’administration System Center Operations Manager conçus pour gérer les ordinateurs UNIX et Linux, le paramètre ExecuteCommand ne démarre pas un processus d’interpréteur de commandes, ce qui entraîne l’échec de l’action personnalisée.

Pour chacun des types d’actions personnalisés suivants, vous spécifiez comment les arguments de commande sont appelés à l’aide du paramètre ExecuteCommand ou du paramètre ExecuteShellCommand :

• Microsoft.Unix.WSMan.Invoke.ProbeAction

• Microsoft.Unix.WSMan.Invoke.WriteAction

• Microsoft.Unix.WSMan.Invoke.Privileged.ProbeAction

• Microsoft.Unix.WSMan.Invoke.Privileged.WriteAction

Le paramètre ExecuteCommand transmet les arguments de ligne de commande à la console sans démarrer un processus d’interpréteur de commandes.

Le paramètre ExecuteShellCommand transmet les arguments de commande à un processus d’interpréteur de commandes à l’aide de l’interpréteur de commandes par défaut de l’utilisateur. Cet interpréteur de commandes prend en charge la syntaxe spécifique au pipeline, aux alias et à l’interpréteur de commandes.

Remarque

Le paramètre ExecuteShellCommand utilise l’interpréteur de commandes par défaut de l’utilisateur qui exécute la commande. Si vous avez besoin d’un interpréteur de commandes spécifique, utilisez le paramètre ExecuteCommand et préfixez les arguments de commande avec l’interpréteur de commandes requis.

Les exemples suivants montrent comment utiliser les paramètres ExecuteCommand et ExecuteShellCommand :

• Pour transmettre les arguments de ligne de commande à la console sans démarrer un processus de shell :

  <p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> service syslog status </p:Command> <p:timeout>10</p:timeout> </p:ExecuteCommand_INPUT>

• Pour transmettre les arguments de ligne de commande à un processus de shell qui fait référence à un shell explicite :

  <p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> /bin/sh ps -ef syslog | grep -v grep </p:Command> <p:timeout>10</p:timeout> </p:ExecuteCommand_INPUT>

• Pour transmettre les arguments de commande à un processus de shell qui utilise le shell par défaut de l'utilisateur :

  <p:ExecuteShellCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> uptime |&nbsp; awk '{print $10}' |awk -F"," '{print $1}' </p:Command> <p:timeout>10</p:timeout> </p:ExecuteShellCommand_INPUT>

Journalisation et débogage

Cette section explique comment activer les outils de journalisation et de débogage pour résoudre les problèmes liés à la surveillance des ordinateurs UNIX et Linux.

Remarque

Vous pouvez modifier les paramètres au niveau du journal sans redémarrer l’agent. Plus d’informations

Activer la journalisation des modules Operations Manager

Les agents Operations Manager pour UNIX et Linux gèrent plusieurs fichiers journaux qui peuvent être utiles lors de la résolution des problèmes du client. Ces fichiers journaux se trouvent sur l’ordinateur UNIX ou Linux géré. Le niveau de journalisation des fichiers journaux de l’agent peut être configuré en fonction des besoins. La journalisation plus détaillée peut être utile pour diagnostiquer un problème. Pour une opération normale, les niveaux de journal ne doivent pas être définis sur une valeur plus détaillée que les configurations par défaut (intermédiaire) afin d’éviter une croissance excessive du fichier journal.

Remarque

Les appels effectués en dehors de Gestion à distance de Windows (WinRM) sont effectués à l'aide de SSH/SFTP. Ces composants s'appuient sur un mécanisme de journalisation distinct à Operations Manager.

Remarque

Le niveau de journalisation du fichier journal omiserver.log ne peut pas être modifié par défaut dans cette version des agents Operations Manager pour UNIX et Linux.

1. Créez un fichier vide nommé EnableOpsmgrModuleLogging dans le répertoire Temp pour le compte d’utilisateur appelant ces modules en tapant à la ligne de commande ou à l’invite PowerShell :

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

   New-Item "$env:windir\TEMP\EnableOpsMgrModuleLogging"
   

   Remarque

   En règle générale, il s’agit du compte SYSTEM qui effectue les appels, et C :\Windows\Temp est le dossier temporaire SYSTEM par défaut.

2. Après la création du fichier vide, Operations Manager commence immédiatement à journaliser l’activité SSH et certificat dans le répertoire Temp. Scripts qui appellent le journal des modules SSH vers <Scriptname.vbs>.log. Les autres modules ont leurs propres journaux.

Dans certains cas, il peut être nécessaire de redémarrer HealthService pour que la journalisation EnableOpsmgrModuleLogging prenne effet.

Activer la journalisation sur l’agent UNIX

Ces journaux signaleront les actions de l'agent UNIX. S’il existe un problème avec les données retournées à Operations Manager, recherchez ce journal. La commande scxadmin vous permet de définir la quantité d’informations journalisées. La syntaxe pour cette commande est :

scxadmin -log-set [all|cimom|provider] {verbose|intermediate|errors}

Le tableau suivant répertorie les valeurs que vous pouvez affecter aux paramètres :

Niveau	Description
Erreurs	Journalise uniquement les messages de type Avertissement ou Erreur .
Intermédiaire	Informations de journal, avertissement et messages d’erreur.
Commentaires	Journalise les messages de type Info, Avertissementet Erreur avec la journalisation du débogage. Notez que ce niveau de journalisation peut entraîner la croissance rapide de la taille des fichiers journaux. Il est recommandé d’utiliser cette option uniquement pendant de courtes périodes pour diagnostiquer un problème spécifique.

Utiliser DebugView pour résoudre les problèmes de détection

DebugView est une méthode alternative pour EnableOpsmgrModuleLogging pour résoudre les problèmes de détection.

1. Téléchargez DebugView à partir de : https://go.microsoft.comfwlink/?Linkid=129486.

2. Lancez DebugView sur le serveur d'administration effectuant la détection.

3. Démarrez la détection des agents UNIX. Vous devez commencer à voir des résultats dans vos fenêtres DebugView.

4. DebugView présentera une description étape par étape du processus de l'Assistant Détection. C'est souvent la méthode la plus rapide pour résoudre les problèmes de détection.

Activer la journalisation d’Operations Manager pour Windows Remote Management

Cette méthode de suivi détaillé permet de voir les requêtes de Gestion à distance de Windows (WinRM) utilisées par Operations Manager pour collecter des données de l'agent. Si vous pensez qu’il existe un problème avec la connexion WinRM, ce journal fournit des informations détaillées qui peuvent vous aider à résoudre les problèmes.

1. Sur le serveur d'administration qui analyse l'agent UNIX ou Linux, ouvrez une invite de commande.

2. Entrez les commandes suivantes à l’invite de commandes :

   1. cd C:\Program Files\Microsoft System Center\Operations Manager\Tools

   2. StopTracing.cmd

   3. StartTracing.cmd VER

3. Reproduisez le problème d'échec dans Operations Manager.

4. Entrez les commandes suivantes à l’invite de commandes :

   1. StopTracing.cmd

   2. FormatTracing.cmd

5. Recherchez WS-Man dans le fichier TracingGuidsNative.log.

Remarque

WinRM est également appelé WS-Management (WS-Man).

Remarque

La commande FormatTracing ouvre une fenêtre de l’Explorateur Windows affichant le C:\Windows\Logs\OpsMgrTrace répertoire. Le fichier TracingGuidsNative.log se trouve dans ce répertoire.

Gérer les fichiers journaux UNIX et Linux

Les agents Operations Manager pour UNIX et Linux ne limitent pas la taille des fichiers journaux de l’agent. Pour contrôler la taille maximale des fichiers journaux, implémentez un processus de gestion des fichiers journaux. Par exemple, l’utilitaire standard logrotate est disponible sur de nombreux systèmes d’exploitation UNIX et Linux. Vous pouvez configurer l’utilitaire logrotate pour contrôler les fichiers journaux utilisés par les agents Operations Manager pour UNIX ou Linux. Après rotation ou modification des fichiers journaux de l’agent, ce dernier doit être averti de la rotation appliquée aux journaux pour pouvoir reprendre la journalisation. La commande scxadmin peut être utilisée avec le paramètre -log-rotate selon la syntaxe suivante :

scxadmin -log-rotate all

Exemple de fichier de configuration Logrotate

L’exemple suivant illustre un fichier de configuration pour faire pivoter les fichiers scx.log et omiserver.log avec l’utilitaire logrotate de Linux. En règle générale, logrotate s’exécute en tant que travail planifié (avec crond) et agit sur les fichiers de configuration trouvés dans /etc/logrotate.d. Pour tester et utiliser ce fichier de configuration, modifiez la configuration pour qu’elle soit appropriée pour votre environnement, puis liez ou enregistrez le fichier dans /etc/logrotate.d.

#opsmgr.lr  

#Rotate scx.log  
#Weekly rotation, retain four weeks of compressed logs  
#Invoke scxadmin -log-rotate to resume logging after rotation  

/var/opt/microsoft/scx/log/scx.log {  
rotate 4  
weekly  
compress  
missingok  
notifempty  
postrotate  

/usr/sbin/scxadmin -log-rotate all  
endscript  
}

#Rotate scx.log for the monitoring user account named: monuser  
#Weekly rotation, retain four weeks of compressed logs  
#Invoke scxadmin -log-rotate to resume logging after rotation  

/var/opt/microsoft/scx/log/monuser/scx.log {  
rotate 4  
weekly  
compress  
missingok  
notifempty  
postrotate  

/usr/sbin/scxadmin -log-rotate all
endscript  
}  

#Optionally, rotate omiserver.log. This requires that OMI be stopped and started to prevent  
#impact to logging. Monthly rotation, retain two weeks of compressed logs  
#Uncomment these lines if rotation of omiserver.log is needed  

#/var/opt/microsoft/scx/log/omiserver.log{  
#        rotate 2  
#        monthly  
#        compress  
#        missingok  
#        notifempty  
#        prerotate  
#        /usr/sbin/scxadmin -stop  
#        endscript  
#        postrotate  
#        /usr/sbin/scxadmin -start  
#        endscript\
#}  

Étapes suivantes

Pour obtenir des conseils supplémentaires pour résoudre les problèmes courants de déploiement d’agent, consultez la résolution des problèmes d’Operations Manager 2012 : Wiki de découverte de l’agent UNIX/Linux.