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

System Center – Operations Manager bietet die Überwachung von UNIX- und Linux-Computern, die der Überwachung von Windows-Computern ähneln. Sie können den Status und die Leistung überwachen, Berichte abrufen, Aufgaben ausführen und benutzerdefinierte Überwachungsinstrumente implementieren.

Sie können die folgenden Aspekte von UNIX- und Linux-Computern überwachen:

• Dienste und Anwendungen

• Dateisystem, Speicherplatz, Auslagerungsbereich, 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 von "Ausführen als Konten".
5. Installieren Sie den Agent unter UNIX und Linux mit dem Discovery-Assistenten.

Nachdem Sie die vorstehenden Schritte ausgeführt und den Agent erfolgreich auf einem oder mehreren UNIX- und Linux-Computern gefunden und bereitgestellt haben, sollten Sie überprüfen, ob sie ordnungsgemäß überwacht werden. Nachdem ein Agent bereitgestellt wurde, werden die Run As-Konten verwendet, um Ermittlungen auszuführen, die mit den anwendbaren Ermittlungsregeln ausgeführt werden, und starten Sie dann die Überwachung. Navigieren Sie nach mehreren Minuten im Verwaltungsarbeitsbereich zu Geräteverwaltung/UNIX/Linux-Computern, und überprüfen Sie, ob die Computer nicht als unbekannt aufgeführt sind. Sie sollten ermittelt und die spezifische Version des Betriebssystems und der Distros angezeigt werden.

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

• Betriebssystem
• Logischer Datenträger
• Netzwerkadapter

Sie können zusätzliche Überwachungs- und Interaktionsfunktionen mit Ihren verwalteten UNIX- und Linux-Computern bereitstellen, indem Sie die UNIX- und Linux-Monitoring Pack-Vorlagen verwenden. Weitere Informationen finden Sie unter UNIX oder Linux Log File und UNIX oder Linux Process im Authoring Guide.

Problembehandlung bei UNIX- und Linux-Überwachung

Der folgende Abschnitt enthält Informationen zu Problemen, die bei der Überwachung von UNIX- und Linux-Computern im Operations Manager auftreten können.

Fehlermeldung zur Zertifikatsignierung

Während der Installation von UNIX/Linux-Agents wird möglicherweise der folgende Fehler 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 das Zertifikatsignaturmodul aufgerufen wird, aber das Zertifikat selbst leer ist. Dieser Fehler kann durch einen SSH-Verbindungsfehler mit dem Remotesystem verursacht werden.

Wenn dieser Fehler angezeigt wird, gehen Sie wie folgt vor:

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

2. Stellen Sie sicher, dass Sie eine SSH-Sitzung mit dem Remotehost öffnen können, indem Sie die im Discovery-Assistenten angegebenen Anmeldeinformationen verwenden.

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, die Sie benötigen, um auf UNIX- und Linux-Computer zuzugreifen.

Zertifikatname und Hostname stimmen nicht überein

Der allgemeine Name (CN), der im Zertifikat verwendet wird, muss mit dem vollqualifizierten Domänennamen (Fully Qualified Domain Name, 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 grundlegenden Details des Zertifikats 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 die Ausgabe angezeigt, die den 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 Datumsangaben, und stellen Sie sicher, dass sie mit dem Namen übereinstimmen, 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 ist, der Operations Manager-Verwaltungsserver sie jedoch falsch auflösen kann, ändern Sie entweder den DNS-Eintrag so, dass er dem richtigen FQDN entspricht, oder fügen Sie der Hostdatei auf dem Operations Manager-Server einen Eintrag hinzu.

• Wenn der UNIX- oder Linux-Hostname falsch ist, führen Sie eine der folgenden Aktionen aus:

  • Ändern Sie den Hostnamen auf dem UNIX- oder Linux-Host in das richtige, und erstellen Sie ein neues Zertifikat.

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

Ändern sie den Namen des Zertifikats:

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

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

Die Option "-f " erzwingt, dass die Dateien in /etc/opt/microsoft/scx/ssl überschrieben werden.

Sie können auch den Hostnamen und den Domänennamen im Zertifikat ändern, indem Sie die Schalter "-h " und "-d " wie im folgenden Beispiel verwenden:

/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  

Fügen Sie der Hostdatei einen Eintrag hinzu:

Wenn sich der FQDN nicht im Reverse-DNS befindet, können Sie der Hostdatei, die sich auf dem Verwaltungsserver befindet, einen Eintrag hinzufügen, um die Namensauflösung bereitzustellen. Die Hostdatei befindet sich im Ordner "Windows\System32\Drivers\etc". Ein Eintrag in der Hostdatei ist eine Kombination aus der IP-Adresse und dem FQDN.

Wenn Sie beispielsweise einen Eintrag für den Host namens newhostname.newdomain.name mit einer IP-Adresse von 192.168.1.1 hinzufügen möchten, fügen Sie Folgendes am Ende der Hostdatei hinzu:

192.168.1.1      newhostname.newdomain.name  

Probleme mit Management Pack

ExecuteCommand unterstützt keine Pipelineoperatoren oder Aliase

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

In System Center Operations Manager Management Packs, die zum Verwalten von UNIX- und Linux-Computern entwickelt wurden, startet der ExecuteCommand-Parameter keinen Shellprozess, wodurch die benutzerdefinierte Aktion fehlschlägt.

Für jeden der folgenden benutzerdefinierten Aktionstypen geben Sie an, wie die Befehlsargumente mithilfe des ExecuteCommand-Parameters oder des ExecuteShellCommand-Parameters 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 ExecuteCommand-Parameter übergibt die Befehlszeilenargumente an die Konsole, ohne einen Shellprozess zu starten.

Der ExecuteShellCommand-Parameter übergibt die Befehlsargumente mithilfe der Standardshell des Benutzers an einen Shellprozess. Diese Shell unterstützt Pipeline-, Aliase- und Shell-spezifische Syntax.

Hinweis

Der ExecuteShellCommand-Parameter verwendet die Standardshell des Benutzers, der den Befehl ausführt. Wenn Sie eine bestimmte Shell benötigen, verwenden Sie den ExecuteCommand-Parameter , und stellen Sie den Befehlsargumenten die erforderliche Shell voran.

Die folgenden Beispiele zeigen, wie sie die Parameter ExecuteCommand und ExecuteShellCommand verwenden:

• So übergeben Sie die Befehlszeilenargumente ohne Starten eines Shellprozesses an die Konsole:

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

• So übergeben Sie die Befehlszeilenargumente an einen Shellprozess, der auf eine explizite Shell verweist:

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

• So ü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>

Protokollieren und Debuggen

In diesem Abschnitt wird beschrieben, wie Sie Protokollierungs- und Debug-Tools 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 Operations Manager-Modulprotokollierung

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

Hinweis

Anrufe außerhalb der Windows-Remoteverwaltung (WinRM) werden mithilfe von SSH/SFTP getätigt. Diese Komponenten basieren auf einem separaten Protokollierungsmechanismus als Operations Manager.

Hinweis

Die Protokollierungsebene für die omiserver.log Protokolldatei kann nicht von der Standardversion der Operations Manager Agents für UNIX und Linux geändert werden.

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

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

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

   Hinweis

   Im Allgemeinen ist es das SYSTEM-Konto, das die Aufrufe vornimmt, und C:\Windows\Temp ist der Standardordner "SYSTEM temp".

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

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

Aktivieren der Protokollierung für den UNIX-Agent

Diese Protokolle melden die UNIX-Agentaktionen. Wenn ein Problem mit den an Operations Manager zurückgegebenen Daten vorliegt, sehen Sie in diesem Protokoll nach. Sie können die Menge der mit dem Befehl "scxadmin" protokollierten Informationen festlegen. Die Syntax für diesen Befehl lautet:

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

In der folgenden Tabelle sind die möglichen Parameterwerte aufgeführt:

Ebene	Beschreibung
Fehler	Nur Warnungs- oder Fehlermeldungen protokollieren.
Fortgeschrittene Anfänger	Protokollinformationen, Warnungen und Fehlermeldungen.
Ausführlich	Protokollinformationen, Warnungen und Fehlermeldungen mit Debugprotokollierung. Beachten Sie, dass diese Protokollierungsstufe wahrscheinlich ein schnelles Wachstum in der Größe der Protokolldateien verursacht. Es wird empfohlen, diese Option nur für kurze Zeiträume zur Diagnose eines bestimmten Problems zu verwenden.

Verwenden von DebugView zur Problembehandlung von Ermittlungsproblemen

DebugView ist eine alternative Methode zum EnableOpsmgrModuleLogging zur Problembehandlung bei Ermittlungsproblemen.

1. Download DebugView von: https://go.microsoft.comfwlink/?Linkid=129486.

2. Starten Sie DebugView auf dem Verwaltungsserver, der die Ermittlung ausführt.

3. Beginnen Sie mit der Entdeckung der UNIX-Agents. Sie sollten mit der Anzeige der Ausgabe in Ihren DebugView-Fenstern beginnen.

4. DebugView stellt ein schrittweises Lesen des Ermittlungs-Assistentenprozesses dar. Dies ist häufig die schnellste Methode zur Behebung von Ermittlungsproblemen.

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

Diese ausführliche Ablaufverfolgungsmethode wird verwendet, um die Windows-Remoteverwaltungsabfragen (Windows Remote Management, WinRM) anzuzeigen, die von Operations Manager zum Sammeln von Daten vom Agent verwendet werden. Wenn Sie vermuten, dass es ein Problem mit der WinRM-Verbindung gibt, enthält dieses Protokoll detaillierte Informationen, die bei der Problembehandlung hilfreich sein können.

1. Öffnen Sie auf dem Verwaltungsserver, der den UNIX- oder Linux-Agent überwacht, 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. Reproduzieren Sie das fehlerhafte Problem 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 auch als WS-Management (WS-Man) bezeichnet.

Hinweis

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

Verwalten von UNIX- und Linux-Protokolldateien

Die Operations Manager-Agents für UNIX und Linux beschränken nicht die Größe der Agent-Protokolldateien. Um die maximale Größe der Protokolldateien zu steuern, implementieren Sie einen Prozess zum Verwalten der Protokolldateien. Beispielsweise ist das Standard-Hilfsprogramm-Logrotat auf vielen UNIX- und Linux-Betriebssystemen verfügbar. Das Logrotate-Hilfsprogramm kann so konfiguriert werden, dass die protokolldateien gesteuert werden, die von den Operations Manager Agents für UNIX oder Linux verwendet werden. Nach dem Drehen oder Ändern der Protokolldateien des Agents muss der Agent signalisiert werden, dass protokolle gedreht wurden, um die Protokollierung fortzusetzen. 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 Drehen der scx.log Dateien und omiserver.log mit dem Logrotate-Dienstprogramm von Linux. In der Regel wird logrotate als geplanter Auftrag (mit Crond) ausgeführt und auf Konfigurationsdateien reagieren, die in /etc/logrotate.d. Um diese Konfigurationsdatei zu testen und zu verwenden, ändern Sie die Konfiguration so, dass sie für Ihre Umgebung geeignet ist, 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 zur Behebung gängiger Agent-Bereitstellungsprobleme finden Sie unter Operations Manager 2012 Problembehandlung: UNIX/Linux Agent Discovery Wiki.