Ihre 12-Stunden-Alarmzusammenfassung übersieht die wichtigsten Probleme

Eine saubere Zusammenfassungs-E-Mail hat etwas Befriedigendes. Alle 12 Stunden landet ein ordentlicher Report in Ihrem Postfach, getaggt, gefiltert und genau auf das zugeschnitten, was Ihr Team sehen muss. Das wirkt kontrolliert und vorhersehbar, als hätten Sie das Rauschen endlich gezähmt. Bis Sie merken, dass Ihnen nur die halbe Geschichte erzählt wird.

Historische Alarme sind nämlich einfach, weil sie abgeschlossen und ordentlich in ein Zeitfenster verpackt sind. Sie fragen die Ereignisse der letzten 12 Stunden ab, wenden Ihre Tag-Filter an, formatieren die Ausgabe und schicken sie los. Saubere Daten, klare Grenzen, keine Mehrdeutigkeit.

Bei aktiven Alarmen wird es unübersichtlich. Sobald Sie aktuelle Probleme einbeziehen wollen, fragen Sie keine Historie mehr ab, sondern Status, und Zabbix behandelt beides unterschiedlich. Historische Ereignisse leben in einer Welt, laufende Probleme in einer anderen.

Fragt Ihr Skript mit einem Zeitfilter aus event.get ab, erfassen Sie wahrscheinlich nur Ereignisse, die in den letzten 12 Stunden aufgetreten sind. Für Zusammenfassungsberichte funktioniert das einwandfrei. Aktive Alarme können aber vor 3 Tagen begonnen haben und immer noch offen sein, und bei einer einfachen Abfrage über die letzten 12 Stunden tauchen sie nicht auf. Das ist die Falle.

Sie wollen keine Alarme, die kürzlich passiert sind, sondern Alarme, die noch im Problemstatus stehen. Das ist ein anderer API-Aufruf oder zumindest ein anderer Filter. Statt nach Zeit filtern Sie je nach API-Ansatz nach value=1 (Problemstatus) und recent=true oder einer äquivalenten Logik.

Ihr Zusammenfassungsskript braucht deshalb wahrscheinlich zwei Abfragen:

1. Historische Ereignisse der letzten 12 Stunden.
2. Aktuelle Probleme, unabhängig von der Startzeit.

Danach führen Sie die Ausgabe intelligent zusammen, also nicht mit einem stumpfen Anhängen, sondern so, dass keine Duplikate entstehen, wenn ein Problem in den letzten 12 Stunden begonnen hat und noch aktiv ist.

Hier bleiben viele hängen. Sie haben ihr Reporting-Skript rund um die Ereignis-Historie gebaut, obwohl sich aktive Probleme in neueren Zabbix-Versionen besser über problem.get abrufen lassen. Dieser Endpunkt versteht laufenden Problemstatus deutlich sauberer. Auf 6.x oder 7.x ist problem.get Ihr Freund, weil es das Rätselraten beendet, ob man manuell prüfen muss, ob ein Recovery-Ereignis existiert. Es sagt Ihnen einfach, was gerade kaputt ist.

Unbequem daran ist, dass Ihr Abschnitt für aktive Alarme wertvoller sein könnte als Ihre historische Zusammenfassung. Historische Zusammenfassungen taugen gut, um Trends zu erkennen: Was ist über Nacht kaputtgegangen, was hat heute Morgen geflackert? Aktive Alarme sind dagegen operative Wahrheit und beantworten die eine Frage, die um 9 Uhr morgens zählt: Was brennt noch?

Dass Sie Tags zum Filtern von Inhalten schon nutzen, ist eine solide Grundlage, denn Tags machen das Ganze skalierbar. Sie können dieselben Tag-Filter auf die historische und die aktive Abfrage anwenden und so sicherstellen, dass Ihre E-Mail nur enthält, was Ihr Team tatsächlich interessiert.

Auch die Struktur der E-Mail spielt eine Rolle. Werfen Sie aktive Alarme einfach in denselben Abschnitt wie die historischen, wird es verwirrend. Besser lesbar ist es so:

• Abschnitt 1: Aktive Probleme (gerade jetzt offen)
• Abschnitt 2: Probleme der letzten 12 Stunden (einschließlich gelöster)

Diese Trennung verhindert mentale Überlastung, weil Leser sofort sehen, was Aufmerksamkeit braucht und was bereits erledigt ist.

Eine subtile Logikfrage müssen Sie noch klären: Wollen Sie lang bestehende aktive Probleme in jeder E-Mail aufführen? Ist etwas seit 30 Tagen offen, taucht es sonst alle 12 Stunden für immer wieder auf. Manche Teams wollen das genau so, weil es den Druck sichtbar hält. Andere unterdrücken Probleme, die älter als ein bestimmter Schwellenwert sind, solange sich ihr Schweregrad nicht ändert. Das ist eine Policy-Entscheidung und keine technische.

Interessant ist auch die Frage, ob es für so etwas ein gemeinsames Skript-Repository gibt. Einen zentralen Zabbix-„Skript-Marktplatz" gibt es nicht wirklich. Die meisten Leute werfen ihre Ad-hoc-Tools auf GitHub und teilen sie, falls andere davon profitieren.

Das ist Segen und Fluch zugleich. Einerseits bleibt so alles offen und flexibel, andererseits erfindet jeder immer wieder ähnliche Reporting-Skripte neu. Alarmzusammenfassungen, SLA-Exporte und Executive-Dashboards existieren in Dutzenden privater Repositories. Wenn Sie Ihres polieren und veröffentlichen, kämpft irgendwo jemand gerade genau denselben Kampf.

Bedenken sollten Sie außerdem, ob Sie überhaupt ein eigenständiges Skript brauchen. Neuere Zabbix-Versionen unterstützen geplante Reports. Geht es nur um E-Mail-Zusammenfassungen, können Sie ein individuelles Dashboard mit gefilterten Widgets auf Tag-Basis bauen und es als Report planen. Dieser Weg bezieht aktive Probleme automatisch mit ein, weil Dashboards den aktuellen Status widerspiegeln. Hat Ihr Skript fortgeschrittenere Formatierung, Aggregation oder eigene Logik, bleiben Sie besser beim API-Ansatz.

Der Kernpunkt ist aber fast sicher dieser: Sie fragen Ereignisse nach Zeit ab, wo Sie Probleme nach Status abfragen müssten. Wechseln Sie dieses mentale Modell, und die fehlenden aktiven Alarme sind kein Thema mehr.

Sobald diese zweite Abfrage drin ist, wird aus Ihrer Zusammenfassung mehr als ein historischer Rückblick. Sie zeigt dann eine echte operative Momentaufnahme mit dem, was passiert ist, und dem, was gerade noch passiert. Das ist die E-Mail, die Menschen tatsächlich lesen.