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

Wichtig

Diese Version von Operations Manager hat das Supportende erreicht. Sie sollten ein Upgrade auf Operations Manager 2019 durchführen.

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. Aktuelle Versionen von Management Packs im Microsoft Download Center herunterladen und importieren
  2. Einen dedizierten Ressourcenpool für die Überwachung von UNIX- und Linux-Computern erstellen
  3. Die Zertifikate für jeden Verwaltungsserver im Pool konfigurieren
  4. Ausführende Konten erstellen und konfigurieren
  5. Den Agent unter UNIX und Linux mithilfe des Ermittlungs-Assistenten installieren

Nachdem Sie diese Schritte abgeschlossen und den Agent erfolgreich ermittelt und auf mindestens einem UNIX- oder Linux-Computer bereitstellt haben, sollten Sie sicherstellen, dass die Computer ordnungsgemäß überwacht werden. 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 vergewissern Sie sich, dass die Computer nicht als Unbekannt aufgelistet wird. 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 eine SSH-Remotehostsitzung mithilfe der im Ermittlungs-Assistenten angegebenen Anmeldeinformationen starten können.

  3. Stellen Sie sicher, dass die im Ermittlungs-Assistenten angegebenen Anmeldeinformationen über ausreichende 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. Ist dies nicht der Fall, wird bei Ausführung des Ermittlungs-Assistenten der folgende Fehler angezeigt:

The SSL certificate contains a common name (CN) that does not 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  

Daraufhin werden Informationen der folgenden Art angezeigt:

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.

Führen Sie, falls die Hostnamen nicht übereinstimmen sollten, eine der folgenden Aktionen aus, 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:

Sofern es sich bei dem FQDN nicht um einen Reversenamen handelt, können Sie für die Namensauflösung einen Eintrag zur Hostdatei hinzufügen, welche sich auf dem Verwaltungsserver befindet. 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 z.B. dem Host namens „newhostname.newdomain.name“, mit der IP-Adresse 192.168.1.1, einen Eintrag hinzuzufügen, fügen Sie an das Ende der Hostdatei Folgendes an:

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 Parameter ExecuteCommand unterstützt den Pipeline-Operator, Aliase und shellspezifische Syntax nicht.

In Management Packs von System Center Operations Manager, die für die Verwaltung von UNIX- und Linux-Computern vorgesehen sind, startet der Parameter ExecuteCommand 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 Thema werden die Schritte zur Aktivierung von Protokollierungs- und Debugtools beschrieben, die Sie einsetzen können, um Überwachungsprobleme bei UNIX- oder Linux-Computern zu beheben.

Hinweis

Mit Operations Manager 2019 UR3 können Einstellungen auf Protokollebene geändert werden, ohne dass der Agent neu gestartet werden muss. 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 Protokollierungsstufen nicht auf einen ausführlicheren Wert als die Standardkonfigurationen (Fortgeschritten) festgelegt werden, um die übermäßige Vergrößerung der Datei 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 Protokollierungsstufe für die Protokolldatei „omiserver.log“ kann von der Standardeinstellung in dieser Version von Operations Manager-Agents für UNIX und Linux geändert werden.

  1. Erstellen Sie eine leere Datei namens EnableOpsmgrModuleLogging im temporären Verzeichnis für das Benutzerkonto, das diese Module aufruft. Geben Sie dazu COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging an der Eingabeaufforderung ein.

    Hinweis

    Im Allgemeinen wird für Aufrufe das Konto „SYSTEM“ verwendet, für welches der Pfad des temporären Verzeichnisses standardmäßig „C:\Windows\Temp“ lautet.

  2. Nachdem Sie die leere Datei erstellt haben, werden SSH- und Zertifikatvorgänge von Operations Manager im temporären Verzeichnis protokolliert. Skripts, die SSH-Module aufrufen, protokollieren in Skriptname.vbs.log. Andere Module verfügen über eigene Protokolle.

U. U. muss der Integritätsdienst neu gestartet werden, damit die Protokollierung in der Datei „EnableOpsmgrModuleLogging“ wirksam wird.

Aktivieren der Protokollierung auf dem UNIX-Agent

In diesen Protokollen werden die UNIX-Agentaktionen erfasst. Wenn bei den an Operations Manager gesendeten Daten Probleme auftreten, lassen sie häufig Rückschlüsse zu. 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 Protokollieren Sie die Meldungen Information, Warnung und Fehler .
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 dringend empfohlen, dass diese Option nur für kurze Zeit verwendet wird, 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 eine fehlerhafte WinRM-Verbindung vermuten, finden Sie in diesem Protokoll ausführliche Informationen, die Ihnen bei der Poblembehandlung von Nutzen 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 2016\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\Temp\OpsMgrTrace angezeigt wird. Die Datei „TracingGuidsNative.log“ befindet sich in diesem Verzeichnis.

Verwalten von UNIX- und Linux-Protokolldateien

Die Größe der Agent-Protokolldateien wird von den Operations Manager-Agents für UNIX und Linux nicht eingeschränkt. 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 zeigt eine Konfigurationsdatei, um die „scx.log“-Dateien und „omiserver.log“ mit dem Dienstprogramm logrotate von Linux zu drehen. 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.