Viktor Schneider

Zurück zum Blog ·

Monitoring, das bei mir wirklich klingelt

Über meinen Hauptjob schreibe ich hier fast nie. Nicht, weil nichts passiert, sondern weil es um Kundensysteme geht, über die ich nicht öffentlich schreiben darf. Aber ein Teil davon ist übertragbar: Ich betreue seit Jahren virtualisierte Umgebungen – vSphere-Cluster, Linux-Hosts, dazu Checkmk als Monitoring. Und die Lektionen daraus gelten für jeden, der einen eigenen Server, einen Homelab oder eine kleine Infrastruktur überwacht. Deshalb hier ein Beitrag, der nichts über meine Kunden verrät, aber viel über das Handwerk.

Das erste Jahr war laut

Als ich mit Checkmk anfing, habe ich den Klassiker gebaut: jede verfügbare Regel aktiviert, jeden Host mit jedem Plugin überwacht, Schwellwerte großzügig übernommen. Das Ergebnis war ein Dashboard voller grüner Häkchen – und ein Postfach voller Meldungen, die niemanden interessierten.

Der Wendepunkt war eine Nacht, in der ich wegen einer Warnung geweckt wurde, die nichts bedeutete. Ein Dateisystem war bei 81 Prozent, der Schwellwert lag bei 80, und der Wert war seit drei Monaten langsam gewachsen. Es war kein Problem, das sofort gelöst werden musste. Es war ein Problem, das am Montag in zehn Minuten gelöst werden konnte. Aber das Monitoring kannte den Unterschied nicht – es meldete beides gleich laut.

Da habe ich verstanden: Monitoring ist nicht das Sammeln von Metriken. Monitoring ist die Entscheidung, was dich wecken darf.

Die eigentliche Arbeit ist das Ausmisten

Der harte Teil von Monitoring ist nicht das Einrichten. Ein Checkmk-Agent auf einem Linux-Host ist in Minuten installiert, ein vCenter lässt sich als Datenquelle anbinden. Der harte Teil ist, danach jede Regel zu hinterfragen:

Konkret heißt das bei mir: Ich unterscheide strikt zwischen Warnungen, die tagsüber jemand sieht, und kritischen Zuständen, die sofort eskalieren. Die Anzahl kritischer Regeln ist klein – und genau das ist der Punkt. Wenn alles kritisch ist, ist nichts kritisch.

Zwei Dinge, die ich jedem empfehle

Schwellwerte aus echten Daten ableiten, nicht raten. Der größte Fehler ist, eine CPU-Grenze bei 80 Prozent zu setzen, weil sie sich vernünftig anhört. Besser: den Host zwei Wochen beobachten, das tatsächliche Maximum ansehen, und den Schwellwert darüber legen – mit Puffer. Ein Host, der normalerweise bei 30 Prozent läuft und nur beim Backup auf 85 springt, braucht keinen 80er-Alarm, sondern eine 90er-Warnung, die das Backup-Fenster kennt.

Trends statt Momentaufnahmen. Der Speicherplatz ist das klassische Beispiel. Statt bei „voll" zu alarmieren, lohnt sich ein Blick auf die Wachstumsrate. df meldet dir heute 82 Prozent – aber die eigentliche Information ist, wie schnell es von 70 auf 82 ging. Ein Wert, der seit Wochen klettert, ist keine Überraschung, wenn er die Grenze reißt. Genau dafür hat Checkmk die Prognose-Funktionen – die meisten nutzen sie nur nie.

Was Checkmk für mich richtig macht

Ich will hier keine Werbung machen, aber ein paar Dinge sind ehrlich gut gelöst. Die Konfiguration ist für mich überschaubar: Hosts, Services, Regeln, alles in einer Struktur, die sich per API abfragen lässt. Das ist im Alltag mehr wert als jedes bunte Dashboard:

# Host samt Services ansehen
cmk -v mein-host

# Alle Regeln für einen Host auflisten
cmk -L mein-host

# Was wäre aktuell rot?
cmk --list-hosts | while read h; do cmk -v "$h" 2>&1 | grep -E 'CRIT|WARN'; done

Der letzte Einzeiler ist mein Lieblingswerkzeug: ein nüchterner Blick darauf, was gerade rot wäre – ohne Dashboard, ohne Klickerei, direkt in der Shell. Wenn ich nur eine Zahl am Tag ansehen kann, dann die.

Für vSphere gilt dasselbe Prinzip mit anderem Werkzeug: Ein Cluster interessiert mich nicht als Sammlung von VMs, sondern als drei Fragen – läuft der Storage, sind die Hosts gesund, und hat die Last noch Luft? Wer das nicht auf drei Sätze bringen kann, hat zu viele Metriken und zu wenig Antworten.

Die Kernaussage

Die beste Monitoring-Installation ist nicht die mit den meisten Checks, sondern die, bei der du bei jeder Meldung sofort weißt, was zu tun ist. Alles andere ist Rauschen – und Rauschen führt dazu, dass du irgendwann auch die wichtigen Meldungen ignorierst.

Das ist dieselbe Lektion wie beim Backup und beim statischen Generator: Der beste X ist nicht der mit den meisten Features, sondern der, den du tatsächlich betreibst. Ein Monitoring, das dich nachts wegen einer 81-Prozent-Warnung weckt, betreibst du nicht – du leidest darunter. Der Unterschied dazwischen ist eine Handvoll durchdachter Regeln.