Das größte Risiko bei einer Flut von Alarmen ist, die wichtigsten Alarme zu verpassen. Deswegen sollte man tunlichst nur die Alarme einschalten, die man auch wirklich bekommen und bearbeiten möchte. Das ist leider manchmal gar nicht so einfach.
Ein sehr nerviger (aber wichtiger) Alarm ist:
==> One or more virtual machine guest file systems are running out of disk space <==
Immer wieder erreichen mich Kundenanfragen, ob man diesen Alarm nicht so bearbeiten kann, dass nur bestimmte Laufwerke alarmiert werden.
Es gibt hierfür sehr viele Beispiele, aber ein sehr gängiges ist, ein Windows Laufwerk, auf dem sich das Pagefile des Betriebssystem befindet. Je nach Windows Einstellung ist es immer “voll” und das soll es auch sein. Wie auch immer, vR Ops weiss das nicht. vR Ops behandelt alle Laufwerke gleich und dementsprechend wird auch alarmiert. Man stelle sich nun vor, man hat 1500 Windows VMs, die alle einen Alarm auf ihrem Laufwerk P:\ (Pagefile) haben. Das wäre sehr lästig und würde dazu führen, dass man vielleicht einen wichtigen Alarm für Laufwerk C:\ schlichtweg verpasst.
Wie kann ich also ein ganz bestimmtes Laufwerk aus dem Alarm entfernen??
Hierzu sind im Wesentlichen 3 Schritte notwendig:
- Neue Symptome erstellen
- Bestehenden Alarm anpassen
- Alle aktiven Alarme löschen
Eins vorweg: Man kann leider kein einzelnes Laufwerk entfernen/ausnehmen! Man muss alle Laufwerke hinzufügen, die man überwachen will!
Wenn man sich den original Alarm genauer anschaut, dann treiben 3 Symptome diesen Alarm. Guest File System Space Usage at critical, immediate und warning Level.
Symptome
Das ist eigentlich eine clevere Einstellung, denn vR Ops muss nicht wissen, welche Laufwerke (und Mountpoints) es gibt, es betrachtet einfach alle!! Wenn man also Alarme für nur bestimmte Laufwerke erhalten möchte, muss man also in den “saueren Apfel” beissen und für jedes Laufwerk und evtl Kritikalitätslevel ein neues Symptom definieren. Um ein Laufwerk explizit auszunehmen, erstellt man einfach kein Symptom! 😎
Symptom erstellen
Unter Content >> Symptom Definition erstellt man im Abschnitt Metric / Property Symptom Definition ein neues Symptom. Die Metrik Guest File System Usage % befindet sich unter den Guest File System Stats. Einfach per Drag&Drop ins Konfigurationsfeld ziehen und Namen, Kritikalitätslevel und Schwellwert eintragen. Wie schon erwähnt, muss man das nun für alle Laufwerke, die man überwachen möchte, machen.
Kleiner Tipp: Wenn man als Base Objekt virtual Machine ausgewählt hat, kommt eine default VM. Manchmal sogar eine Linux VM, die unter Guest File Stats gar keine Windows Laufwerksbuchstaben anzeigt. Dazu kann man auf das kleine Quadrat (Select Object) neben dem Rollbalken “Metric “klicken und sich eine Referenz VM aussuchen.
Alarm konfigurieren
Sobald alle Symptome erstellt sind, bearbeiten wir den Alarm. Der Alarm ist unter Content >> Alert Definition zu finden. Die eigentliche Konfiguration findet im Schritt 4 des Wizzards statt (Add Symptom Definitions). Die 3 alten Symptome, die den Alarm beeinflusst haben, entfernen wir einfach. Wir ziehen nun mit Drag&Drop unsere gerade neu erstellten Symptome in das Konfigurationsfeld. Und zwar so viele, wie man benötigt. Es mag ja auch sein, dass ihr gar keinen Alarm für den Warning-Schwellwert haben wollt, dann fügt ihn einfach nicht hinzu. In meinem Beispiel, bekomme ich nur noch Alarme für Laufwerk C:\ und F:\. Für kein anderes mehr!!!
ACHTUNG: Ihr müsst dringend den Auslöser/Trigger auf ANY stellen, da er sonst wartet, bis alle diese Symptome eintreten.
Alarme löschen
Im Prinzip war es das schon. Wir müssen nun den neuen Alarm live bekommen, in dem wir alle alten Alarme zum Guest File System Usage löschen! Ja löschen!! Keine Angst, die kommen wieder 🙂 Wenn die Laufwerke wirklich noch voll sind, kommt der Alarm wieder, aber eben nur die, für die ihr auch ein Symptom erstellt habt!
Ich hoffe ich konnte helfen. Wie immer, würde ich mich über Feedback freuen!
- Super Metric 102 oder “Wo findet sich die WhiteList für Super Metriken?” - 11. Mai 2016
- Super Metric 101 oder “Cannot convert aggregated result to number” - 11. Mai 2016
- vRealize Operations FAQ jetzt online - 26. Januar 2016