Ein Leistungsindikator soll gesammelt und gemeldet werden, wenn er zehn Minuten über 50 % liegt. Warum die Konsole dafür keinen passenden Regeltyp bietet – und welche Wege es gibt.
Die Anforderung klingt einfach: Ein Windows-Leistungsindikator soll gesammelt werden – für Berichte und Diagramme – und zusätzlich eine Warnung per E-Mail auslösen, wenn der Wert über einen ganzen Zeitraum zu hoch ist, etwa zehn Minuten lang über 50 %. Unter den Alert Generating Rules der Konsole findet sich dafür aber kein passender Regeltyp.
Warum die Konsole das nicht kann
In der Betriebskonsole gibt es zwei getrennte Welten:
- Performance Collection Rules sammeln Leistungsdaten, erzeugen aber keine Alarme.
- Alert Generating Rules reagieren auf Ereignisse, nicht auf Leistungsindikatoren.
Eine Regel, die beides tut – sammeln und bei anhaltender Überschreitung alarmieren –, ist technisch möglich, lässt sich aber nur mit einem Authoring-Werkzeug bauen. Das ist eine bewusste Designentscheidung seit SCOM 2007.
Weg 1: Monitor plus Sammelregel (empfohlen)
Der übliche und gut wartbare Weg besteht aus zwei Bausteinen:
- Unit Monitor vom Typ Windows Performance Counters › Static Thresholds › Consecutive Samples over Threshold – zum Beispiel: Alarm, wenn fünf aufeinanderfolgende Messungen im Zwei-Minuten-Intervall über 50 % liegen.
- Performance Collection Rule für denselben Indikator – für Diagramme und Berichte.
Der Monitor ändert zusätzlich den Integritätsstatus des Objekts. Das ist in den meisten Fällen erwünscht: Sobald der Wert wieder unter den Schwellwert fällt, wird der Zustand automatisch zurückgesetzt und der Alarm geschlossen.
Weg 2: Eine Regel mit eigener Logik
Soll ausdrücklich kein Zustand gesetzt werden, bauen Sie mit den Visual Studio Authoring Extensions (früher: Authoring Console) eine Regel mit eigenem Workflow: Datenquelle für den Leistungsindikator, eine Bedingungserkennung für aufeinanderfolgende Werte über dem Schwellwert, und als Aktionen sowohl das Schreiben in Datenbank und Data Warehouse als auch das Erzeugen eines Alarms.
Nachteil: Der Alarm muss manuell geschlossen werden, weil die Regel keinen „gesunden“ Zustand kennt.
Entscheidungshilfe
| Anforderung | Lösung |
|---|---|
| Alarm soll sich selbst schließen | Monitor |
| Integritätsstatus soll sich ändern | Monitor |
| Daten für Berichte benötigt | zusätzlich Sammelregel |
| Kein Zustand, nur Alarm und Daten | Regel per Authoring |
Tipp
Viele Management Packs enthalten bereits Sammelregeln für gängige Indikatoren. Prüfen Sie vor dem Anlegen einer eigenen Regel, ob die Daten nicht ohnehin schon gesammelt werden – doppelte Sammlungen belasten das Data Warehouse unnötig.
Heute
Die Trennung von Sammelregeln und Alarmregeln gilt unverändert in Operations Manager 2019, 2022 und 2025. Die damalige Authoring Console wurde durch die VSAE abgelöst.