← Alle Artikel

· 3 Min. Lesezeit

Ihr Monitoring hat kein Alarm-Problem, es hat ein Kontext-Problem

Tausend Alarme pro Nacht sind nicht tausend Probleme. Wie eine Regel aus zwei Zeilen das Rauschen eines Glasfasernetzes in Vorfälle verwandelt hat, auf die man reagieren kann.

MonitoringFTTHAIOps

Die Nachtschicht in einem kleinen NOC sieht immer gleich aus: ein Bildschirm mit hunderten roten Zeilen und ein Mensch, der nach Gefühl entscheidet, welche davon zählen. Es fehlt nicht an Monitoring. Es ist zu viel davon da.

Neun Jahre lang stand ich auf der anderen Seite dieses Bildschirms. Gelernt habe ich: Das Problem ist fast nie, dass Alarme fehlen. Das Problem ist, dass jeder Alarm für sich allein ankommt, ohne irgendetwas drumherum, das erklärt, was er bedeutet.

Ein Alarm ist kein Vorfall

Ein Gerät, das Signalverlust meldet, kann defekt sein, oder jemand hat im Block den Strom abgestellt, oder es hat sich selbst neu gestartet und ist wiedergekommen. Drei sehr verschiedene Lagen, die exakt dieselbe rote Zeile erzeugen.

Die Betreiberin löst das, indem sie im Kopf Daten verknüpft: Hat dasselbe Gerät vorhin noch etwas anderes gemeldet, beschweren sich auch die Nachbarn, sind Arbeiten geplant. Dieses Verknüpfen ist echte Arbeit, sie wird von Hand gemacht, und sie wird schlecht gemacht, wenn man müde ist.

Die lohnende Frage lautet nicht “wie schicke ich weniger Alarme?”, sondern “was muss passieren, damit es sich lohnt, jemanden zu wecken?”.

Die Regel, bei der ich gelandet bin

In FTTH-Copilot, dem Diagnoseagenten, den ich für Glasfasernetze geschrieben habe, fiel die Antwort ziemlich unspektakulär aus — und genau deshalb funktioniert sie:

Alarme nach Gerät gruppieren. Einen Vorfall erst öffnen, wenn dasselbe Gerät innerhalb eines Zeitfensters mindestens zwei verschiedene Arten von Alarm meldet.

Mehr nicht. Kein Modell, kein magischer Schwellenwert, kein gleitender Durchschnitt.

Warum zwei verschiedene Arten? Weil Rauschen dazu neigt, sich identisch zu wiederholen. Eine flatternde Strecke schickt hundertmal denselben Signalverlust. Ein Gerät, das wirklich stirbt, schickt Verschiedenes: erst fällt die optische Leistung, dann steigt die Temperatur, dann ist es weg. Zwei unterschiedliche Signale am selben Ort lassen sich viel schwerer als Zufall erklären als hundert gleiche.

Der Code dafür passt auf einen Bildschirm. Er ist im Repository veröffentlicht, in packages/alerts/src/correlate.ts, und die Konstante für das Minimum heißt DEFAULT_MIN_KINDS. Sie steht auf 2.

Was Ihnen niemand über Zeitfenster sagt

Das Schwierige ist nicht die Regel, sondern die Entscheidung, wie lang das Fenster ist und wann der Vorfall schließt.

Ist das Fenster zu kurz, verlieren Sie echte Zusammenhänge: Temperatur braucht Zeit zum Steigen. Ist es zu lang, fassen Sie Dinge zusammen, die nichts miteinander zu tun haben, und Sie sind zurück beim Rauschen — nur kommt das Rauschen jetzt gebündelt und sieht ernster aus.

Es gibt keine richtige Zahl. Es gibt eine Methode: Sehen Sie sich die echten Vorfälle der letzten Monate an, messen Sie, wie lange das zweite Signal gebraucht hat, und nehmen Sie dieses Perzentil. Fehlt Ihnen diese Historie, fangen Sie kurz an und dehnen Sie aus. Einen Zusammenhang zu verpassen ist billiger, als einen zu erfinden.

Woran Sie merken, dass es wirkt

Zwei Kennzahlen reichen, und keine davon ist “Anzahl der Alarme”:

Die zweite ist die wichtige. Ein System, das selbstbewusst lügt, richtet mehr Schaden an als eines, das schreit.

Zum Mitnehmen

Wenn Ihr Monitoring Sie ertränkt, probieren Sie das, bevor Sie ein neues Werkzeug kaufen: Gruppieren Sie nach Einheit — Gerät, Dienst, Kunde, was in Ihrer Domäne Sinn ergibt — und verlangen Sie zwei verschiedene Signale, bevor Sie einen Menschen stören. Das ist ein Nachmittag Arbeit und reicht meistens.

Das teure Werkzeug kommt später, falls es wirklich nötig ist. Nötig ist es fast nie.

Kommt Ihnen das bekannt vor? Erzählen Sie mir Ihren Fall

Pfeiltasten zum Bewegen, Enter zum Auswählen, Esc zum Schließen