BEOBACHTBARKEIT · BETRIEB · AUTOMATISIERUNG
Als ich 2000 dazukam, gab es eine Handvoll Server und Skripte zur Logauswertung. Was für den Anfang genügt hatte, konnte mit dem Wachstum und der zunehmenden Komplexität nicht mithalten.
Reaktive Logauswertung durch ein mitwachsendes Monitoring ersetzen und Probleme erkennen, bevor Nutzer sie melden.
Mit Nagios und Zabbix starten, Service-Checks und Alarmierung aufbauen und Performancemetriken für Trendanalysen aufzeichnen.
Eine über die Jahre gewachsene Monitoring-Praxis, später ergänzt durch Grafana und Checkmk: früh warnen und die langfristige Entwicklung verstehen.
Lesen Sie die Fallstudie+
Kleine Umgebung, wachsende blinde Flecken. Am Anfang standen nur eine Handvoll Server und Skripte, die Logfiles analysierten. Mit dem Wachstum stieß dieser Ansatz an Grenzen: Er skalierte nicht ausreichend und konnte die zunehmende Komplexität nicht mehr abbilden. Vor allem war er reaktiv – er zeigte, was bereits passiert war.
Chef und Kunden sind keine Monitoring-Werkzeuge. Warum ein Problem erst bemerken, wenn es schon eingetreten ist? Wenn der Chef oder gar ein Kunde als Erster eine Störung meldet, läuft der Betrieb der Situation bereits hinterher. Neben dem eigentlichen Ausfall steht dann auch das Vertrauen in die Arbeit des Teams auf dem Spiel – nach innen wie nach außen.
Der Klassiker: auslaufende TLS-Zertifikate. 2000 gab es die heute vertrauten Möglichkeiten zur automatischen Zertifikatserneuerung noch nicht in dieser Form. Let’s Encrypt kam erst deutlich später, 2015. Wir mussten bevorstehende Ablaufdaten überwachen, statt sie durch eine fehlgeschlagene Verbindung zu entdecken. Anforderungen und Zertifikatsanbieter können unterschiedlich sein; auch eine automatisierte Erneuerung muss überwacht werden.
Erkennen, melden und Daten behalten. Unsere erste Wahl waren Nagios und Zabbix. Wir brauchten Prüfungen, die Probleme erkannten, und Meldungen, die jemanden erreichten, der handeln konnte. Die Benachrichtigungen gingen insbesondere an das 24/7-Bereitschaftsteam, damit Störungen rund um die Uhr bearbeitet werden konnten. Aus Kostengründen hatte die Website damals noch keine High-Availability-Architektur. Zuverlässige Erkennung und schnelle Reaktion waren deshalb entscheidend, um eine möglichst hohe Servicequalität zu sichern; das Monitoring selbst beseitigte das Ausfallrisiko nicht. Über die Jahre kamen unterschiedliche Meldewege zum Einsatz, darunter SMS, WhatsApp und PagerDuty. Das beschreibt die spätere Entwicklung, nicht einen vollständigen Werkzeugkasten von 2000.
Vom einzelnen Alarm zur Entwicklung über Zeit. Aufgezeichnete Performancemetriken ermöglichten den Blick über den einzelnen Alarm hinaus: Wie entwickelten sich Last, Latenzen und verfügbare Kapazität? Später ergänzten Grafana und Checkmk die Werkzeuglandschaft. Das Ziel blieb, Verschlechterungen früher zu erkennen und anhand der Daten zu verstehen, wohin sich die Systeme entwickelten.
Der Gedanke dahinter. Monitoring ist mehr als eine Sammlung von Dashboards. Es soll dem Team die Chance geben, zu handeln, bevor jemand anders auf ein Problem aufmerksam machen muss.
Historische Quelle: Ankündigung des ersten öffentlichen Let’s-Encrypt-Zertifikats (2015).
- Nagios
- Zabbix
- Grafana
- Checkmk


Cloud / Systeme