SCOM-Grundlagen: Monitore, Regeln und E-Mail-Benachrichtigungen richtig einsetzen

Wann brauche ich einen Monitor, wann eine Regel – und wie kommt der Alarm am Ende per E-Mail beim Administrator an? Ein Leitfaden für alle, die mit Operations Manager starten.

Wer zum ersten Mal mit System Center Operations Manager (SCOM) arbeitet, stößt schnell auf drei Begriffe, die auf den ersten Blick dasselbe zu tun scheinen: Monitore, Regeln und Aufgaben (Tasks). Dazu kommt die Frage, wie aus einem erkannten Problem eine E-Mail wird. Genau diese Fragen kamen in unserer Community immer wieder auf – hier die Antworten, kompakt zusammengefasst.

Monitor oder Regel – der entscheidende Unterschied

SCOM kennt zwei grundsätzliche Wege, einen Fehlerzustand zu erkennen:

• Monitore sind zustandsbehaftet (stateful). Ein Unit Monitor (Einheitenmonitor) prüft eine Bedingung und setzt den Integritätsstatus eines Objekts auf Fehlerfrei, Warnung oder Kritisch. Der Statuswechsel kann zusätzlich einen Alarm erzeugen – und wenn die Bedingung wieder in Ordnung ist, wird der Status automatisch zurückgesetzt.
• Regeln sind zustandslos (stateless). Eine Regel sammelt Daten (z. B. Leistungsindikatoren für Reports) oder erzeugt bei einem Ereignis direkt einen Alarm – ohne den Integritätsstatus zu verändern. Ein Alarm aus einer Regel muss in der Regel manuell geschlossen werden.
• Tasks (Aufgaben) sind Aktionen, die ein Operator auf Knopfdruck ausführen kann – etwa einen Dienst neu starten oder einen Ping absetzen. Mit der Überwachung selbst haben sie nichts zu tun.

Faustregel: Alles, was einen „gesund/ungesund“-Zustand hat (CPU-Last, freier Plattenplatz, Dienststatus), gehört in einen Monitor. Einzelereignisse ohne Gegenzustand (ein bestimmter Eventlog-Eintrag) und Datensammlungen gehören in eine Regel.

Welche Monitortypen gibt es?

In 99 % der Fälle arbeiten Sie mit Einheitenmonitoren – dort steckt die eigentliche „Intelligenz“ eines Management Packs. Die beiden anderen Typen dienen dem Health Rollup:

• Aggregatmonitore (Rollupmonitor zusammenfassen) fassen den Status mehrerer Monitore eines Objekts zusammen, z. B. alle Verfügbarkeitsmonitore.
• Abhängigkeits-Rollupmonitore übertragen den Status eines Objekts auf ein anderes – etwa wenn der Zustand einer Datenbank den Zustand der gesamten Anwendung beeinflussen soll.

Für einfache Überwachungsszenarien in der Konsole brauchen Sie beide nicht.

Beispiel: CPU länger als 5 Minuten über 80 %

Bevor Sie selbst etwas bauen: Ein Blick in das Windows Server Operating System Management Pack lohnt sich. Dort existiert bereits ein Monitor für die Prozessorauslastung, der Prozessorzeit und Prozessor-Warteschlange auswertet. Schwellwerte und Intervalle passen Sie über Overrides an – nicht im versiegelten Management Pack selbst.

Ein Monitor gilt übrigens nie für „einen Computer“, sondern für eine Klasse (Zielobjekt). SCOM ist objektorientiert: Zielen Sie auf die Klasse Windows Server Operating System, wirkt der Monitor auf alle Server dieser Klasse. Einschränkungen auf einzelne Systeme erledigen Sie wiederum per Override für eine Gruppe.

Vom Alarm zur E-Mail

Ein Monitor allein verschickt keine E-Mails. Dafür sind drei Bausteine unter Administration › Notifications nötig:

1. Channel (Kanal): Einen SMTP-Kanal mit Mailserver, Absenderadresse und Nachrichtenformat anlegen.
2. Subscriber (Abonnent): Empfänger mit E-Mail-Adresse und Zeitplan hinterlegen.
3. Subscription (Abonnement): Festlegen, welche Alarme an wen gehen – etwa alle kritischen Alarme der Klasse Windows Server Operating System oder nur Alarme bestimmter Monitore.

Schneller geht es aus der Alarmansicht heraus: Unter Monitoring › Active Alerts einen Alarm markieren und im Aktionsbereich über Subscription ein neues Abonnement auf Basis dieses Alarms erstellen.

Fazit

Monitore bilden Zustände ab, Regeln sammeln Daten oder melden Einzelereignisse – und erst eine Subscription macht aus einem Alarm eine Benachrichtigung. Wer diese Trennung verinnerlicht, vermeidet die typischen Anfängerfehler wie doppelte Alarme oder Monitore, die nie zurückgesetzt werden.