Ihr Monitoring ist auch ein System: Testen Sie den Pfad, nicht das Dashboard

Ein ruhiger Monitoring-Bildschirm hat zwei mögliche Bedeutungen: Alles ist in Ordnung, oder das Monitoring kann nichts sehen. Vom Bildschirm allein können Sie nicht erkennen, welche von beiden zutrifft. Jeder Monitoring-Stack ist eine Kette aus Geräten, Agents, Collectors, Regeln und Benachrichtigungskanälen, und jedes Glied kann ausfallen, ohne selbst einen Alarm auszulösen. In diesem Artikel geht es darum, wie Sie beweisen, dass die Kette funktioniert, routinemäßig, vor dem Tag, an dem Sie sie brauchen.

Stille ist kein Beweis

Die meisten Monitoring-Konzepte prüfen sorgfältig die überwachten Dinge und setzen das Monitoring selbst voraus. Ein Switch ist so konfiguriert, dass er Syslog sendet, also wird angenommen, dass seine Logs ankommen. Eine Alarmregel existiert, also wird angenommen, dass eine Benachrichtigung jemanden erreicht. Ein Backup-Job ist eingeplant, also wird angenommen, dass eine Kopie der Konfiguration existiert. Keine dieser Annahmen ist eine Messung.

Die Stellen, an denen diese Kette typischerweise bricht, sind banal: ein Source-Interface oder eine Routing-Instanz für das Logging, die den Collector nicht erreicht, eine Firewall-Regel dazwischen, ein Collector-Input, der umkonfiguriert wurde, eine Benachrichtigungsintegration, deren Token abgelaufen ist, ein Schweregradfilter, der still den Ereignistyp ausschließt, der Sie interessiert. Nichts davon lässt ein Gerät von seiner eigenen Kommandozeile aus ungesund aussehen.

Prüfung eins: Wird jedes Gerät tatsächlich gehört?

Die Sicht des Geräts (show logging listet einen Server auf und sagt, er sei aktiviert) ist eine Behauptung. Die Sicht des Collectors ist der Beweis. Drehen Sie es um und fragen Sie den Collector: Wann hat jedes Gerät zuletzt etwas gesendet?

In Graylog zeigt eine nach Quelle gruppierte Suche über den letzten Tag jedes Gerät, das gesprochen hat. Vergleichen Sie diese Liste mit Ihrem Inventar, und alles, was fehlt, ist Ihr Befund. Ein einfacher Ende-zu-Ende-Test vom Gerät selbst räumt jeden Zweifel aus. Auf Cisco IOS und NX-OS erzeugen Sie eine harmlose Meldung und suchen sie innerhalb von Sekunden am Collector:

send log 6 "monitoring path test from this device"

Auf einem Linux-Host:

logger -p user.notice "monitoring path test from $(hostname)"

Wenn die Meldung nicht erscheint, folgen Sie dem Pfad der Reihe nach: Quelladresse und Routing-Instanz, die für das Logging verwendet werden, Erreichbarkeit des Collectors von dieser Quelle aus, jede Firewall dazwischen, dann der Input und die Stream-Regeln des Collectors.

Machen Sie denselben Vergleich für die Konfigurations-Backups. Ein Gerät, dessen zuletzt gesicherte Konfiguration Wochen alt ist, hat einen defekten Backup-Pfad, auch wenn nie etwas einen Fehler gemeldet hat.

Prüfung zwei: Erreicht ein Alarm einen Menschen?

Lösen Sie absichtlich einen echten Alarm durch die gesamte Kette aus: einen Test-Trigger, ein Dummy-Item, das einen Schwellenwert überschreitet, oder eine Log-Signatur, die Sie einspeisen. Bestätigen Sie, dass die Benachrichtigung in dem Kanal ankommt, den Ihre Ingenieure tatsächlich lesen, mit dem richtigen Schweregrad, innerhalb der Zeit, die Sie erwarten. Tun Sie das nach jeder Änderung an der Monitoring-Plattform selbst, und nach Plan auch dann, wenn sich nichts geändert hat, denn Tokens laufen ab und Integrationen driften.

In Zabbix genügen ein Test-Item auf einem überwachten Host plus ein Trigger mit dem Schweregrad, bei dem Sie alarmieren. Schicken Sie einen Wert und sehen Sie ihm beim Reisen zu:

zabbix_sender -z <zabbix-server> -s "<host>" -k monitoring.selftest -o 1

Dann bestätigen Sie drei Dinge: Das Problem ist erschienen, die Benachrichtigung wurde zugestellt, und die Entwarnung wurde zugestellt, als Sie den Wert zurückgesetzt haben.

Prüfung drei: Sind die Schweregrade ehrlich?

Prüfen Sie, welche Ereignisse einen Menschen erreichen und welche nicht. Eine kurze, ausdrückliche Liste von Signaturen, die immer alarmieren (Routing-Nachbar down, Link down, BFD down, VPN-Krypto-Fehler, Störungen bei Stromversorgung, Lüftern und Temperatur, Fehler im Storage-Netzwerk, Firewall-State-Tabellen nahe ihrem Limit), lässt sich leichter verteidigen als ein Schwellenwert, den jemand vor Jahren gesetzt hat.

Eine zweite Meinung hilft hier. Regeln filtern zuerst das bekannte Rauschen, dann wird alles Übrige in Echtzeit von KI-Modellen auf unseren eigenen NVIDIA A100 GPUs analysiert, in unserem Rechenzentrum. Die Analyse liest einen Alarm zusammen mit seiner jüngsten Historie und verwandten Ereignissen und bietet den Ingenieuren eine zweite Meinung dazu, was wahrscheinlich vor sich geht. Die Alarmdaten verlassen unsere Infrastruktur nie, und die Entscheidung trifft weiterhin der Ingenieur.

Prüfung vier: Von außen schauen

Jede Sicht aus dem Inneren Ihres Netzwerks teilt die blinden Flecken Ihres Netzwerks. Eine globale Messplattform wie RIPE Atlas, mit einem Anchor oder Probes, die in Ihre Richtung messen, zeigt, wie echte Orte im Internet Sie erreichen: Latenz, Verluste und Pfadänderungen. Wenn ein Carrier Wartungsarbeiten durchführt, sagt Ihnen die Außensicht, wie lange die Rekonvergenz gedauert hat und ob es jemand hätte bemerken können, was kein interner Zähler kann.

Für private Leitungen verwandelt ein dedizierter Probe an jedem Ende, der jede Minute Latenz, Jitter und Durchsatz in beide Richtungen misst, dauerhaft gespeichert, jedes Gespräch mit einem Carrier von Meinung in Daten. Nehmen Sie den Probe-Verkehr aus den Statistiken der Leitung selbst heraus, damit der Nachweis sauber bleibt.

Prüfung fünf: Durchsehen, wenn nichts falsch ist

Führen Sie nach Plan Health-Sweeps im Nur-Lese-Modus durch, nicht nur nach einem Alarm. Umgebungswerte, Routing- und Overlay-Zustand, Redundanzkonsistenz zwischen Paaren, Optikpegel und Fehlerzähler der Interfaces ändern sich langsam, und langsame Änderung ist genau das, was Schwellenwertalarme übersehen. Eine Optik, die in Richtung ihrer unteren Lichtgrenze driftet, ist diese Woche ein gelassener Austausch oder nächsten Monat ein Ausfall.

Ihre Checkliste zum Selbsttest des Monitorings

• Können Sie jedes Gerät auflisten, das am letzten Tag kein Log gesendet hat?
• Können Sie jedes Gerät auflisten, dessen gesicherte Konfiguration älter ist als seine letzte Änderung?
• Wann haben Sie zuletzt einen echten Alarm Ende zu Ende ausgelöst, und ist er angekommen?
• Entsprechen die Schweregrade, die einen Menschen alarmieren, einer schriftlichen Liste?
• Sehen Sie Ihr Netzwerk von außen, kontinuierlich?
• Sehen Sie durch, wenn nichts bekanntermaßen falsch ist?

Wir überwachen unser Netzwerk mit Zabbix, Graylog, Observium und einem RIPE Atlas Anchor, und wir führen diese Prüfungen nach Plan dagegen durch. Wenn Sie einen Anbieter wollen, der mit Messungen antwortet, oder Hilfe beim Testen Ihrer eigenen Kette, sprechen Sie mit uns.

Mit einem Ingenieur sprechen

Verwandt: Netzwerk-Monitoring und Nachweise · Wie wir Dinge ändern: Disziplin bei Netzwerkänderungen · Unser eigenes Netzwerk: zwei ASNs, viele Carrier, Peering