Behandeln von Problemen mit grauen Agentstatus in System Center Operations Manager

In diesem Artikel wird beschrieben, wie Sie Probleme beheben können, bei denen ein Agent, ein Verwaltungsserver oder ein Gateway in System Center Operations Manager (OpsMgr) nicht verfügbar oder abgeblendet ist.

Ursprüngliche Produktversion: Microsoft System Center 2012 Operations Manager
Ursprüngliche KB-Nummer: 2288515

Ein Agent, ein Verwaltungsserver oder ein Gateway kann einen der folgenden Zustände aufweisen, wie durch die Farbe des Agentnamens und -symbols im Überwachungsbereich angegeben.

Staat	Erscheinungsbild	Beschreibung
Healthy	Grünes Häkchen	Der Agent oder Management-Server läuft normal.
Kritisch	Rotes Häkchen	Es liegt ein Problem auf dem Agent- oder Management-Server vor.
Unbekannt	Grauer Agentname, graues Häkchen	Der Integritätsdienst-Watcher auf dem Verwaltungsserver, der den Integritätsdienst auf dem überwachten Computer überwacht, empfängt keine Heartbeats mehr vom Agents. Die Überwachung des Integritätsdiensts hatte zuvor Heartbeats erhalten, und der Zustand wurde als fehlerfrei gemeldet. Das bedeutet auch, dass die Verwaltungsserver keine Informationen mehr vom Agent erhalten. Dieses Problem kann auftreten, wenn der Computer, auf dem der Agent ausgeführt wird, nicht läuft oder wenn es Probleme mit der Verbindung gibt.
Unbekannt	Grüner Kreis, kein Häkchen	Der Status des ermittelten Elements ist unbekannt. Für dieses bestimmte ermittelte Element ist kein Überwachungsprogramm verfügbar.

Ursachen eines grauen Zustands

Ein Agent, ein Verwaltungsserver oder ein Gateway kann aus einem der folgenden Gründe nicht mehr verfügbar sein:

• Taktausfall
• Ungültige Konfiguration
• Systemworkflowfehler
• Operations Manager Datenbank- oder Data Warehouse-Leistungsprobleme
• Probleme mit der Leistung des Verwaltungs- oder Gatewayservers
• Netzwerk- oder Authentifizierungsprobleme
• Integritätsdienst wird nicht ausgeführt

Problembereich

Bevor Sie mit der Problembehandlung des Agents beginnen, sollten Sie zuerst die Operations Manager-Topologie verstehen und dann den Umfang des Problems definieren. Die folgenden Fragen können Ihnen helfen, den Umfang des Problems zu definieren:

• Wie viele Agents sind betroffen?
• Haben die Agents das Problem im selben Netzwerksegment?
• Melden die Agents an denselben Verwaltungsserver?
• Wie oft betreten und verbleiben die Agenten in einem grauen Zustand?
• Wie können Sie sich in der Regel aus dieser Situation wiederherstellen (z. B. den Agent-Integritätsdienst neu starten, den Cache löschen, auf automatische Wiederherstellung verlassen)?
• Werden die Taktfehlerwarnungen für diese Agents generiert?
• Tritt dieses Problem während einer bestimmten Tageszeit auf?
• Bleibt dieses Problem bestehen, wenn Sie diese Agents an einen anderen Verwaltungsserver oder ein anderes Gateway übergeben?
• Wann ist dieses Problem zum ersten Mal aufgetreten?
• Wurden Änderungen an den Agents, den Verwaltungsservern oder der Gateway- oder Verwaltungsgruppe vorgenommen?
• Sind die betroffenen Agents Windows-Clustersysteme?
• Wird der Ordner "Integritätsdienst Status" von der Virenüberprüfung ausgeschlossen?

Problembehandlungsstrategie

Ihre Problembehandlungsstrategie wird durch die inaktive Komponente bestimmt, wo diese Komponente in die Topologie fällt und wie weit das Problem verbreitet ist. Unter den folgenden Bedingungen ziehen Sie Folgendes in Betracht:

• Wenn die Agents, die einem bestimmten Verwaltungsserver oder Gateway melden, nicht verfügbar sind, sollte die Problembehandlung auf Verwaltungsserver- oder Gatewayebene beginnen.
• Wenn die Gateways, die einen bestimmten Verwaltungsserver melden, nicht verfügbar sind, sollte die Problembehandlung auf Verwaltungsserverebene beginnen.
• Bei agentlosen Systemen, für Netzwerkgeräte und für Unix- und Linux-Server sollte die Problembehandlung beim Agent, Verwaltungsserver oder Gateway gestartet werden, das diese Objekte überwacht.
• Die Problembehandlung beginnt in der Regel direkt oberhalb der nicht verfügbaren Komponente auf der Ebene.

Szenario 1

Nur wenige Agents sind vom Problem betroffen. Diese Agents melden sich an verschiedene Verwaltungsserver. Agenten bleiben regelmäßig nicht verfügbar. Obwohl Sie den Agentcache löschen können, um das Problem vorübergehend zu beheben, wird das Problem nach einigen Tagen rekursiert.

Lösung für Szenario 1

Führen Sie die folgenden Schritte aus, um das Problem in diesem Szenario zu beheben:

1. Wenden Sie den entsprechenden Hotfix auf die betroffenen Betriebssysteme an.
2. Schließen Sie den Agentcache von der Antivirenüberprüfung aus. Weitere Informationen finden Sie unter Empfehlungen für Antivirenausschlüsse, die sich auf Operations Manager beziehen.
3. Beenden Sie den Integritätsdienst.
4. Löschen Sie den Agentcache.
5. Starten Sie den Integritätsdienst.

Szenario 2

Nur wenige Agents sind vom Problem betroffen. Diese Agents melden sich an verschiedene Verwaltungsserver. Agenten bleiben ständig inaktiv. Obwohl Sie den Agentcache löschen können, wird das Problem dadurch nicht behoben.

Lösung für Szenario 2

Führen Sie die folgenden Schritte aus, um das Problem in diesem Szenario zu beheben:

1. Ermitteln Sie, ob der Integritätsdienst aktiviert ist und derzeit auf dem Verwaltungsserver oder Gateway ausgeführt wird. Wenn der Integritätsdienst nicht mehr reagiert, generieren Sie ein ADPlus-Speicherabbild in einem Dienst-Hang-Modus, um die Ursache des Problems zu ermitteln. Weitere Informationen finden Sie unter Verwendung von ADPlus.vbs zur Problembehandlung von "Hangs" und "Crashes"

2. Überprüfen Sie das Operations Manager-Ereignisprotokoll beim Agent, um eines der folgenden Ereignisse zu finden:

   Ereignis-ID: 1102
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Regel/Monitor "%4", die für die Instanz "%3" mit id:"%2" ausgeführt wird, kann nicht initialisiert werden und wird nicht geladen. Verwaltungsgruppe „%1“

   Ereignis-ID: 1103
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Zusammenfassung: %2 Regel(n)/Monitore sind fehlgeschlagen und wurden entladen, %3 von ihnen erreichte den Fehlergrenzwert, der das automatische Neuladen verhindert. Verwaltungsgruppe „%1“ Dies ist nur eine Zusammenfassung des Ereignisses. Sehen Sie sich andere Ereignisse mit Beschreibungen der entladenen Regel(n)/Monitore an.

   Ereignis-ID: 1104
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   RunAs-Profil im Workflow "%4", das z. B. "%3" mit id:"%2" ausgeführt wird, kann nicht aufgelöst werden. Workflow wird nicht geladen. Verwaltungsgruppe „%1“

   Ereignis-ID: 1105
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Typenkonflikt für RunAs-Profil im Workflow "%4", wird z. B. "%3" mit id:"%2" ausgeführt. Workflow wird nicht geladen. Verwaltungsgruppe „%1“

   Ereignis-ID: 1106
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Im Workflow "%4" kann nicht auf das RunAs-Profil mit Nur-Text zugegriffen werden, wobei beispielsweise "%3" mit id:"%2" ausgeführt wird. Workflow wird nicht geladen. Verwaltungsgruppe „%1“

   Ereignis-ID: 1107
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Konto für RunAs-Profil im Workflow "%4", das z. B. "%3" mit id:"%2" ausgeführt wird, ist nicht definiert. Workflow wird nicht geladen. Ordnen Sie dem Profil ein Konto zu. Verwaltungsgruppe „%1“

   Ereignis-ID: 1108
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Ein im Profil "%7" angegebenes Konto kann nicht aufgelöst werden. Insbesondere wird das Konto bei der Außerkraftsetzung von sicherem Verweis „%6“ verwendet. %n%n Eine mögliche Ursache besteht darin, dass das Konto nicht für die Verteilung auf diesen Computer konfiguriert ist. Um das Problem zu beheben, müssen Sie das unten angegebene RunAs-Profil öffnen, den Konto-Eintrag anhand seiner SSID ausfindig machen und je nach Bedarf die Verteilung des Kontos auf diesen Computer aktivieren oder die Profileinstellungen so ändern, dass das Zielobjekt das angegebene Konto nicht verwendet. %n%nVerwaltungsgruppe: %1 %nAusführendes Profil: %7 %nSecureReferenceOverride-Name: %6 %nSecureReferenceOverride-ID: %4 %nObjektname: %3 %nObjekt-ID: %2 %nKonto-SSID: %5

   Ereignis-ID: 4000
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Ein Überwachungshost reagiert nicht oder ist abgestürzt. Der Statuscode für den Hostfehler lautet %1.

   Ereignis-ID: 21016
   Ereignisquelle: OpsMgr Connector
   Ereignisbeschreibung:
   OpsMgr konnte keinen Kommunikationskanal für %1 einrichten, und es gibt keine Failoverhosts. Die Kommunikation wird fortgesetzt, wenn %1 verfügbar ist und die Kommunikation von diesem Computer zulässig ist.

   Ereignis-ID: 21006
   Ereignisquelle: OpsMgr Connector
   Ereignisbeschreibung:
   Der OpsMgr Connector konnte keine Verbindung mit %1:%2 herstellen. Der Fehlercode ist %3(%4). Überprüfen Sie, ob netzwerkkonnektivität vorhanden ist, der Server ausgeführt wird und den Überwachungsport registriert hat, und es gibt keine Firewalls, die den Datenverkehr an das Ziel blockieren.

   Ereignis-ID: 20070
   Ereignisquelle: OpsMgr Connector
   Ereignisbeschreibung:
   Der OpsMgr-Connector ist mit %1 verbunden, die Verbindung wurde jedoch unmittelbar nach der Authentifizierung geschlossen. Die wahrscheinlichste Ursache für diesen Fehler ist, dass der Agent nicht berechtigt ist, mit dem Server zu kommunizieren, oder der Server hat keine Konfiguration erhalten. Überprüfen Sie das Ereignisprotokoll auf dem Server auf das Vorhandensein von 20000-Ereignissen, was angibt, dass Agents, die nicht genehmigt wurden, versuchen, eine Verbindung herzustellen.

   Ereignis-ID: 20051
   Ereignisquelle: OpsMgr Connector
   Ereignisbeschreibung:
   Das angegebene Zertifikat konnte nicht geladen werden, da das Zertifikat zurzeit ungültig ist. Überprüfen Sie, ob die Systemzeit korrekt ist, und stellen Sie das Zertifikat bei Bedarf erneut aus%n Gültige Startzeit des Zertifikats: %1%n Gültige Endzeit des Zertifikats: %2

   Ereignisquelle: ESE
   Ereigniskategorie: Transaktions-Manager
   Ereignis-ID: 623
   Beschreibung: HealthService (<PID>) Der Versionsspeicher für Instanzinstanz<>("<Name>") hat seine maximale Größe des Werts<> Mb erreicht. Es ist wahrscheinlich, dass eine lange ausgeführte Transaktion die Bereinigung des Versionsspeichers verhindert und die Größe vergrößert. Updates werden abgelehnt, bis die lange ausgeführte Transaktion vollständig zugesichert oder zurückgesetzt wurde. Mögliche langfristige Transaktion:
   SessionId: <wert>
   Sitzungskontext: <Wert>
   Session-context ThreadId: <value>.
   Bereinigung: <Wert>

3. Wenn Sie die folgenden besonderen Ereignisse erkennen, befolgen Sie diese Richtlinien:

   • Ereignisse 1102 und 1103: Diese Ereignisse zeigen an, dass einige der Workflows nicht geladen werden konnten. Wenn dies die zentralen Workflows des Systems sind, könnten diese Ereignisse das Problem verursachen. Konzentrieren Sie sich in diesem Fall darauf, diese Ereignisse zu beheben.

   • Ereignisse 1104, 1105, 1106, 1107 und 1108: Diese Ereignisse können die Ereignisse 1102 und 1103 verursachen. In der Regel ist dies auf falsch konfigurierte ausführende Konten zurückzuführen. Beispielsweise sind die ausführenden Konten so konfiguriert, dass sie mit der falschen Klasse verwendet werden, oder sie sind nicht so konfiguriert, dass sie an den Agent verteilt werden.

   • Ereignis 4000: Dieses Ereignis gibt an, dass der Monitoringhost.exe Prozess abgestürzt ist. Wenn dieses Problem durch einen DLL-Konflikt oder durch fehlende Registrierungsschlüssel verursacht wird, können Sie das Problem möglicherweise beheben, indem Sie den Agent erneut installieren. Wenn das Problem weiterhin besteht, versuchen Sie, es mithilfe der folgenden Methoden zu beheben:

     • Führen Sie eine Prozessüberwachungserfassung aus, bis der Punkt abstürzt, an dem der Prozess abstürzt. Weitere Informationen finden Sie unter Process Monitor v3.53.
     • Generieren Sie ein ADPlus-Abbild im Absturzmodus. Weitere Informationen finden Sie unter Verwendung von ADPlus.vbs zur Problembehandlung von "Hangs" und "Crashes"

   • Ereignis-ID 21006: Dieses Ereignis gibt an, dass Kommunikationsprobleme zwischen dem Agent und dem Verwaltungsserver bestehen. Wenn der Agent ein Zertifikat für die gegenseitige Authentifizierung verwendet, überprüfen Sie, ob das Zertifikat nicht abgelaufen ist und dass der Agent das richtige Zertifikat verwendet. Wenn Kerberos verwendet wird, stellen Sie sicher, dass der Agent mit Active Directory kommunizieren kann. Wenn die Authentifizierung ordnungsgemäß funktioniert, bedeutet dies möglicherweise, dass die Pakete des Agents nicht auf den Verwaltungsserver oder das Gateway gelangen. Versuchen Sie, ein Telnet zum Portieren von 5723 vom Agent zum Verwaltungsserver einzurichten. Führen Sie außerdem eine gleichzeitige Netzwerkablaufverfolgung zwischen dem Agent und dem Verwaltungsserver aus, während Sie die Kommunikationsfehler reproduzieren. Auf diese Weise können Sie ermitteln, ob die Pakete den Verwaltungsserver erreichen und ob ein Gerät zwischen den beiden Komponenten versucht, den Datenverkehr zu optimieren oder einige Pakete zu löschen. Weitere Informationen finden Sie unter "Sammeln von Daten mithilfe des Netzwerkmonitors".

   • Ereignis-ID 623: Dieses Ereignis tritt in der Regel in einer großen Operations Manager-Umgebung auf, in der ein Verwaltungsserver oder ein Agentcomputer viele Workflows verwaltet. Weitere Informationen finden Sie unter Mindestens einen Verwaltungsserver, deren verwaltete Geräte in der Operations Manager-Konsole abgeblendet sind.

Szenario 3

Alle Agents, die einem bestimmten Verwaltungsserver oder Gateway melden, sind nicht verfügbar.

Lösung für Szenario 3

Führen Sie die folgenden Schritte aus, um das Problem in diesem Szenario zu beheben:

1. Versuchen Sie zu ermitteln, welche Art von Workloads der Verwaltungsserver oder das Gateway überwacht. Solche Workloads können Netzwerkgeräte, plattformübergreifende Agents, synthetische Transaktionen, Windows-Agents und agentlose Computer umfassen.

2. Ermitteln Sie, ob der Integritätsdienst auf dem Verwaltungsserver oder Gateway ausgeführt wird.

3. Ermitteln Sie, ob der Verwaltungsserver im Wartungsmodus ausgeführt wird. Wenn dies erforderlich ist, entfernen Sie den Server aus dem Wartungsmodus.

4. Untersuchen Sie das Operations Manager-Ereignisprotokoll beim Agent für alle Ereignisse, die in Szenario 2 aufgeführt sind. Wenn die Ereignis-ID 21006 vorhanden ist, befolgen Sie die gleichen Richtlinien, die in "Lösung für Szenario 2" erwähnt werden. Darüber hinaus gibt dieses Ereignis an, dass der Verwaltungsserver oder das Gateway nicht mit seinem übergeordneten Server kommunizieren kann. Für ein Gateway kann der übergeordnete Server ein beliebiger Verwaltungsserver sein. (Siehe Schritt 3 in der Auflösung für Szenario 2.)

5. Untersuchen Sie das Operations Manager-Ereignisprotokoll auf die folgenden Ereignisse. Diese Ereignisse deuten in der Regel darauf hin, dass Leistungsprobleme auf dem Verwaltungsserver oder microsoft SQL Server vorhanden sind, der die OperationsManager Datenbank OperationsManagerDW hosten soll:

   Ereignis-ID: 2115
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Eine Bindungsdatenquelle in der Verwaltungsgruppe "%1" hat Elemente in den Workflow gepostet, aber in %5 Sekunden keine Antwort erhalten. Dies weist auf ein Leistungs- oder Funktionsproblem mit dem Workflow hin.%n Workflow-ID: %2%n Instanz : %3%n Instanz-ID: %4%n

   Ereignis-ID: 5300
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Der lokale Integritätsdienst ist nicht fehlerfrei. Der Änderungsfluss des Entitätsstatus wird mit ausstehender Bestätigung angehalten. %n%nManagement-Gruppe: %2 %nManagement Gruppen-ID: %1

   Ereignis-ID: 4506
   Ereignisquelle: HealthService
   Ereignisbeschreibung: Operations Manager
   Die Daten wurden aufgrund zu viel ausstehender Daten in regel "%2" gelöscht, die z. B. "%3" mit der ID:"%4" in der Verwaltungsgruppe "%1" ausgeführt werden.

   Ereignis-ID: 31551
   Ereignisquelle: Integritätsdienst Module
   Ereignisbeschreibung:
   Fehler beim Speichern von Daten im Data Warehouse. Der Vorgang wird erneut ausgeführt.%rAusnahme '%5': %6 %n%nOne oder mehr Workflows wurden dadurch beeinflusst. %n%nWorkflowname: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

   Ereignis-ID: 31552
   Ereignisquelle: Integritätsdienst Module
   Ereignisbeschreibung:
   Fehler beim Speichern von Daten im Data Warehouse.%rAusnahme '%5': %6 %n%nOne oder mehr Workflows waren davon betroffen. %n%nWorkflowname: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

   Ereignis-ID: 31553
   Ereignisquelle: Integritätsdienst Module
   Ereignisbeschreibung:
   Die Daten wurden in den Data Warehouse-Stagingbereich geschrieben, die Verarbeitung ist jedoch bei einem der nachfolgenden Vorgänge fehlgeschlagen.%rAusnahme '%5': %6 %n%nOne oder mehr Workflows waren davon betroffen. %n%nWorkflowname: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

   Ereignis-ID: 31557
   Ereignisquelle: Integritätsdienst Module
   Ereignisbeschreibung:
   Fehler beim Abrufen von Synchronisierungsvorgangsstatusinformationen aus der Data Warehouse-Datenbank. Der Vorgang wird erneut ausgeführt.%rAusnahme '%5': %6 %n%nOne oder mehr Workflows wurden dadurch beeinflusst. %n%nWorkflowname: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

6. Ereignis-ID 3155X kann auch aufgrund falscher Run As-Kontokonfigurationen oder fehlender Berechtigungen für die Run As-Konten protokolliert werden.

Notiz

Informationen zur Problembehandlung bei der Verwaltungsserver- oder Gatewayleistung sowie zur SQL Server-Leistung finden Sie im Abschnitt "Lösung für Szenario 4 ".

Szenario 4

Alle Agents, die einen bestimmten Verwaltungsserver melden, wechseln zeitweise zwischen fehlerfreien und grauen Zuständen. Oder alle Agenten in der Umgebung wechseln zeitweise zwischen fehlerfreien und grauen Zuständen.

Lösung für Szenario 4

Um das Problem zu beheben, bestimmen Sie zuerst die Ursache des Problems. Häufige Ursachen für die Nichtverfügbarkeit des temporären Servers sind die folgenden:

• Der übergeordnete Server der Agents ist vorübergehend offline.
• Agents überfluten den Verwaltungsserver mit Betriebsdaten, z. B. Warnungen, Zustände, Entdeckungen usw. Dies kann zu einer erhöhten Verwendung von Systemressourcen in der Operations Manager-Datenbank und auf den Operations Manager-Servern führen.
• Netzwerkausfälle verursachten einen temporären Kommunikationsfehler zwischen dem übergeordneten Server und den Agents.
• Änderungen des Management Packs (MP) sind aufgetreten. In der Operations Manager-Konsole erfordern diese Änderungen eine Operations Manager-Konfiguration und eine MP-Umverteilung an die Agents. Wenn sich die Änderung auf eine größere Agentbasis auswirkt, kann dies zu einer erhöhten Nutzung der Systemressourcen auf den Operations Manager-Datenbank- und Operations Manager-Servern führen.

Der Schlüssel zur Problembehandlung in diesen Szenarien besteht darin, die Dauer der Nichtverfügbarkeit des Servers und die Tageszeit zu verstehen, zu der er aufgetreten ist. Dies hilft Ihnen, den Umfang des Problems schnell einzugrenzen.

Problembehandlung bei Verwaltungsserver und Gatewayleistung

Verwaltungsserver

Während eines Konfigurationsupdate-Bursts (das durch MP-Import und -Ermittlung verursacht wird), sind die typischen Engpässe zuerst, die CPU und die zweite, die Operations Manager-Installationsdatenträger-E/A. Der Verwaltungsserver dient der Weiterleitung von Konfigurationsdateien an die Ziel-Agents.

Für die Betriebsdatensammlung werden Engpässe in der Regel durch die CPU verursacht. Die Eingabe/Ausgabe des Datenträgers kann auch die maximale Kapazität erreicht haben, was aber nicht sehr wahrscheinlich ist. Der Verwaltungsserver ist verantwortlich für die Dekomprimierung und Entschlüsselung eingehender Betriebsdaten und das Einfügen in die Betriebsdatenbank. Außerdem sendet er Bestätigungen (ACKs) zurück an die Agents oder Gateways, nachdem er betriebsbezogene Daten empfängt, und verwendet Datenträger-Queuing, um diese ausgehenden ACKs vorübergehend zu speichern.

Gateway

Das Gateway ist sowohl CPU-gebunden als auch E/A-gebunden. Wenn das Gateway eine große Datenmenge weitergibt, können sowohl die CPU- als auch die E/A-Vorgänge eine hohe Auslastung aufweisen. Der Großteil der CPU-Auslastung wird durch die Dekomprimierung, Komprimierung, Verschlüsselung und Entschlüsselung der eingehenden Daten sowie durch die Übertragung dieser Daten verursacht. Alle Daten, die vom Gateway und von den Agents empfangen werden, werden in einer beständigen Warteschlange auf dem Datenträger gespeichert, die vom Gatewaystatusdienst an den Verwaltungsserver gelesen und weitergeleitet werden sollen. Dies kann zu einer hohen Datenträgerauslastung führen. Diese Verwendung kann erheblich sein, wenn das Gateway vorübergehend offline genommen wird und dann gesammelte Agentdaten verarbeiten muss, die die Agents generiert und versucht haben, zu senden, wenn das Gateway noch offline war.

Um das Problem in dieser Situation zu beheben, sammeln Sie die folgenden Informationen für jeden betroffenen Management Server oder Gateway:

• Genaue Windows-Version, Edition und Buildnummer

• Anzahl der Prozessoren

• Größe des RAM

• Laufwerk, das den Ordner "Integritätsdienst Status" enthält

• Gibt an, ob die Antivirensoftware so konfiguriert ist, dass der Integritätsdienst Store ausgeschlossen wird.

  Notiz

  Weitere Informationen finden Sie unter Empfehlungen für Antivirenausschlüsse, die sich auf Operations Manager beziehen.

• RAID-Ebene (0, 1, 5oder 1+00+1 ) für das Laufwerk, das vom Integritätsdienst State verwendet wird

• Anzahl der Datenträger, die für das RAID verwendet werden

• Gibt an, ob der akkugestützte Schreibcache auf dem Arraycontroller aktiviert ist.

Behandeln von Problemen mit der SQL Server-Leistung

Betriebsdatenbank (OperationsManager)

Bei der Datenbank von OperationsManager ist der wahrscheinlichste Engpass das Datenträgerarray. Wenn das Datenträgerarray nicht die maximale E/A-Kapazität erreicht, ist der nächste Engpass höchstwahrscheinlich die CPU. In der Datenbank kommt es gelegentlich zu Verlangsamungen und betrieblichen Datenstürmen (häufiges Auftreten von Ereignissen, Warnungen, Leistungsdaten oder Statusänderungen, die relativ lange andauern). Ein kurzer Burst verursacht in der Regel keine nennenswerte Verzögerung über einen längeren Zeitraum.

Während der operativen Dateneingabe werden die Datenbankfestplatten hauptsächlich für Schreibvorgänge verwendet. Die CPU-Auslastung wird durch SQL Server Churn verursacht. Dies kann vorkommen, wenn Sie große und komplexe Abfragen durchführen, viele Daten einfügen und große Tabellen bereinigen (was standardmäßig um Mitternacht geschieht). In der Regel verbraucht die Bereinigung selbst großer Ereignisse und umfangreichen Leistungsdatentabellen keine übermäßigen CPU- oder Festplattenressourcen. Allerdings kann die Bereinigung der Tabellen für Warnungen und Statusänderungen bei großen Tabellen CPU-intensiv sein.

Die Datenbank ist auch CPU-gebunden, wenn sie Konfigurationsumverteilungen verarbeitet, die durch MP-Importe oder eine große Änderung des Instance-Spaces verursacht werden. In diesen Fällen fragt der Config-Dienst die Datenbank nach einer neuen Agent-Konfiguration ab. Dadurch kommt es in der Regel zu CPU-Spitzen in der Datenbank, bevor der Dienst die Konfigurationsaktualisierungen an die Agents sendet.

Data Warehouse (OperationsManagerDW)

Bei der Datenbank von OperationsManagerDW ist der wahrscheinlichste Engpass das Datenträgerarray. Dies geschieht in der Regel aufgrund großer operativer Dateneingaben. In diesen Fällen sind die Datenträger hauptsächlich mit Schreibvorgängen beschäftigt. Normalerweise werden auf dem Datenträger nur wenige Lesevorgänge durchgeführt, außer für manuell erstellte Berichtsansichten, da diese Abfragen auf dem Data Warehouse ausführen.

Die CPU-Auslastung wird durch SQL Server verursacht. CPU-Spitzen können bei starken Partitionierungsaktivitäten (wenn Tabellen groß werden und dann partitioniert werden), bei der Erstellung komplexer Berichte und bei großen Mengen von Warnmeldungen in der Datenbank auftreten, mit denen das Data Warehouse ständig synchronisiert werden muss.

Allgemeine Problembehandlung

Um das Problem in dieser Situation zu beheben, sammeln Sie die folgenden Informationen für jeden betroffenen Management Server oder Gateway:

• Genaue Windows-Version, Edition und Buildnummer

• Anzahl der Prozessoren

• Größe des RAM

• Größe des Arbeitsspeichers, die SQL Server zugewiesen wird

• Egal, ob SQL Server 32-Bit ist und AWE aktiviert ist

  Die meisten dieser Informationen finden Sie im SQL Server Management Studio oder im SQL Server Enterprise Manager. Öffnen Sie dazu das Fenster Eigenschaften des Servers, und wählen Sie dann die Registerkarten Allgemein und Arbeitsspeicher aus. Die Registerkarte Allgemein enthält die SQL Server-Version, die Windows-Version, die Plattform, die Größe des RAM und die Anzahl der Prozessoren. Die Registerkarte Arbeitsspeicher enthält die Speichermenge, die dem SQL Server zugewiesen ist. In Microsoft SQL Server 2008 enthält die Registerkarte Arbeitsspeicher auch die Option AWE.

  Wenn es sich um ein 32-Bit-Betriebssystem mit 4 GB oder mehr RAM handelt, überprüfen Sie das Vorhandensein der Weichen /pae oder /3gb in Boot.ini. hinzu. Diese Optionen könnten falsch konfiguriert sein, wenn der Server ursprünglich mit 4 GB oder weniger RAM installiert wurde und wenn der RAM später aufgerüstet wurde.

  Bei 32-Bit-Servern, die über 4 GB RAM verfügen, erhöht die Weiche /3gb in Boot.ini die Größe des Arbeitsspeichers, die SQL Server ansteuern kann (von 2 GB auf 3 GB). Bei 32-Bit-Servern, die über mehr als 4 GB RAM verfügen, könnte die Weiche /3gb in Boot.ini tatsächlich die Größe des Arbeitsspeichers begrenzen, die SQL Server ansteuern kann. Fügen Sie für diese Systeme die Weiche /pae in Boot.ini hinzu und aktivieren Sie dann AWE in SQL Server.

  Überprüfen Sie auf einem Multiprozessorsystem die Einstellung Max Degree of Parallelism (MAXDOP) . In SQL Server 2008 finden Sie diese Option auf der Registerkarte Erweitert im Dialogfeld Eigenschaften des Servers.

  Der Standardwert ist 0, was bedeutet, dass alle verfügbaren Prozessoren verwendet werden. Eine Einstellung von 0 ist für Server mit acht oder weniger Prozessoren in Ordnung. Bei Servern mit mehr als acht Prozessoren kann die Zeit, die SQL Server benötigt, um die Nutzung aller Prozessoren zu koordinieren, kontraproduktiv sein. Daher sollten Sie bei Servern mit mehr als acht Prozessoren den Max Degree of Parallelism in der Regel auf einen Wert von 8 setzen. Führen Sie dazu den folgenden Befehl im SQL Query Analyzer aus:

  sp_configure 'show advanced options', 1
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  sp_configure 'max degree of parallelism', 8
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  

• Laufwerkbuchstaben, die Data Warehouse-, Operations Manager DB- und Tempdb-Dateien enthalten

• Ist die Antiviren-Software so konfiguriert ist, dass SQL-Daten und Protokolldateien ausgeschlossen werden? (Das Scannen von SQL Server-Datenbankdateien mit Antiviren-Software kann die Leistung beeinträchtigen)

• Freier Speicherplatz auf Laufwerken, die Data Warehouse-, Operations Manager DB- und Tempdb-Dateien enthalten

• Speichertyp (SAN oder lokal)

• RAID-Ebene (0, 1, 5, 0+1 oder 1+0) für Laufwerke, die von SQL Server verwendet werden

• Wenn SAN-Speicher verwendet wird: Anzahl der Spindeln auf jeder LUN, die von SQL Server verwendet wird

• Wenn das konvertierte Exchange 2007 Management Pack verwendet wird oder jemals verwendet wurde: Anzahl der Zeilen in der Tabelle in der LocalizedText Operations Manager-Datenbank und in der EventPublisher Tabelle in der Data Warehouse-Datenbank

  Um die Zeilenmenge zu ermitteln, führen Sie die folgenden Befehle aus:

  USE OperationsManager SELECT COUNT(*) FROM LocalizedText
  USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher
  

Leistungsindikatoren zur Ermittlung des Arbeitsspeicherdrucks

Name des Leistungsindikators	Beschreibung
MSSQL$<instance>: Puffer-Manager: Seitenlebensdauer	Wie lange Seiten im Pufferpool beibehalten werden. Wenn dieser Wert unter 300 Sekunden liegt, bedeutet dies möglicherweise, dass der Server mehr Arbeitsspeicher verwenden könnte. Es könnte auch eine Folge der Indexfragmentierung sein.
MSSQL$<instance>: Puffer-Manager: Lazy writes/sec	Verzögerter Schreibvorgang gibt den Platz im Puffer frei, indem er Seiten auf den Datenträger verschiebt. Im Allgemeinen sollte der Wert 20 Schreibvorgänge pro Sekunde nicht übersteigen. Idealerweise steht er nahe null.
Arbeitsspeicher: Verfügbare Mbytes	Werte unter 100 MB können ein Hinweis auf Speicherdruck sein. Wenn dieser Wert weniger als 10 MB beträgt, besteht eindeutig ein Speicherdruck.
Prozess: Private Bytes: _Total	Dies ist die Menge an Arbeitsspeicher (physischer Speicher und Seitenspeicher), die von allen Prozessen zusammen belegt wird.
Prozess: Working Set: _Total	Dies ist die Menge des physischen Arbeitsspeichers, die von allen Prozessen zusammen belegt wird. Wenn der Wert für diesen Zähler deutlich unter dem Wert für Process: Private Bytes: _Total liegt, deutet dies darauf hin, dass die Prozesse zu stark ausgelagert werden. Ein Unterschied von mehr als 10 % ist wahrscheinlich erheblich.

Zähler zur Ermittlung des Datenträgerdrucks

Erfassen Sie diese physischen Datenträgerzähler für alle Laufwerke, die SQL-Daten oder Protokolldateien enthalten:

• % Leerlaufzeit: Wie viel Leerlaufzeit für die Datenträger gemeldet wird. Alles, was unter 50 Prozent liegt, könnte auf einen Engpass des Datenträgers hindeuten.

• Durchschn. Datenträger-Warteschlangenlänge: Dieser Wert sollte das Doppelte der Anzahl der Spindeln auf einer LUN nicht überschreiten. Wenn eine LUN z. B. 25 Spindeln aufweist, ist ein Wert von 50 akzeptabel. Wenn eine LUN jedoch 10 Spindeln hat, ist ein Wert von 25 zu hoch. Sie können die folgenden Formeln verwenden, die auf der RAID-Ebene und der Anzahl der Datenträger in der RAID-Konfiguration basieren:

  • RAID 0: Alle Datenträger arbeiten in einem RAID 0-Satz

  • Durchschnittliche Länge der< Datenträgerwarteschlange= # (Datenträger im Array) *2

  • RAID 1: Die Hälfte der Datenträger arbeitet; daher kann nur die Hälfte davon als Datenträgerwarteschlange gezählt werden

  • Durchschnittliche Datenträgerwarteschlangenlänge<= # (Datenträger im Array/2) *2

  • RAID 10: Die Hälfte der Datenträger arbeiten; daher kann nur die Hälfte davon als Datenträgerwarteschlange gezählt werden

  • Durchschnittliche Datenträgerwarteschlangenlänge<= # (Datenträger im Array/2) *2

  • RAID 5: Alle Datenträger arbeiten in einem RAID 5-Satz

  • Durchschnittliche Datenträgerwarteschlangenlänge<= # Datenträger im Array *2

  • Durchschn. Sek./Übertragung: Die Anzahl der Sekunden, die benötigt werden, um eine Datenträger-E/A abzuschließen

  • Durchschn. Sek./Lesevorgang: Die durchschnittliche Zeit, in Sekunden, um Daten vom Datenträger zu lesen

  • Durchschn. Sek./Schreibvorgang: Die durchschnittliche Zeit, in Sekunden, um Daten auf den Datenträger zu schreiben

    Die letzten drei Zähler in dieser Liste sollten durchgängig Werte von etwa 0,020 (20 ms) oder weniger aufweisen und niemals 0,050 (50 ms) überschreiten. Im Folgenden finden Sie die Schwellenwerte, die im Handbuch zur Problembehandlung bei SQL Server-Leistung dokumentiert sind:

    • Weniger als 10 ms: sehr gut
    • Zwischen 10 und 20 ms: okay
    • Zwischen 20 und 50 ms: langsam, erfordert Beachtung
    • Mehr als 50 ms: ernster E/A-Engpass

  • Datenträger Bytes/Sek. : Die Anzahl der Bytes, die pro Sekunde auf den oder vom Datenträger übertragen werden

  • Datenträger Übertragungen/Sek. : Die Anzahl der Ein- und Ausgabevorgänge pro Sekunde (IOPS)

  Wenn % Leerlaufzeit niedrig ist (10 Prozent oder weniger), bedeutet dies, dass der Datenträger vollständig genutzt wird. In diesem Fall liefern die letzten beiden Zähler in dieser Liste (Datenträger Bytes/Sek. und Datenträger Übertragungen/Sek. ) einen guten Hinweis auf den maximalen Durchsatz des Datenträgers in Bytes bzw. in IOPS. Der Durchsatz eines SAN-Laufwerks ist sehr unterschiedlich und hängt von der Anzahl der Spindeln, der Geschwindigkeit der Laufwerke und der Geschwindigkeit des Kanals ab. Die beste Wahl besteht darin, sich über den SAN-Anbieter zu informieren, wie viele Bytes und IOPS das Laufwerk unterstützen sollte. Wenn % Leerlaufzeit niedrig ist und die Werte für diese beiden Zähler nicht dem erwarteten Durchsatz des Laufwerks entsprechen, bitten Sie den SAN-Anbieter um weitere Hilfe bei der Problembehandlung.

Handbuch zur Problembehandlung bei SQL Server-Leistung bietet einen tieferen Einblick in die Problembehandlung bei der SQL Server-Leistung.

Operations Manager-Leistungsindikatoren

In den folgenden Abschnitten werden die Leistungsindikatoren beschrieben, die Sie verwenden können, um die Leistung von Operations Manager zu überwachen und zu beheben.

Gatewayserverrolle

Leistungsindikatoren insgesamt

Diese Leistungsindikatoren geben die Gesamtleistung des Gateways an:

Name des Leistungsindikators
Processor(_Total)\% Processor Time
Arbeitsspeicher\% Zugesicherte verwendete Bytes
Netzwerkschnittstelle(*)\Bytes gesamt/s
LogicalDisk(*)\% Leerlaufzeit
LogicalDisk(*)\avg. Datenträgerwarteschlangenlänge

Allgemeine Leistungsindikatoren des Operations Manager-Prozesses

Diese Leistungsindikatoren geben die Gesamtleistung von Operations Manager-Prozessen auf dem Gateway an:

Name des Leistungsindikators	Beschreibung
Process(HealthService)\% Prozessorzeit
Prozess(HealthService)\Private Bytes	Je nachdem, wie viele Agents dieses Gateway verwaltet, kann diese Zahl variieren und mehrere hundert Megabyte sein.
Process(HealthService)\Threadanzahl
Process(HealthService)\Virtuelle Bytes
Process(HealthService)\Arbeitssatz
Process(MonitoringHost*)\% Prozessorzeit
Prozess(MonitoringHost*)\Private Bytes
Prozess(MonitoringHost*)\Threadanzahl
Process(MonitoringHost*)\Virtuelle Bytes
Process(MonitoringHost*)\Arbeitssatz

Für Operations Manager spezifische Leistungsindikatoren

Diese Leistungsindikatoren sind operations Manager-spezifische Indikatoren, die die Leistung bestimmter Aspekte von Operations Manager auf dem Gateway angeben:

Name des Leistungsindikators	BESCHREIBUNG
Integritätsdienst\Workflowanzahl
Integritätsdienst-Verwaltungsgruppen(*)\Aktive Dateiuploads	Die Anzahl der Dateiübertragungen, die dieses Gateway verarbeitet. Dies stellt die Anzahl der Management Pack-Dateien dar, die in Agents hochgeladen werden. Wenn dieser Wert lange hoch bleibt und zu einem bestimmten Zeitpunkt nicht viele Management Pack importiert werden, können diese Bedingungen ein Problem generieren, das sich auf die Dateiübertragung auswirkt.
Integritätsdienst-Verwaltungsgruppen(*)\Genutzte Prozent der Sendewarteschlange	Die Größe der beständigen Warteschlange. Wenn dieser Wert für lange Zeit höher als 10 bleibt und nicht fällt, ist dies ein Hinweis darauf, dass die Warteschlange voll ist. Diese Bedingung wird durch ein überlastetes Operations Manager-System verursacht, da der Verwaltungsserver oder die Datenbank zu ausgelastet oder offline ist.
OpsMgr Connector\Empfangene Bytes	Die Anzahl der vom Gateway empfangenen Netzwerkbytes , d. h. die Anzahl der eingehenden Bytes vor der Dekomprimierung.
OpsMgr Connector\Übertragene Bytes	Die Anzahl der Netzwerkbytes, die vom Gateway gesendet werden , d. h. die Anzahl ausgehender Bytes nach der Komprimierung.
OpsMgr Connector\Empfangene Datenbytes	Die Anzahl der vom Gateway empfangenen Datenbytes , d. h. die Menge der eingehenden Daten nach der Dekomprimierung.
OpsMgr Connector\Übertragene Datenbytes	Die Anzahl der vom Gateway gesendeten Datenbytes , d. h. die Menge ausgehender Daten vor der Komprimierung.
OpsMgr Connector\Geöffnete Verbindungen	Die Anzahl der Verbindungen, die auf dem Gateway geöffnet sind. Diese Nummer sollte mit der Anzahl der Agents oder Verwaltungsserver identisch sein, die direkt mit dem Gateway verbunden sind.

Verwaltungsserverrolle

Leistungsindikatoren insgesamt

Diese Leistungsindikatoren geben die Gesamtleistung des Verwaltungsservers an:

Name des Leistungsindikators
Processor(_Total)\% Processor Time
Arbeitsspeicher\% Zugesicherte verwendete Bytes
Netzwerkschnittstelle(*)\Bytes gesamt/s
LogicalDisk(*)\% Leerlaufzeit
LogicalDisk(*)\avg. Datenträgerwarteschlangenlänge

Allgemeine Leistungsindikatoren des Operations Manager-Prozesses

Diese Indikatoren geben die Gesamtleistung von Operations Manager-Prozessen auf dem Verwaltungsserver an:

Name des Leistungsindikators	Beschreibung
Process(HealthService)\% Prozessorzeit
Prozess(HealthService)\Private Bytes	Je nachdem, wie viele Agents dieser Verwaltungsserver verwaltet, kann diese Zahl variieren, und es könnte sich um mehrere hundert Megabytes handeln.
Process(HealthService)\Threadanzahl
Process(HealthService)\Virtuelle Bytes
Process(HealthService)\Arbeitssatz
Process(MonitoringHost*)\% Prozessorzeit
Prozess(MonitoringHost*)\Private Bytes
Prozess(MonitoringHost*)\Threadanzahl
Process(MonitoringHost*)\Virtuelle Bytes
Process(MonitoringHost*)\Arbeitssatz

Für Operations Manager spezifische Leistungsindikatoren

Diese Indikatoren sind spezifische Indikatoren für Operations Manager, die die Leistung bestimmter Aspekte von Operations Manager auf dem Verwaltungsserver angeben:

Name des Leistungsindikators	BESCHREIBUNG
Integritätsdienst\Workflowanzahl	Die Anzahl der Workflows, die auf diesem Verwaltungsserver ausgeführt werden.
Integritätsdienst-Verwaltungsgruppen(*)\Aktive Dateiuploads	Die Anzahl der Dateiübertragungen, die dieser Verwaltungsserver verarbeitet. Dies stellt die Anzahl der Management Pack-Dateien dar, die in Agents hochgeladen werden. Wenn dieser Wert lange hoch bleibt und zu einem bestimmten Zeitpunkt nicht viele Management Pack importiert werden, können diese Bedingungen ein Problem generieren, das sich auf die Dateiübertragung auswirkt.
Integritätsdienst-Verwaltungsgruppen(*)\Genutzte Prozent der Sendewarteschlange	Die Größe der dauerhaften Warteschlange. Wenn dieser Wert für lange Zeit höher als 10 bleibt und nicht fällt, ist dies ein Hinweis darauf, dass die Warteschlange voll ist. Diese Bedingung wird durch ein überladenes Operations Manager-System verursacht, da das Operations Manager-System (z. B. der Stammverwaltungsserver) zu stark ausgelastet oder offline ist.
Integritätsdienst-Verwaltungsgruppen(*)\Rate verworfener Elemente der Bindungsdatenquelle	Die Anzahl der Datenelemente, die vom Verwaltungsserver für Schreibaktionen in der Datensammlung der Datenbank oder des Data Warehouse gelöscht werden. Wenn dieser Leistungsindikatorwert nicht 0ist, wird der Verwaltungsserver oder die Datenbank überlastet, da es das eingehende Datenelement nicht schnell genug verarbeiten kann oder weil ein Datenelement platzt. Die verworfenen Datenelemente werden von Agents erneut zurückgesendet. Nach Abschluss der Überladung oder der Burst-Situation werden diese Datenelemente in die Datenbank oder das Data Warehouse eingefügt.
Integritätsdienst-Verwaltungsgruppen(*)\Rate eingehender Elemente der Bindungsdatenquelle	Die Anzahl der Datenelemente, die vom Verwaltungsserver für Schreibaktionen in der Datensammlung der Datenbank oder des Data Warehouse empfangen werden.
Integritätsdienst-Verwaltungsgruppen(*)\Rate bereitgestellter Elemente der Bindungsdatenquelle	Die Anzahl der Datenelemente, die der Verwaltungsserver für Schreibaktionen in der Datensammlung an die Datenbank oder das Data Warehouse geschrieben werden.
OpsMgr Connector\Empfangene Bytes	Die Anzahl der vom Verwaltungsserver empfangenen Netzwerkbytes – d. h., die Größe eingehender Bytes vor der Dekomprimierung.
OpsMgr Connector\Übertragene Bytes	Die Anzahl der vom Verwaltungsserver gesendeten Netzwerkbytes – d. h., die Größe ausgehender Bytes nach der Komprimierung.
OpsMgr Connector\Empfangene Datenbytes	Die Anzahl der vom Verwaltungsserver empfangenen Datenbytes , d. h. die Größe eingehender Daten nach dekomprimieren.
OpsMgr Connector\Übertragene Datenbytes	Die Anzahl der vom Verwaltungsserver gesendeten Datenbytes , d. h. die Größe ausgehender Daten vor der Komprimierung.
OpsMgr Connector\Geöffnete Verbindungen	Die Anzahl der Verbindungen, die auf dem Verwaltungsserver geöffnet sind. Sie sollte identisch mit der Anzahl an Agents oder Stammverwaltungsservern sein, die direkt damit verbunden sind.
OpsMgr-Datenbank-Schreibaktionsmodule(*)\Durchschn. Batchgröße	Die Anzahl der Datenelemente oder Batches, die von Datenbank-Schreibaktionsmodulen empfangen werden. Wenn diese Zahl 5.000 ist, tritt ein Datenelement-Burst auf.
OpsMgr-DB-Schreibaktionsmodule(*)\Durchschn. Verarbeitungszeit	Die Anzahl an Sekunden, die ein Datenbank-Schreibaktionsmodul benötigt, um einen Batch in die Datenbank einzufügen. Wenn diese Zahl häufig größer als 60 ist, tritt ein Problem beim Einfügen in die Datenbank auf.
OpsMgr-DW-Schreibmodul(*)\Durchschn. Batchverarbeitungszeit, ms	Die Anzahl der Millisekunden, die eine Data Warehouse-Schreibaktion zum Einfügen eines Batches von Datenelementen in ein Data Warehouse benötigt.
OpsMgr-DW-Schreibmodul(*)\Durchschn. Batchgröße	Die durchschnittliche Anzahl von Datenelementen oder Batches, die von Data Warehouse-Schreibaktionsmodulen empfangen werden.
OpsMgr-DW-Schreibmodul(*)\Batches/Sek.	Die Anzahl der von Data Warehouse-Schreibaktionsmodulen empfangenen Batches pro Sekunde.
OpsMgr-DW-Schreibmodul(*)\Datenelemente/Sek.	Die Anzahl der von Data Warehouse-Schreibaktionsmodulen empfangenen Datenelementen pro Sekunde.
OpsMgr-DW-Schreibmodul(*)\Anzahl verworfener Datenelemente	Die Anzahl der von Data Warehouse-Schreibaktionsmodulen verworfenen Datenelementen.
OpsMgr-DW-Schreibmodul(*)\Gesamtfehlerzahl	Die Anzahl der Fehler, die in einem Data Warehouse-Schreibaktionsmodul aufgetreten sind.