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

System Center - Operations Manager offre une surveillance des ordinateurs UNIX et Linux semblable à la surveillance des ordinateurs Windows. Vous pouvez surveiller l’intégrité et les performances, obtenir des rapports, exécuter des tâches et implémenter une instrumentation de surveillance personnalisée.

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écouvert 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 a été déployé, les comptes d’identification permettent d’effectuer les détections en cours à l’aide des règles de détection applicables, puis de démarrer la surveillance. Après plusieurs minutes, sous l’espace de travail Administration, accédez à ordinateurs Gestion des appareils/UNIX/Linux et vérifiez que les ordinateurs ne sont pas répertoriés comme inconnus. Ils doivent être détectés et indiquer la version spécifique du système d’exploitation et du distributeur.

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ésolution des problèmes de surveillance d’UNIX et Linux

La section suivante fournit des informations sur les problèmes pouvant survenir avec 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. Assurez-vous 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 nécessaires pour accéder à des 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  

Dans ce cas, 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.

Pour modifier le nom du 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 le remplacement des fichiers dans /etc/opt/microsoft/scx/ssl.

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  

Pour ajouter une entrée au fichier d'hôte :

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 l’adresse IP 192.168.1.1, ajoutez ce qui suit à la fin du fichier hosts :

192.168.1.1      newhostname.newdomain.name  

Problèmes liés 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 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'action personnalisée suivants, vous spécifiez comment les arguments de commande sont appelés à l'aide du paramètre ExecuteCommand ou 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 de shell.

Le paramètre ExecuteShellCommand transmet les arguments de commande à un processus de shell à l'aide du shell par défaut de l'utilisateur. Ce shell prend en charge le pipeline, les alias et la syntaxe spécifique du shell.

Notes

Le paramètre ExecuteShellCommand utilise le shell par défaut de l'utilisateur qui exécute la commande. Si vous avez besoin d'un shell spécifique, utilisez le paramètre ExecuteCommand et placez le shell requis en préfixe des arguments de commande.

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>

Logging and Debugging

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.

Notes

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 produisent plusieurs fichiers journaux qui peuvent être utiles lors du dépannage des problèmes liés aux clients. Ces fichiers journaux sont situés sur l’ordinateur UNIX ou Linux managé. Le niveau de journalisation pour les 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 un fonctionnement normal, 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.

Notes

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.

Notes

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 du compte d’utilisateur appelant ces modules en tapant à une ligne de commande ou à une invite PowerShell :

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

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

   Notes

   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 Certificate dans le répertoire Temp. Scripts qui appellent le journal des modules SSH pour <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. En cas de problème avec les données retournées à Operations Manager, examinez 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 :

Level	Description
Erreurs	Journalise uniquement les messages de type Avertissement ou Erreur .
Intermédiaire	Messages d’informations de journal, d’avertissement et 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 depuis : 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 de la gestion à distance de Windows dans Operations Manager

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.

Notes

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

Notes

La commande FormatTracing ouvre une fenêtre de l’Explorateur Windows affichant le répertoire C:\Windows\Logs\OpsMgrTrace. 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 et les omiserver.log scx.log avec l’utilitaire logrotate de Linux. En règle générale, logrotate s’exécute en tant que tâche planifiée (avec crond) et agit sur les fichiers de configuration qui se trouvent dans /etc/logrotate.d. Pour tester et utiliser ce fichier de configuration, modifiez la configuration pour l’adapter à 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 de résolution des problèmes courants de déploiement de l’agent, passez en revue la page Wiki Operations Manager 2012 Troubleshooting: UNIX/Linux Agent Discovery.