Ein Alarm ist eine Nachricht an einen Menschen, keine Zeile in einem Log

Jede Monitoring-Plattform kann ein Problem erkennen. Der schwierige Teil ist die letzte Meile: den richtigen Alarm vor einen Menschen zu bringen, der handeln kann, innerhalb von Sekunden, ohne diesen Menschen unter Alarmen zu begraben, die nicht zählen. So leiten wir Alarme in Zabbix weiter, und so können Sie prüfen, ob Ihre eigene Kette wirklich funktioniert.

Erkennung ist billig, Aufmerksamkeit ist teuer

Die meisten Monitoring-Umgebungen scheitern nicht, weil sie ein Problem übersehen. Sie scheitern, weil niemand liest, was sie erzeugen. E-Mail-Benachrichtigungen landen in einem Ordner, der sich schneller füllt, als ihn jemand leeren kann. Dashboards werden rot und bleiben wochenlang rot, bis Rot gar nichts mehr bedeutet. Der Ingenieur, der es schließlich bemerkt, reagiert meist auf einen Kunden, nicht auf den Monitor.

Mehr Checks hinzuzufügen behebt das nicht. Was es behebt, ist ein Weiterleitungsdesign, das die Aufmerksamkeit eines Ingenieurs als die knappste Ressource behandelt, die Sie haben, und sie nur für Dinge ausgibt, die jetzt einen Menschen brauchen.

Entscheiden Sie, was einen Menschen erreichen darf

Beginnen Sie beim Schweregrad, und seien Sie streng dabei. Jeder Zabbix-Trigger trägt einen Schweregrad, von Information bis Disaster. Wir leiten nur die beiden obersten, High und Disaster, an den Ingenieur in Bereitschaft weiter, und jeder Trigger auf dieser Stufe muss einen Test bestehen: Wenn das nachts auslöst, muss jemand vor dem Morgen handeln? Lautet die ehrliche Antwort nein, ist es ein Warning. Warnings gehören auf Dashboards und in die tägliche Durchsicht, nicht in jemandes Hosentasche.

In Zabbix lebt diese Entscheidung an zwei Stellen: in den Bedingungen der Action (Schweregrad des Triggers größer oder gleich High) und im Schweregradfilter auf dem Medium des Benutzers. Setzen Sie beide, und bringen Sie sie in Einklang. Eine Action, die auf alles passt, kombiniert mit einem Medienfilter, der die Hälfte davon stillschweigend verwirft, ist eine Konfiguration, über die um drei Uhr morgens niemand klar nachdenken kann.

Dann unterdrücken Sie die Echos. Fällt ein Switch aus, wird jeder Host dahinter ebenfalls unerreichbar. Trigger-Abhängigkeiten sagen Zabbix, dass die Host-Alarme vom Switch-Alarm abhängen, sodass der Ingenieur einen Alarm erhält, der die Ursache nennt, statt vierzig, die die Symptome nennen.

Stellen Sie ihn dort zu, wo der Ingenieur bereits ist

Unsere Alarme verlassen Zabbix über einen Webhook in einen eigenen Betriebskanal in Mattermost, den Chat, in dem unsere Ingenieure den ganzen Tag arbeiten und den sie nachts auf ihren Telefonen bei sich tragen. Chat schlägt E-Mail bei Alarmen aus praktischen Gründen. Dort schauen die Menschen bereits hin. Er zeigt, wer die Nachricht gesehen hat. Und das Gespräch über die Behebung findet im Thread unter dem Alarm statt, sodass der Thread zur Aufzeichnung dessen wird, was wann getan wurde.

Eine gute Alarmnachricht trägt genug, um zu handeln, ohne drei andere Werkzeuge zu öffnen: den Host, den Namen des Triggers, den Schweregrad, den aktuellen Wert, wie lange er in diesem Zustand ist, und einen Link direkt zum Graphen. Schreiben Sie die Nachrichtenvorlage einmal, sorgfältig, und jeder Alarm, den Sie je senden, profitiert davon.

Machen Sie Zuständigkeit sichtbar

Ein Alarm, den drei Menschen gesehen und den niemand übernommen hat, ist so schlecht wie einer, den niemand gesehen hat. Die Bestätigung schließt diese Lücke. Wenn der Ingenieur in Bereitschaft ein Problem in Zabbix bestätigt, mit einer kurzen Notiz, sehen alle anderen, dass es übernommen ist, und die Notiz ist die erste Zeile der Aufzeichnung. Hat Ihr Team eine zweite Linie, macht ein Eskalationsschritt in der Action (eine weitere Benachrichtigung, wenn ein Problem hohen Schweregrads nach einer festgelegten Anzahl von Minuten noch unbestätigt ist) aus «jemand wird schon hinsehen» eine Regel.

Geplante Arbeiten verdienen die gegenteilige Behandlung: Ein Team, das von seiner eigenen Wartung alarmiert wird, lernt, Alarme zu ignorieren, und diese Gewohnheit bleibt nicht im Wartungsfenster.

Beweisen Sie, dass es funktioniert

Beweisen Sie die Kette nach jeder Änderung

Nichts davon zählt, bis Sie einen echten Alarm den ganzen Weg haben gehen sehen. Nach jeder Änderung an der Monitoring-Plattform lösen wir einen echten Alarm aus und stoppen die Zeit vom Trigger bis zur Nachricht. Unser Netzwerkteam hat genau aufgeschrieben, wie Sie diesen Test ausführen und wie Sie bestätigen, dass jedes Gerät noch gehört wird, in Testen Sie den Alarmpfad, nicht das Dashboard. Bewahren Sie die gemessenen Zeiten auf. Steigt die Zahl zwischen den Tests langsam an, wird etwas in der Kette langsamer, und Sie haben es aus einem Test erfahren statt aus einem Ausfall.

Stimmen Sie pro Host ab, schalten Sie nie blind stumm

Geteilte Templates sind der Ort, an dem Alarmmüdigkeit entsteht. Ein Datenbankserver läuft legitimerweise heiß, jemand hebt den CPU-Schwellenwert im Template an, um ihn ruhigzustellen, und jeder andere Host im Bestand hat gerade einen nützlichen Alarm verloren. Wir bearbeiten nie ein geteiltes Template, um eine Maschine abzustimmen. Schwellenwerte, die sich unterscheiden müssen, werden als Macro-Overrides auf Host-Ebene gesetzt, zum Beispiel der eigene Wert dieses Hosts für {$CPU.UTIL.CRIT}, sodass die Abstimmung einer Maschine nie die Alarme einer anderen verändert.

Dieselbe Regel gilt für das Abschalten von Triggern. Ein Trigger, der ständig auslöst, sagt Ihnen etwas: Entweder ist der Schwellenwert für diesen Host falsch, oder der Host hat ein echtes Problem. Ihn zu deaktivieren, damit das Board grün wird, entfernt den einzigen Zeugen. Korrigieren Sie den Schwellenwert auf diesem Host, oder reparieren Sie den Host.

Überwachen Sie den Wächter

Ein Monitor, der stehen geblieben ist, ist schlimmer als keiner, weil Sie seinem Schweigen vertrauen. Zwei Checks decken den Großteil des Risikos ab. Innerhalb von Zabbix fängt ein nodata-Trigger auf jedem Agent, etwa nodata(/<host>/agent.ping,5m)=1, einen Host ab, der aufgehört hat zu melden, ein anderer und leiserer Ausfall als ein Host, der Probleme meldet. Außerhalb von Zabbix muss etwas Unabhängiges bemerken, wenn die Plattform selbst verstummt: ein Herzschlag, den der Server nach Zeitplan an ein separates System sendet, das seinen eigenen Alarm auslöst, wenn der Herzschlag ausbleibt.

Wir behandeln die Monitoring-Plattform außerdem als Produktion: erzwungene Aufbewahrung in der Datenbank und ein Audit von der Hardware aufwärts über Betriebssystem, Datenbank, Daemon und Benachrichtigungspfad.

Eine zweite Meinung, bevor der Ingenieur ihn liest

Regeln filtern zuerst das bekannte Rauschen, dann wird jeder verbleibende Alarm in Echtzeit von KI-Modellen analysiert, die auf unseren eigenen NVIDIA A100 GPUs laufen, in unserem eigenen Rechenzentrum. Die Analyse betrachtet den Alarm zusammen mit jüngsten Ereignissen, verwandten Hosts und bekannten Mustern und stellt eine kurze zweite Meinung daneben: was sich sonst in der Nähe geändert hat, und was dieses Muster früher bedeutet hat. Sie entscheidet nichts und alarmiert niemanden. Sie erspart dem Ingenieur die ersten Minuten des Suchens. Weil die Modelle auf unserer eigenen Hardware laufen, verlassen Monitoring-Daten nie unser Netzwerk und werden nie an einen öffentlichen KI-Dienst gesendet.

Wenn Sie etwas Ähnliches bauen, behalten Sie dieselbe Grenze. Die KI kommentiert den Alarm. Ein Mensch trägt die Entscheidung.

Prüfen Sie Ihre eigene Kette

• Welche Schweregrade erreichen einen Menschen, und ist diese Entscheidung irgendwo aufgeschrieben?
• Können alle sehen, wer einen offenen Alarm übernommen hat?
• Wann hat zuletzt jemand einen echten Testalarm ausgelöst und ihn von Ende zu Ende gestoppt?
• Kommt ein Switch-Ausfall als ein Alarm an oder als vierzig?
• Hat jemand einen Schwellenwert durch Bearbeiten eines geteilten Templates abgestimmt?
• Wie viele Trigger sind gerade deaktiviert, und weiß jemand, warum?
• Was sagt Ihnen, dass die Monitoring-Plattform selbst stehen geblieben ist?

Wenn Sie ein zweites Paar Augen darauf möchten, wie Ihre Alarme Ihre Menschen erreichen, sehen wir gern hin. Mit einem Ingenieur sprechen

related line: Verwandt: Flotten-Monitoring und Alarmweiterleitung · Netzwerk- und Stromtelemetrie, Protokollierung, DDoS-Erkennung

footer line: Veröffentlicht am 22. Oktober 2026. Alle Notizen aus der Praxis