SCOM Config Churn aufspüren: Welche Discoveries laufen zu oft?

Hohe Last auf Management Servern und Datenbank, ohne dass sich an der Umgebung etwas ändert? Häufig sind übereifrige Discoveries schuld. Mit diesen Abfragen finden Sie die Verursacher.

Operations Manager erkennt Objekte und ihre Eigenschaften über Discoveries. Jede Änderung einer erkannten Eigenschaft löst eine Konfigurationsänderung aus, die an Management Server und Agenten verteilt werden muss. Ändert sich eine Eigenschaft ständig – etwa weil eine Discovery einen Zeitstempel, einen Füllstand oder eine dynamische Liste erfasst –, entsteht Config Churn: dauerhaft hohe Last ohne echten Mehrwert.

Typische Symptome

• Management Server mit hoher CPU-Last und vielen Konfigurationsaktualisierungen.
• Agenten, die häufig neue Konfigurationen anfordern.
• Schnell wachsende Datenbanken, insbesondere die Tabellen für Eigenschaftsänderungen.

Abfrage 1: Neu erkannte Objekte der letzten 4 Stunden

Die folgenden Abfragen laufen gegen das Data Warehouse (OperationsManagerDW):

SELECT DISTINCT
       mp.ManagementPackSystemName,
       met.ManagedEntityTypeSystemName,
       d.DiscoverySystemName, d.DiscoveryDefaultName,
       me.Path, me.Name, me.DWCreatedDateTime
FROM   dbo.vManagedEntity me
JOIN   dbo.vManagedEntityType met  ON met.ManagedEntityTypeRowId = me.ManagedEntityTypeRowId
JOIN   dbo.vManagementPack mp      ON mp.ManagementPackRowId     = met.ManagementPackRowId
JOIN   dbo.vManagementPackVersion mpv ON mpv.ManagementPackRowId = mp.ManagementPackRowId
LEFT JOIN dbo.vDiscoveryManagementPackVersion dmp
       ON dmp.ManagementPackVersionRowId = mpv.ManagementPackVersionRowId
      AND CAST(dmp.DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max))
          LIKE '%' + met.ManagedEntityTypeSystemName + '%'
LEFT JOIN dbo.vDiscovery d ON d.DiscoveryRowId = dmp.DiscoveryRowId
WHERE  me.DWCreatedDateTime > DATEADD(HOUR, -4, GETUTCDATE());

Abfrage 2: Die Discoveries mit den meisten Eigenschaftsänderungen

Die aussagekräftigste Abfrage zählt Eigenschaftsänderungen pro Klasse und Discovery:

SELECT met.ManagedEntityTypeSystemName, d.DiscoverySystemName, COUNT(*) AS Changes
FROM   dbo.vManagedEntityPropertyChange c
JOIN   dbo.vManagedEntity me           ON me.ManagedEntityRowId = c.ManagedEntityRowId
JOIN   dbo.vManagedEntityType met      ON met.ManagedEntityTypeRowId = me.ManagedEntityTypeRowId
JOIN   dbo.vManagementPack mp          ON mp.ManagementPackRowId = met.ManagementPackRowId
JOIN   dbo.vManagementPackVersion mpv  ON mpv.ManagementPackRowId = mp.ManagementPackRowId
LEFT JOIN dbo.vDiscoveryManagementPackVersion dmp
       ON dmp.ManagementPackVersionRowId = mpv.ManagementPackVersionRowId
      AND CAST(dmp.DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max))
          LIKE '%' + met.ManagedEntityTypeSystemName + '%'
LEFT JOIN dbo.vDiscovery d ON d.DiscoveryRowId = dmp.DiscoveryRowId
WHERE  c.ChangeDateTime > DATEADD(HOUR, -4, GETUTCDATE())
GROUP BY met.ManagedEntityTypeSystemName, d.DiscoverySystemName
ORDER BY Changes DESC;

Mit c.OldValue und c.NewValue in der Detailabfrage sehen Sie zudem, welche Eigenschaft wie oft zwischen welchen Werten wechselt – das ist meist schon die Diagnose.

Was tun mit den Ergebnissen?

1. Intervall verlängern: Viele Discoveries laufen stündlich, obwohl einmal täglich genügt. Per Override das Intervall erhöhen.
2. Discovery deaktivieren, wenn die Klasse gar nicht benötigt wird – ebenfalls per Override für die betroffene Gruppe.
3. Eigene Management Packs korrigieren: Wechselnde Werte gehören in Monitore oder Leistungsregeln, nicht in Discovery-Eigenschaften.
4. Herstellerupdate prüfen: Viele bekannte Churn-Probleme wurden in neueren Management-Pack-Versionen behoben.