Erkennen und Behandeln von Problemen mit häufigen Konfigurationsänderungen in Operations Manager

Artikel
04/15/2024

In diesem Artikel wird erläutert, wie Sie häufige Konfigurationsänderungen in System Center Operations Manager erkennen und behandeln.

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

Übersicht über die Konfiguration

Der System Center-Verwaltungskonfigurationsdienst ist für die Berechnung der Konfiguration jedes Integritätsdiensts in der Operations Manager-Verwaltungsgruppe zuständig. Die Konfiguration eines Integritätsdiensts besteht aus den Regeln, Monitoren, Ermittlungen und Aufgaben für den Integritätsdienst und für alle Instanzen, die der Integritätsdienst überwacht.

Um alle erforderlichen Konfigurationen für jeden Integritätsdienst zu berechnen, muss der Verwaltungskonfigurationsdienst über eine Liste der folgenden Elemente verfügen:

Alle Instanzen aller überwachten Klassen
Die Hostingbeziehungen zwischen Instanzen
Regeln, Monitore, Ermittlungen und andere Workflows, die den überwachten Klassen zugewiesen sind
Die Integritätsdienste, die für die Überwachung der Instanzen verantwortlich sind

Darüber hinaus muss der Verwaltungskonfigurationsdienst in der Lage sein, die Mitgliedschaft aller instance Gruppen in der Verwaltungsgruppe zu lesen. Der Verwaltungskonfigurationsdienst muss auch alle Außerkraftsetzungen für Regeln und Monitore anwenden, die auf diese Gruppen, Klassen oder einzelnen Instanzen ausgerichtet sind.

Objekte in einer Verwaltungsgruppe werden basierend auf Ermittlungsdaten, die von Ermittlungsworkflows übermittelt werden, als Instanzen überwachter Klassen definiert. Wenn sich eine Schlüsseleigenschaft eines Objekts ändert, kann dieses Objekt als neue instance einer überwachten Klasse hinzugefügt werden. Andernfalls gilt dieses Objekt nicht mehr als instance dieser Klasse.

Wenn sich die Liste für die Klassen ändert, in denen das Objekt mitglied ist, ändert sich auch die Konfiguration für den Integritätsdienst, der dieses Objekt überwacht. Diese Änderungen treten auf, wenn Regeln, Monitore, Ermittlungen, Aufgaben und Außerkraftsetzungen der vorherigen Konfiguration hinzugefügt oder entfernt werden.

Änderung der Konfiguration

Agents können in den folgenden Szenarien möglicherweise keine stabile Konfiguration empfangen:

Eine große Menge von Ermittlungsdaten wird an den Verwaltungskonfigurationsdienst übermittelt.
Ermittlungsdaten werden zu schnell übermittelt, damit der Verwaltungskonfigurationsdienst verarbeitet werden kann, bevor weitere Ermittlungsdaten übermittelt werden. Dieses Szenario tritt auf, weil die Daten immer gerade berechnet werden.

Die häufige Übermittlung von Ermittlungsdaten, auch als Konfigurationsänderung bezeichnet, kann dazu führen, dass einige Integritätsdienste unter alten Konfigurationen ausgeführt werden oder die Konfiguration von Verwaltungsservern veraltet wird. Dieses Verhalten führt dann dazu, dass einige Integritätsdienste in der Betriebskonsole abgeblendet (nicht verfügbar) angezeigt werden.

Ermittlungsdaten werden von einem Integritätsdienst übermittelt, wenn ein Ermittlungsworkflow ausgeführt wird. Die Einführung eines neuen Management Packs in eine Verwaltungsgruppe kann dazu führen, dass auf jedem Agent mehrere Ermittlungsworkflows ausgeführt werden. Und wenn neue Instanzen erkannt werden, können zusätzliche Ermittlungen auf einigen Agents ausgeführt werden. Änderungen an Gruppen, Außerkraftsetzungen und anderen Workflows können dazu führen, dass Ermittlungsworkflows auf Agents ausgeführt werden. Außerdem kann die Einführung neuer Agents dazu führen, dass der Verwaltungskonfigurationsdienst den instance Speicherplatz mithilfe der Konfiguration des neuen Agents aktualisiert.

Der Konfigurationsverwaltungsdienst muss die Integritätsdienstkonfiguration in den folgenden Szenarien häufig neu berechnen:

Ein Ermittlungsworkflow ist so konfiguriert, dass er zu häufig ausgeführt wird.
Die eigenschaften, die vom Workflow ermittelt werden, ändern sich jedes Mal, wenn der Ermittlungsworkflow ausgeführt wird.

Wenn diese Szenarien für viele Agents auftreten oder Verwaltungsserver bereits eine hohe Workload aufweisen, kann der Konfigurationsverwaltungsdienst möglicherweise nicht mit der Änderungsrate Schritt halten, und es kann zu Konfigurationsänderungen kommen.

Identifizieren von Konfigurationsänderungsänderungen mithilfe des Ereignisprotokolls des Verwaltungsservers

Ein Ereignis, das dem folgenden im Operations Manager-Ereignisprotokoll auf dem Verwaltungsserver ähnelt, gibt an, dass sich die Konfiguration der Verwaltungsgruppe aufgrund neuer Ermittlungsdaten geändert hat:

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Ereignis-ID: 21024
Ebene: Informationen
Computer: <Name>
Beschreibung:
Die Konfiguration von OpsMgr ist für die Verwaltungsgruppe <ManagementGroupName> möglicherweise veraltet und hat eine aktualisierte Konfiguration vom Konfigurationsdienst angefordert. Das Aktuelle (veraltete) Statuscookies ist "3A B0 1E 5C 81 F3 12 F5 56 B7 8A EF F8 01 BA 09 86 55 06 48 "

Ein Ereignis, das dem folgenden ähnelt, gibt an, dass der Verwaltungskonfigurationsdienst die Verarbeitung der neuen Ermittlungsdaten abgeschlossen und alle Änderungen berechnet hat, die an der Konfiguration der Verwaltungsgruppe erforderlich sind, basierend auf den neuen Daten:

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Ereignis-ID: 21025
Ebene: Informationen
Computer: <Name>
Beschreibung:
OpsMgr hat eine neue Konfiguration für die Verwaltungsgruppe <ManagementGroupName> vom Konfigurationsdienst erhalten. Das neue Status-Cookie ist "34 FA 11 61 4D B8 03 59 3D 1D 66 B7 83 F3 C0 AA 7A 6F 1A 3B "

In einer typischen Umgebung sollte auf jedes Ereignis 21024 das Ereignis 21025 folgen. Wenn sich aufgrund der Ermittlungsdaten keine Konfigurationsdaten geändert haben, lautet die Ereignis-ID stattdessen 21026. In einer großen Verwaltungsgruppe sollten Paare von Ereignissen vom Typ 21024 und 21025 oder 21026 erwartet werden, dass sie mehrmals pro Stunde auftreten. Lange Zeichenfolgen mit 21024 Ereignissen ohne entsprechendes 21025- oder 21026-Ereignis sind ein Zeichen für eine Änderung der Konfiguration. Darüber hinaus kann im Ereignisprotokoll das folgende Ereignis angezeigt werden, das angibt, dass die Änderungsrate erkannt wurde:

Protokollname: Operations Manager
Quelle: OpsMgr Config Service
Ereignis-ID: 29202
Stufe: Warnung
Computer: <Name>
Beschreibung:
Der OpsMgr-Konfigurationsdienst konnte aufgrund zu häufiger Datenbankänderungen keinen konsistenten Zustand aus der OpsMgr-Datenbank abrufen.
Dies könnte auf einen normalen und vorübergehenden Anstieg der Ermittlungsdaten zurückzuführen sein. Überprüfen Sie jedoch die neuesten Änderungen, um festzustellen, ob dieser Anstieg unerwartet ist.
Letzte Änderung des Überwachungsobjekts:
Instanz = %1
Klasse = %2
Änderungszeit = %3
Letzte Änderung der Überwachungsbeziehung:
Beziehung instance = %4
Quelle instance = %5
Ziel instance = %6
RelationshipClass = %7
Änderungszeit = %8

Die Datenzugriffsebene muss mehrere Tabellen lesen, wenn die Datenzugriffsebene Änderungen abfragt. Wenn eine der Tabellen geändert wird, nachdem sie gelesen wurde, aber bevor alle Tabellen gelesen wurden, protokolliert die Datenzugriffsebene die vorherige Ereignis-ID 29202 und wiederholen Sie den Vorgang. Wenn eine Entität oder Beziehung instance während dieser Zeit gelesen wurde, sind Informationen zu diesen Instanzen in den Ereignisfeldern enthalten. Andernfalls bleiben diese Felder leer.

Identifizieren potenzieller Ursachen für Konfigurationsänderungen mithilfe des Operations Manager-Data Warehouse

In Verwaltungsgruppen, in denen die Operations Manager-Berichtskomponente installiert wurde, können mehrere SQL-Abfragen verwendet werden, um Workflows zu identifizieren, die häufige Änderungen übermitteln. Diese Abfragen sollten in SQL Server Management Studio für die Data Warehouse instance ausgeführt werden.

Gesamtanzahl der von Ermittlungsworkflows in den letzten 24 Stunden übermittelten Änderungen:

select
   ManagedEntityTypeSystemName,
   DiscoverySystemName,
   count(*) As 'Changes'
from
   (
      select distinct
         MP.ManagementPackSystemName,
         MET.ManagedEntityTypeSystemName,
         PropertySystemName,
         D.DiscoverySystemName,
         D.DiscoveryDefaultName,
         MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName',
         MET1.ManagedEntityTypeDefaultName As 'TargetTypeDefaultName',
         ME.Path,
         ME.Name,
         C.OldValue,
         C.NewValue,
         C.ChangeDateTime
      from
         dbo.vManagedEntityPropertyChange C
         inner join
            dbo.vManagedEntity ME
            on ME.ManagedEntityRowId = C.ManagedEntityRowId
         inner join
            dbo.vManagedEntityTypeProperty METP
            on METP.PropertyGuid = C.PropertyGuid
         inner join
            dbo.vManagedEntityType MET
            on MET.ManagedEntityTypeRowId = ME.ManagedEntityTypeRowId
         inner join
            dbo.vManagementPack MP
            on MP.ManagementPackRowId = MET.ManagementPackRowId
         inner join
            dbo.vManagementPackVersion MPV
            on MPV.ManagementPackRowId = MP.ManagementPackRowId
         left join
            dbo.vDiscoveryManagementPackVersion DMP
            on DMP.ManagementPackVersionRowId = MPV.ManagementPackVersionRowId
            AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%' + MET.ManagedEntityTypeSystemName + '%'
         left join
            dbo.vManagedEntityType MET1
            on MET1.ManagedEntityTypeRowId = DMP.TargetManagedEntityTypeRowId
         left join
            dbo.vDiscovery D
            on D.DiscoveryRowId = DMP.DiscoveryRowId
      where
         ChangeDateTime > dateadd(hh, - 24, getutcdate())
   )
   As # T
group by
   ManagedEntityTypeSystemName,
   DiscoverySystemName
order by
   count(*) DESC

Diese Abfrage erstellt drei Spalten. Die erste Spalte ist die Objektklasse, auf die der Workflow ausgerichtet ist. Die zweite Spalte gibt den internen Namen des Ermittlungsworkflows an. Die dritte Spalte gibt die Gesamtzahl der Eigenschaftsänderungen für alle Instanzen dieser Klasse an, die vom Workflow in den letzten 24 Stunden übermittelt wurden. Die Gesamtanzahl der Änderungen für alle Klassen stellt die Häufigkeit dar, mit der der Konfigurationsverwaltungsdienst die Konfiguration für einen Agent-Integritätsdienst neu berechnen muss.

Die Anzahl der Änderungen für einige Klassen von Objekten, selbst in einer stabilen Umgebung, kann niemals 0 (null) erreichen. Jede Änderung, z. B. das Hinzufügen oder Entfernen einer Eigenschaft, hinzugefügte oder außer Betrieb gesetzte Agents, hinzugefügte oder geänderte Serverrollen usw., werden in den zurückgegebenen Zahlen widergespiegelt. In Umgebungen, in denen Konfigurationsänderungen auftreten, weist ein oder mehrere Workflows wahrscheinlich einen größeren Wert als andere Workflows auf.

Eigenschaften wurden in den letzten 24 Stunden geändert:

select distinct
   MP.ManagementPackSystemName,
   MET.ManagedEntityTypeSystemName,
   PropertySystemName,
   D.DiscoverySystemName,
   D.DiscoveryDefaultName,
   MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName',
   MET1.ManagedEntityTypeDefaultName As 'TargetTypeDefaultName',
   ME.Path,
   ME.Name,
   C.OldValue,
   C.NewValue,
   C.ChangeDateTime
from
   dbo.vManagedEntityPropertyChange C
   inner join
      dbo.vManagedEntity ME
      on ME.ManagedEntityRowId = C.ManagedEntityRowId
   inner join
      dbo.vManagedEntityTypeProperty METP
      on METP.PropertyGuid = C.PropertyGuid
   inner join
      dbo.vManagedEntityType MET
      on MET.ManagedEntityTypeRowId = ME.ManagedEntityTypeRowId
   inner join
      dbo.vManagementPack MP
      on MP.ManagementPackRowId = MET.ManagementPackRowId
   inner join
      dbo.vManagementPackVersion MPV
      on MPV.ManagementPackRowId = MP.ManagementPackRowId
   left join
      dbo.vDiscoveryManagementPackVersion DMP
      on DMP.ManagementPackVersionRowId = MPV.ManagementPackVersionRowId
      AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%' + MET.ManagedEntityTypeSystemName + '%'
   left join
      dbo.vManagedEntityType MET1
      on MET1.ManagedEntityTypeRowId = DMP.TargetManagedEntityTypeRowId
   left join
      dbo.vDiscovery D
      on D.DiscoveryRowId = DMP.DiscoveryRowId
where
   ChangeDateTime > dateadd(hh, - 24, getutcdate())
ORDER BY
   MP.ManagementPackSystemName,
   MET.ManagedEntityTypeSystemName

Diese Abfrage kann ermitteln, welche Eigenschaften sich in den letzten 24 Stunden geändert haben. In Kombination mit der vorherigen Abfrage kann diese Abfrage anzeigen, was die alten und neuen Werte für die Eigenschaft waren, welche Agents die Änderung übermittelt haben, den Workflow, der die Ermittlung durchgeführt hat, und das Management Pack, in dem sie enthalten war.

Reduzieren der Konfigurationsänderungsänderung

Ältere Management Packs haben Ermittlungsworkflows eingeführt, die Eigenschaftsänderungen zu häufig übermittelt haben. Die aktuellen Versionen der meisten Management Packs haben diese Ermittlungsworkflows so geändert, dass daten seltener übermittelt werden, oder die Management Packs fragen keine flüchtigen Eigenschaften ab, die sich häufig ändern. Es wird empfohlen, Management Packs zu aktualisieren, die Workflows enthalten, die häufig in der vorherigen Abfrage auftreten.

Wenn keine neue Version des Management Packs verfügbar ist oder die neue Version jetzt nicht bereitgestellt werden kann, kann das Ermittlungsintervall mithilfe der Außerkraftsetzung so angepasst werden, dass es weniger häufig ausgeführt wird. Manchmal kann die Ermittlung, die für die Änderung der Konfiguration verantwortlich ist, durch Außerkraftsetzung deaktiviert werden. Wenn die Ermittlung für mehrere Wochen deaktiviert ist, werden die vom Workflow ermittelten Objekte möglicherweise aus der Datenbank entfernt. Das Deaktivieren der Ermittlung kann jedoch eine kurzfristige Problemumgehung bieten, um Konfigurationsänderungen zu vermeiden, solange eine permanente Lösung implementiert werden kann, bevor Objekte aus der Datenbank entfernt werden. Der Workflow kann auch für kurze Intervalle aktiviert werden, um die Objekte wiederzuentdecken, bevor sie optimiert werden.

Einige Workflows in diesen älteren Management Packs werden unter Was ist Konfigurationsänderung? erläutert.

Wenn der Workflow von einer benutzerdefinierten Ermittlung stammt, die auf eine flüchtige Eigenschaft abzielt, z. B. freier Speicherplatz, sollte die Ermittlung so umgeschrieben werden, dass sie nicht auf eine Eigenschaft abzielt, die sich häufig ändert. Ermittlungsworkflows sollten nicht auf Instanzen mit einer kurzen Lebensdauer (mehrere Wochen oder weniger) abzielen. Ermittlungsworkflows sollten keine Eigenschaften der Instanzen erfassen, die sich häufig ändern (einmal oder mehrmals pro Monat). Flüchtige Daten werden bei der Berechnung einer Konfiguration nicht berücksichtigt. Daher sollten flüchtige Daten durch Leistungsregeln und nicht durch Ermittlungsworkflows gesammelt werden.

Zusätzliche Leistungsoptimierung

In großen Verwaltungsgruppen (mehr als 1.000 Agents) kann der Stammverwaltungsserver (RMS) mit Vorgängen ausgelastet werden, die in der Regel in kleineren Verwaltungsgruppen kein Problem verursachen. In dieser Situation kann selbst eine geringe Anzahl von Eigenschaftsänderungen aufgrund der Zum Verarbeiten der Änderungen erforderlichen Zeit zu einer häufigen Änderung führen. Mehrere Konfigurationsänderungen können verwendet werden, um den Betriebsaufwand des RMS zu reduzieren und es zu ermöglichen, eine typische Rate von Eigenschaftsänderungen schnell genug zu verarbeiten, um Konfigurationsänderungen zu vermeiden. Diese Konfigurationsänderungen werden unter Leistungsoptimierungen für Operations Manager 2007 R2 und 2012 erläutert.

Konfigurationsänderung für die Verwaltungsgruppe erzwingen

Wenn die Konfigurationsänderung für die Verwaltungsgruppe ständig auftritt, werden alle Änderungen, um die Häufigkeit der Problemworkflows zu reduzieren oder die Problemworkflows zu deaktivieren, niemals an Agents weitergegeben. In diesem Fall muss der Fluss eingehender Ermittlungsdaten blockiert werden, damit der System Center Configuration Management-Dienst eine aktuelle Konfiguration berechnen kann, in der der Workflow, der diese Daten erzeugt, deaktiviert oder seltener ausgeführt wird.

Ermittlungsdaten werden über system OperationsManager Center Data Access Service (DAS) an die Datenbank übermittelt. Die Daten werden zuerst vom System Center-Verwaltungsdienst auf dem RMS an das DAS übermittelt. Der RMS ruft diese Daten von Agents oder anderen Verwaltungsservern ab. Sie können die Windows-Firewall oder andere Netzwerkfunktionen verwenden, um eingehende Verbindungen mit dem RMS an Port 5723 zu blockieren. Diese Blockierung verhindert, dass Ermittlungsdaten so lange an die OperationsManager Datenbank übermittelt werden, dass der Konfigurationsverwaltungsdienst die aktuelle Konfiguration für die Agents berechnet, die die Daten übermitteln.

Der System Center-Verwaltungsdienst und der System Center-Datenzugriffsdienst auf dem RMS sollten nicht beendet oder deaktiviert werden, während der Konfigurationsverwaltungsdienst die aktuelle Konfiguration berechnet. Der System Center Configuration Management-Dienst erfordert Folgendes, um die Berechnung der Verwaltungsgruppenkonfiguration abzuschließen:

Der System Center-Verwaltungsdienst auf dem RMS muss ausgeführt und fehlerfrei sein.
Der System Center-Datenzugriffsdienst muss mit der Datenbank kommunizieren können.

Darüber hinaus können einige Daten auf den Agents und auf anderen Verwaltungsservern zurückgeloggt werden, während der Konfigurationsverwaltungsdienst die aktuelle Konfiguration berechnet. Daher sollte der Firewall- oder Portausschluss aufgehoben werden, sobald die Ereignis-ID 21025 im Operations Manager-Ereignisprotokoll auf dem RMS angezeigt wird. Dieses Ereignis gibt an, dass der Konfigurationsverwaltungsdienst die neue Konfiguration für die Verwaltungsgruppe berechnet hat, in der der Workflow jetzt deaktiviert oder geändert wurde.

Identifizieren potenzieller Ursachen für Konfigurationsänderung mithilfe der Operations Manager-Berichterstellung

Neue Berichte wurden eingeführt. Diese Berichte bieten Einen Einblick in die Gesamtmenge der Daten, die die Verwaltungsgruppe verarbeitet. Diese Berichte können verwendet werden, um eine Standardbaseline zu erstellen und Möglichkeiten für die Optimierung von Objektermittlungsworkflows zu identifizieren. Sobald die Konfigurationsänderung identifiziert und behoben wird, können diese Berichte für die langfristige Planung verwendet werden, um Wiederholungen von Abwanderungen zu verhindern.

Bericht "Datenvolumen nach Management Pack"

Der Bericht Datenvolume nach Management Pack kompiliert Informationen über die Datenmenge, die von den Management Packs generiert wird. Der Bericht listet die Anzahl der Vorkommen pro Management Pack für die folgenden Datentypen auf:
- Entdeckungen
- Warnungen
- Leistung (Anzahl der Instanzen, die für Leistungsindikatoren übermittelt und vom Management Pack erfasst werden)
- Ereignisse
- Zustandsänderungen
Datenvolumen nach Workflow und Instanzbericht

Der Bericht Datenvolumen nach Workflow und Instanz kompiliert Informationen über die Menge der generierten Daten, die nach Workflows (Ermittlungen, Regeln, Monitoren usw.) und nach Instanzen organisiert werden.

Es gibt zwei Möglichkeiten, auf diesen Bericht zuzugreifen:
- Wählen Sie im Bericht Datenvolumen nach Management Pack eine der Zählungszellen in der Tabelle oben im Bericht aus, um den Bericht Datenvolumen nach Workflow und Instanz für die Management Packs zu öffnen.
- Führen Sie den Bericht direkt im Abschnitt Berichterstellung in der Betriebskonsole aus. Wenn Sie den Bericht Datenvolumen nach Workflow und Instanz direkt ausführen, sollten Sie die Parameter des Berichts festlegen, um die Ergebnisse anzupassen. Dieser Bericht enthält Details zu Informationen im Bericht Datenvolumen nach Management Pack . Daher stellen die Standardparametereinstellungen möglicherweise nicht die informationen bereit, nach denen Sie suchen.