Ihre 12-Stunden-Alarmzusammenfassung ist schön, aber sie übersieht die wichtigsten Probleme
Ihre 12-Stunden-Alarmzusammenfassung ist schön — aber hier ist, warum sie die wichtigsten Probleme übersieht
Es gibt etwas Befriedigendes an einer sauberen Zusammenfassungs-E-Mail. Alle 12 Stunden landet ein ordentlicher Report in Ihrem Postfach. Getaggt. Gefiltert. Genau das, was Ihr Team sehen muss. Es fühlt sich kontrolliert an. Vorhersehbar. Als hätten Sie das Rauschen endlich gezähmt.
Bis Sie merken, dass Ihnen nur die halbe Geschichte erzählt wird.
Denn historische Alarme sind einfach. Sie sind abgeschlossen. Erledigt. Ordentlich in ein Zeitfenster verpackt. Sie fragen Ereignisse der letzten 12 Stunden ab, wenden Ihre Tag-Filter an, formatieren die Ausgabe und schicken sie los. Saubere Daten. Klare Grenzen. Keine Mehrdeutigkeit.
Aktive Alarme? Da wird es unübersichtlich.
Sobald Sie versuchen, aktuelle Probleme einzubeziehen, fragen Sie nicht mehr Historie ab. Sie fragen Status ab. Und Zabbix behandelt das unterschiedlich. Historische Ereignisse leben in einer Welt. Laufende Probleme leben in einer anderen.
Wenn Ihr Skript mit einem Zeitfilter aus event.get abfragt, erfassen Sie wahrscheinlich nur Ereignisse, die in den letzten 12 Stunden aufgetreten sind. Das funktioniert einwandfrei für Zusammenfassungsberichte. Aber aktive Alarme könnten vor 3 Tagen begonnen haben und immer noch offen sein. Sie tauchen bei einer einfachen „letzte 12 Stunden"-Abfrage nicht auf.
Und das ist die Falle.
Sie wollen nicht „Alarme, die kürzlich passiert sind". Sie wollen „Alarme, die noch im Problemstatus sind". Das ist ein anderer API-Aufruf – oder zumindest ein anderer Filter. Statt nach Zeit zu filtern, müssen Sie nach value=1 (Problemstatus) und recent=true oder einer äquivalenten Logik filtern, je nach Ihrem API-Ansatz.
Mit anderen Worten: Ihr Zusammenfassungsskript braucht wahrscheinlich zwei Abfragen:
- Historische Ereignisse der letzten 12 Stunden.
- Aktuelle Probleme, unabhängig von der Startzeit.
Dann führen Sie die Ausgabe intelligent zusammen. Nicht einfach ein stumpfes Anhängen, sondern etwas, das Duplikate vermeidet, wenn ein Problem sowohl in den letzten 12 Stunden begonnen hat als auch noch aktiv ist.
Hier bleiben viele hängen. Sie haben ein Reporting-Skript rund um Ereignis-Historie gebaut, aber aktive Probleme lassen sich in neueren Zabbix-Versionen besser über problem.get abrufen. Dieser Endpunkt versteht laufenden Problemstatus auf sauberere Weise.
Wenn Sie auf 6.x oder 7.x sind, ist problem.get Ihr Freund. Es eliminiert das Rätselraten, ob man manuell prüfen muss, ob ein Recovery-Ereignis existiert. Es sagt Ihnen einfach, was gerade kaputt ist.
Und hier die unbequeme Wahrheit: Ihr Abschnitt für aktive Alarme könnte wertvoller sein als Ihre historische Zusammenfassung.
Historische Zusammenfassungen sind großartig für das Erkennen von Trends. „Was ist über Nacht kaputtgegangen?" „Was hat heute Morgen geflackert?" Aber aktive Alarme sind operative Wahrheit. Sie beantworten die einzige Frage, die um 9 Uhr morgens wirklich zählt:
Was brennt noch?
Die Tatsache, dass Sie bereits Tags zum Filtern von Inhalten verwenden, ist eine solide Grundlage. Tags machen das skalierbar. Sie können dieselben Tag-Filter sowohl auf Ihre historischen als auch auf Ihre aktiven Abfragen anwenden und sicherstellen, dass Ihre E-Mail nur das enthält, was Ihr Team tatsächlich interessiert.
Auch die Struktur der E-Mail ist wichtig. Wenn Sie aktive Alarme einfach in denselben Abschnitt wie historische werfen, wird es verwirrend. Der bessere Ansatz:
- Abschnitt 1: Aktive Probleme (gerade jetzt offen)
- Abschnitt 2: Probleme der letzten 12 Stunden (einschließlich gelöster)
Diese Trennung verhindert mentale Überlastung. Leser sehen sofort, was Aufmerksamkeit braucht, im Gegensatz zu dem, was bereits erledigt wurde.
Es gibt auch eine subtile Logikfrage, die Sie klären müssen: Wollen Sie lang bestehende aktive Probleme in jeder E-Mail einbeziehen? Denn wenn etwas seit 30 Tagen offen ist, taucht es alle 12 Stunden für immer wieder auf.
Manche Teams bevorzugen das. Es hält den Druck sichtbar. Andere unterdrücken Probleme, die älter als ein bestimmter Schwellenwert sind, es sei denn, ihr Schweregrad ändert sich. Das ist eine Policy-Entscheidung, keine technische.
Die andere aufgeworfene Frage – ob es ein gemeinsames Skript-Repository für so etwas gibt – ist interessant. Es gibt nicht wirklich einen zentralisierten Zabbix-„Skript-Marktplatz". Die meisten Leute werfen ihre Ad-hoc-Tools einfach auf GitHub und teilen sie, falls andere davon profitieren könnten.
Das ist sowohl Segen als auch Fluch.
Einerseits hält es die Dinge offen und flexibel. Andererseits bedeutet es, dass jeder immer wieder ähnliche Reporting-Skripte neu erfindet. Alarmzusammenfassungen. SLA-Exporte. Executive-Dashboards. Sie existieren in Dutzenden privater Repositories.
Wenn Sie Ihres poliert und veröffentlichen, kämpft wahrscheinlich jemand anderes gerade genau denselben Kampf.
Noch ein Aspekt, der es wert ist, bedacht zu werden: Brauchen Sie überhaupt ein eigenständiges Skript?
Zabbix unterstützt geplante Reports in neueren Versionen. Wenn Ihr Anwendungsfall rein aus E-Mail-Zusammenfassungen besteht, können Sie möglicherweise ein individuelles Dashboard mit gefilterten Widgets (basierend auf Tags) bauen und es dann als Report planen. Dieser Ansatz bezieht automatisch aktive Probleme mit ein, weil Dashboards den aktuellen Status widerspiegeln.
Aber wenn Ihr Skript fortgeschrittenere Formatierung, Aggregation oder individuelle Logik hat, ergibt es Sinn, beim API-Ansatz zu bleiben.
Der Kernpunkt ist aber fast sicher dieser: Sie fragen Ereignisse nach Zeit ab, nicht Probleme nach Status.
Wechseln Sie dieses mentale Modell, und das Problem der fehlenden aktiven Alarme verschwindet.
Und sobald Sie diese zweite Abfrage hinzufügen, hört Ihre Zusammenfassung auf, ein historischer Rückblick zu sein, und wird zu etwas Mächtigerem – einer echten operativen Momentaufnahme. Nicht nur, was passiert ist. Sondern was gerade noch passiert.
Das ist die E-Mail, die Menschen tatsächlich lesen.