Haben Sie schon mal beim chinesisch Kochen auf den Tisch klettern müssen um einen Rauchmelder an der Decke zu deaktivieren? Liegt wohl daran, dass der Rauchmelder zwar den Rauch registriert hat aber den Koch am Herd nicht berücksichtigt. Ein Rauchmelder ist ein Alarm der auf einem einzigen Symptom basiert. Bei komplexen Systemen, wie den Menschen, werden Diagnosen selten aufgrund eines einzigen Symptoms gestellt, sondern beruhen auf Anamnese und Befunden, die für eine Krankheit spezifisch sind.
Das Konzept der Alerts wurde nach dem Beispiel der medizinischen Diagnone in vRealize Operations 6 von Grund auf neu gestaltet. Die Alerts basieren auf einer Kombination beliebiger Einzelsymptome, können Empfehlungen beinhalten und Aktionen anbieten. Symptome werden über mehrere Objekte korelliert und erstrecken sich gleichermassen über alle Daten im Operations Manager. Die Korelllation erfolgt über die verschiedenen Objekte und Metriken hinweg.
Vorgefertigte Alarme, Symptome und Recommendations werden sowohl von VMware (für die virtuelle Umgebung) als auch von den Herstellern der Management Packs (z.B. für NetApp) mitgeliefert. Ein grafischer Wizzard erlaubt das erzeugen und anpassen eigener Alarme.
Alerts können mit Objekten und mit Badges assoziiert werden. Sie bestehen aus einem oder meist mehreren aktiven Symptomen und einer oder mehreren Empfehlungen und zugewiesenen Aktionen.
Die Basisbausteine der Alarme sind Symptome. Dies sind einfache Bedingungen, die erfüllt oder nicht erfüllt sind. Wichtig ist, dass die Symptome nicht nur auf Metriken basieren, sondern auch auf Objekteigenschaften, Ausfällen, Änderungsevents, Badges oder gar Log-Einträgen. Hier sind ein Paar Beispiele für Symptome:
- CPU Workload in % auf einer VM ist höher als 80% -> Metrik, festgelegter Schwellenwert
- Datastore Latenz über dem dynamischen Schwellenwert -> Metrik, dynamischer Schwellenwert
- Limits für die VM sind gesetzt -> Konfigurationseigenschaft
- Netzwerkpfad weg -> Ausfall (fault)
- Event -> zum Beispiel das Vorkommen eines Stichworts im Logfile (erfordert Log Insight – Integration)
- Allgemeiner Gesundheitszustand -> Badge
Bei der Auswertung der Eigenschaften können einfache Bedingungen geprüft werden: grösser als, kleiner als, grösser oder gleich, ungleich, genau gleich usw.
- Dynamische Schwellenwerte: grösser, kleiner, anormal.
- Events und Faults können auf Textinhalt ausgewertet werden (contains..).
Das Zusammenführen der Symptome aus verschiedenen Quellen und die logische Verknüpfung dieser erlaubt das Erstellen sehr zielgerichteter Alerts. Ein Beispiel: es gibt einen vorgefertigten Alert zu dropped Packages in % auf einer distributed Port group, dieser heisst „One or more ports are experiencing network contention“
Unter Content -> Alert Definitions können wir diesen Alert editieren. Ich empfehle den vorgefertigten zu klonen (Das Symbol mit zwei blauen Dreiecken).
Durch das Drücken des Stiftsymbols öffnet sich Alert-Konfigurations-Dialog:
Dieser Alert basiert auf einem Symptom: „Port is experiencing dropped packets“ der wiederum auf dem Objekt „vSphere distributed port group“ die Metrik „Network – Port Statistics – Percent of dropped Packets“ hinzuzieht und bei 10 Prozent zutrifft. Soweit ist es alles korrekt, aber in der konkreten Kundenumgebung gab es Netze die noch nicht benutzt werden, in denen nur sehr wenige Pakete unterwegs waren. Bei 4 Paketen pro Sekunde wäre 1 Paket „dropped“ und schon 25%.
Wenn man sich die Metriken genauer anschaut: die Prozente in dem folgenden Beispel sehen furchterregend aus, liegen auf bis zu 83%:
zieht man die „Total Dropped Packets per second“ hinzu, kann man wieder aufatmen, insgesamt wird kaum ein Paket pro Sekunde verloren. Dies ist kein Grund auf den Tisch zu klettern. 
Aufgrund dieser Erkenntnis können wir ganz leicht den Alert erweitern und ein neues Symptom hinzufügen, z.B. der Alert soll nur dann aktiv werden wenn tatsächlich mehr als 10 Pakete gedropped werden. Hierzu kann man den vorhanden Alert editieren und dabei ein neues Symptom definieren und mit einer logischen UND-Verknüpfung hinzufügen:
So sieht der Alert im Original aus:
Mit dem + fügen wir ein neues Symptom hinzu und definieren dieses Symptom als “Total dropped packets per s” > 10
Hier ist das Ergebnis:
Nun werden die Alerts nur dann aktiv, wenn mehr als 10 Prozent der Pakete gedropped werden und auch die absolute Zahl der dropped packets höher als 10 pro Sekunde ist.
Dies ist nur ein Beispiel, wie man beliebige Alerts erweitern oder eingrenzen und “schärfen” kann. Das Konzept der Symptome ist sehr mächtig, es wird besonders spannend, wenn man auch Infrastruktur-Metriken, Logs und Anwendungskennzahlen miteinander kombiniert: zum Beispiel, ein Alert bei niedriger Transaktionszahl der Datenbank bei gleichzeitig hoher CPU Last, oder die Kombination der Log-Einträge mit Metriken.