Problembehandlung bei der Überwachung von UNIX- und Linux-Computern

System Center – Operations Manager stellt Überwachung für UNIX- und Linux-Computer bereit, die der Überwachung auf Windows-Computern ähnelt. Sie können die Integrität und die Leistung überwachen, Berichte abrufen, Aufgaben ausführen und benutzerdefinierte Überwachungs-Instrumentierung implementieren.

Die folgenden Aspekte von UNIX- und Linux-Computern können überwacht werden:

• Dienste und Anwendungen

• Dateisystem, Speicherplatz, Auslagerungsbereich und Systemspeicher

• Netzwerkschnittstellen

• Kernprozesse und -attribute

• Schlüsselkonfigurationen

Bevor Sie UNIX- und Linux-Computer überwachen können, müssen Sie die folgenden Schritte ausführen:

1. Importieren Sie Management Packs, indem Sie die neuesten Versionen aus dem Microsoft Download Center herunterladen.
2. Erstellen Sie einen dedizierten Ressourcenpool für die Überwachung von UNIX- und Linux-Computern.
3. Konfigurieren Sie die Zertifikate für jeden Verwaltungsserver im Pool.
4. Erstellen und Konfigurieren ausführener Konten
5. Installieren Sie den Agent unter UNIX und Linux mithilfe des Ermittlungs-Assistenten.

Nachdem Sie die obigen Schritte ausgeführt und den Agent erfolgreich ermittelt und auf einem oder mehreren UNIX- und Linux-Computern bereitgestellt haben, sollten Sie überprüfen, ob er ordnungsgemäß überwacht wird. Nach der Bereitstellung eines Agents werden die ausführenden Konten verwendet, um Ermittlungen mithilfe der entsprechenden Ermittlungsregeln auszuführen und anschließend mit der Überwachung zu beginnen. Navigieren Sie nach einigen Minuten im Arbeitsbereich Verwaltung zu Geräteverwaltung/UNIX/Linux-Computer, und überprüfen Sie, ob die Computer nicht als Unbekannt aufgeführt sind. Sie sollten ermittelt worden sein und die genaue Version des Betriebssystems und die Verteilung anzeigen.

Operations Manager überwacht standardmäßig die folgenden Betriebssystemobjekte:

• Betriebssystem
• Logischer Datenträger
• Netzwerkadapter

Mit den Vorlagen der UNIX- und Linux-Überwachungspakete können Sie für die verwalteten UNIX- und Linux-Computer weitere Überwachungs- und Interaktionsfunktionen bereitstellen. Weitere Informationen finden Sie unter UNIX oder Linux-Protokolldatei und UNIX oder Linux-Prozess im Erstellungshandbuch.

Problembehandlung bei der UNIX- und Linux-Überwachung

Im folgenden Abschnitt finden Sie Informationen zu Problemen, die bei der Überwachung von UNIX- und Linux-Computern in Operations Manager auftreten können.

Fehler bei der Zertifikatsignierung

Bei der Installation von UNIX/Linux-Agents wird möglicherweise die folgende Fehlermeldung angezeigt:

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:  

Dieser Fehler tritt auf, wenn der Aufruf des Zertifikatsignaturmoduls mit einem leeren Zertifikat erfolgt. Ursache hierfür kann z. B. eine fehlerhafte SSH-Verbindung mit dem Remotesystem sein.

Gehen Sie folgendermaßen vor, wenn dieser Fehler angezeigt wird:

1. Stellen Sie sicher, dass der SSH-Daemon auf dem Remotehost ausgeführt wird.

2. Stellen Sie sicher, dass Sie mithilfe der im Ermittlungs-Assistenten angegebenen Anmeldeinformationen eine SSH-Sitzung mit dem Remotehost öffnen können.

3. Stellen Sie sicher, dass die im Ermittlungs-Assistenten angegebenen Anmeldeinformationen über die erforderlichen Berechtigungen für die Ermittlung verfügen. Weitere Informationen finden Sie unter Anmeldeinformationen für den Zugriff auf UNIX- und Linux-Computer.

Zertifikat- und Hostname stimmen nicht überein

Der im Zertifikat verwendete allgemeine Name (CN) muss mit dem voll qualifizierten Domänennamen (FQDN) übereinstimmen, der von Operations Manager aufgelöst wird. Wenn der CN nicht übereinstimmt, wird beim Ausführen des Ermittlungs-Assistenten der folgende Fehler angezeigt:

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

Sie können die wichtigsten Zertifikatdetails auf dem UNIX- oder Linux-Computer anzeigen, indem Sie den folgenden Befehl eingeben:

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

Wenn Sie dies tun, wird eine Ausgabe angezeigt, die der folgenden ähnelt:

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  

Überprüfen Sie die Hostnamen und Daten, und stellen Sie sicher, dass sie dem Namen entsprechen, der vom Operations Manager-Verwaltungsserver aufgelöst wird.

Wenn die Hostnamen nicht übereinstimmen, verwenden Sie eine der folgenden Aktionen, um das Problem zu beheben:

• Wenn der UNIX- oder Linux-Hostname richtig angegeben ist, vom Operations Manager-Verwaltungsserver jedoch nicht ordnungsgemäß aufgelöst werden kann, können Sie entweder den DNS-Eintrag so bearbeiten, dass er dem richtigen FQDN entspricht, oder einen Eintrag zur Hostdatei auf dem Operations Manager-Server hinzufügen.

• Wenn der UNIX- oder Linux-Hostname fehlerhaft ist, führen Sie einen der folgenden Schritte aus:

  • Korrigieren Sie den Hostnamen auf dem UNIX- oder Linux-Host, und erstellen Sie ein neues Zertifikat.

  • Erstellen Sie ein neues Zertifikat mit dem gewünschten Hostnamen.

So ändern Sie den Namen des Zertifikats:

Wenn das Zertifikat mit einem falschen Namen erstellt wurde, können Sie den Hostnamen ändern und das Zertifikat sowie den privaten Schlüssel erneut erstellen. Führen Sie hierzu den folgenden Befehl auf dem UNIX- oder Linux-Computer aus:

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

Mit der Option -f werden die Dateien in /etc/opt/microsoft/scx/ssl überschrieben.

Mithilfe der Switches -h und -d können Sie außerdem den im Zertifikat angegebenen Host- bzw. Domänennamen ändern, wie im folgenden Beispiel dargestellt:

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

Starten Sie den Agent neu, indem Sie den folgenden Befehl ausführen:

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

So fügen Sie einen Eintrag zur Hostdatei hinzu:

Wenn sich der FQDN nicht im Reverse-DNS befindet, können Sie der Hostdatei auf dem Verwaltungsserver einen Eintrag hinzufügen, um die Namensauflösung bereitzustellen. Die Hostdatei befindet sich im Ordner „Windows\System32\Drivers\etc“. Einträge in der Hostdatei setzen sich aus der IP-Adresse und dem FQDN zusammen.

Um beispielsweise einen Eintrag für den Host namens newhostname.newdomain.name mit der IP-Adresse 192.168.1.1 hinzuzufügen, fügen Sie am Ende der Hostdatei Folgendes hinzu:

192.168.1.1      newhostname.newdomain.name  

Probleme mit Management Packs

„ExecuteCommand“ unterstützt keine Pipeline-Operatoren oder Aliase

Wenn Sie für den Parameter ExecuteCommand einen Alias oder Pipeline-Operator verwenden, schlägt der Befehl fehl. Der ExecuteCommand-Parameter unterstützt den Pipelineoperator, die Aliase und die shellspezifische Syntax nicht.

In System Center Operations Manager-Management Packs, die für die Verwaltung von UNIX- und Linux-Computern konzipiert sind, startet der ExecuteCommand-Parameter keinen Shellprozess, sodass die benutzerdefinierte Aktion fehlschlägt.

Für jeden der folgenden benutzerdefinierten Aktionstypen geben Sie mit dem Parameter ExecuteCommand oder dem Parameter ExecuteShellCommand an, wie die Befehlsargumente aufgerufen werden:

• Microsoft.Unix.WSMan.Invoke.ProbeAction

• Microsoft.Unix.WSMan.Invoke.WriteAction

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

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

Der Parameter ExecuteCommand übergibt die Befehlszeilenargumente an die Konsole, ohne einen Shellprozess zu starten.

Der Parameter ExecuteShellCommand übergibt die Befehlsargumente mit der Standardshell des Benutzers, die die Pipeline, Aliase und shellspezifische Syntax unterstützt, an einen Shellprozess.

Hinweis

Für den Parameter ExecuteShellCommand wird die Standardshell des Benutzers verwendet, der den Befehl ausführt. Wenn eine bestimmte Shell verwendet werden soll, stellen Sie dem Parameter ExecuteCommand die Befehlsargumente mit der erforderlichen Shell voran.

Das folgende Beispiel veranschaulicht die Verwendung der Parameter ExecuteCommand und ExecuteShellCommand :

• Mit folgendem Befehl übergeben Sie die Befehlszeilenargumente an die Konsole, ohne einen Shellprozess zu starten:

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

• Mit folgendem Befehl übergeben Sie die Befehlszeilenargumente an einen Shellprozess, der eine bestimmte Shell referenziert:

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

• Mit folgendem Befehl übergeben Sie die Befehlsargumente an einen Shellprozess, der die Standardshell des Benutzers verwendet:

  <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

In diesem Abschnitt wird beschrieben, wie Sie Protokollierungs- und Debugtools für die Problembehandlung bei der Überwachung von UNIX- und Linux-Computern aktivieren.

Hinweis

Sie können Einstellungen auf Protokollebene ändern, ohne den Agent neu starten zu müssen. Weitere Informationen

Aktivieren der Protokollierung für das Operations Manager-Modul

Die Operations Manager-Agents für UNIX und Linux verwalten mehrere Protokolldateien, die bei der Problembehandlung von Clientproblemen hilfreich sein können. Diese Protokolldateien befinden sich auf dem verwalteten UNIX- oder Linux-Computer. Die Protokollierungsstufe für die Agent-Protokolldateien kann je nach Bedarf konfiguriert werden. Eine detailliertere Protokollierung kann bei der Diagnose eines Problems hilfreich sein. Für den normalen Betrieb sollten Protokollebenen nicht auf einen Wert festgelegt werden, der ausführlicher als die Standardkonfigurationen (Intermediate) ist, um übermäßiges Wachstum der Protokolldateien zu verhindern.

Hinweis

Anrufe außerhalb der Windows-Remoteverwaltung (WinRM) werden mithilfe von SSH/SFTP vorgenommen. Diese Komponenten beruhen auf einem anderen Protokollierungsmechanismus als dem von Operations Manager.

Hinweis

Die Protokollierungsebene für die omiserver.log Protokolldatei kann in dieser Version der Operations Manager-Agents für UNIX und Linux nicht vom Standardwert geändert werden.

1. Erstellen Sie eine leere Datei mit dem Namen EnableOpsmgrModuleLogging im Verzeichnis Temp für das Benutzerkonto, das diese Module aufruft, indem Sie an einer Befehlszeilen- oder PowerShell-Eingabeaufforderung eingeben:

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

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

   Hinweis

   Im Allgemeinen handelt es sich um das SYSTEM-Konto, das die Aufrufe durchführt, und C:\Windows\Temp ist der standardordner SYSTEM temp.

2. Nach der Erstellung der leeren Datei beginnt Operations Manager sofort mit der Protokollierung der SSH- und Zertifikataktivität im Verzeichnis Temp. Skripts, die die SSH-Module aufrufen, protokollieren, um <Scriptname.vbs>.log. Andere Module verfügen über eigene Protokolle.

In einigen Fällen kann es erforderlich sein, den HealthService neu zu starten, damit die EnableOpsmgrModuleLogging-Protokollierung wirksam wird.

Aktivieren der Protokollierung auf dem UNIX-Agent

In diesen Protokollen werden die UNIX-Agentaktionen erfasst. Wenn es ein Problem mit den an Operations Manager zurückgegebenen Daten gibt, suchen Sie in diesem Protokoll. Sie können die Menge an protokollierten Informationen mit dem Befehl „Scxadmin“ festlegen. Die Syntax für diesen Befehl lautet:

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

In der folgende Tabelle werden die möglichen Parameterwerte aufgeführt:

Ebene	BESCHREIBUNG
Errors	Protokollieren Sie nur die Meldungen Warnung oder Fehler .
Fortgeschrittene Anfänger	Protokollinformationen, Warnungen und Fehlermeldungen.
Ausführlich	Protokollieren Sie die Meldungen Information, Warnungund Fehler mit der Debug-Protokollierung. Beachten Sie, dass diese Stufe der Protokollierung dazu führt, dass die Größe der Protokolldateien schnell anwächst. Es wird empfohlen, diese Option nur für kurze Zeit zu verwenden, um ein bestimmtes Problem zu diagnostizieren.

Verwenden von DebugView zur Behandlung von Ermittlungsproblemen

DebugView kann alternativ zu EnableOpsmgrModuleLogging für die Behandlung von Ermittlungsproblemen verwendet werden.

1. Laden Sie DebugView hier herunter: https://go.microsoft.comfwlink/?Linkid=129486.

2. Starten Sie DebugView auf dem Verwaltungsserver, der für die Ermittlung verwendet wird.

3. Beginnen Sie mit der Ermittlung von UNIX-Agents. Die Ergebnisse werden in den DebugView-Fenstern angezeigt.

4. DebugView liefert umfassende Informationen zu den durch den Ermittlungs-Assistenten ausgeführten Vorgängen. Zur schnellen Beseitigung von Ermittlungsproblemen ist diese Methode häufig am besten geeignet.

Aktivieren der Protokollierung für Windows-Remoteverwaltung in Operations Manager

Die ausführliche Ablaufverfolgung dient zur Erfassung der WinRM-Abfragen (Windows-Remoteverwaltung), die von Operations Manager für den Abruf von Agentdaten verwendet werden. Wenn Sie vermuten, dass ein Problem mit der WinRM-Verbindung vorliegt, enthält dieses Protokoll ausführliche Informationen, die bei der Problembehandlung hilfreich sein können.

1. Öffnen Sie auf dem Verwaltungsserver, mit dem der UNIX- oder Linux-Agent überwacht wird, eine Eingabeaufforderung.

2. Geben Sie an der Eingabeaufforderung die folgenden Befehle ein:

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

   2. StopTracing.cmd

   3. StartTracing.cmd VER

3. Replizieren Sie den Fehler in Operations Manager.

4. Geben Sie an der Eingabeaufforderung die folgenden Befehle ein:

   1. StopTracing.cmd

   2. FormatTracing.cmd

5. Suchen Sie in der Datei „TracingGuidsNative.log“ nach WS-Man.

Hinweis

WinRM wird manchmal auch als „WS-Verwaltung“ („WSMan“) bezeichnet.

Hinweis

Mit dem Befehl „FormatTracing“ wird ein Windows Explorer-Fenster geöffnet, in dem das Verzeichnis C:\Windows\Logs\OpsMgrTrace angezeigt wird. Die Datei „TracingGuidsNative.log“ befindet sich in diesem Verzeichnis.

Verwalten von UNIX- und Linux-Protokolldateien

Die Operations Manager-Agents für UNIX und Linux beschränken die Größe der Agent-Protokolldateien nicht. Um die maximale Größe der Protokolldateien zu steuern, implementieren Sie einen Prozess zum Verwalten der Protokolldateien. Beispielsweise ist das Standard-Dienstprogramm Logrotate auf vielen UNIX- und Linux-Betriebssystemen verfügbar. Das Logrotate-Dienstprogramm kann so konfiguriert werden, dass es die von Operations Manager-Agents für UNIX oder Linux verwendeten Protokolldateien steuert. Nach der Rotation oder Änderung der Protokolldateien des Agents muss dem Agent signalisiert werden, dass Protokolle gedreht wurden, damit die Protokollierung fortgesetzt werden kann. Der Befehl „scxadmin“ kann mit dem Parameter „–log-rotate“ in der folgenden Syntax verwendet werden:

scxadmin -log-rotate all

Beispiel für eine Logrotate-Konfigurationsdatei.

Das folgende Beispiel veranschaulicht eine Konfigurationsdatei zum Rotieren der scx.log-Dateien und omiserver.log mit dem Hilfsprogramm logrotate von Linux. In der Regel wird Logrotate als geplanter Auftrag (mit „crond“) ausgeführt, und bearbeitet Konfigurationsdateien in /etc/logrotate.d. Um diese Konfigurationsdatei zu testen und zu verwenden, passen Sie die Konfiguration Ihrer Umgebung an und verknüpfen oder speichern Sie die Datei in /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\
#}  

Nächste Schritte

Weitere Anleitungen zum Beheben von bekannten Problemen bei der Bereitstellung von Agents finden Sie im Wiki unter Operations Manager 2012 Troubleshooting: UNIX/Linux Agent Discovery.