Monitoring-Konfigurationen werden in vielen Teams bis heute über Web-Oberflächen verwaltet: Ein Techniker klickt einen neuen Check an, setzt Schwellenwerte und speichert. Was praktisch klingt, schafft in der Praxis stille Probleme. Konfigurationen sind nicht nachvollziehbar, nicht versioniert, schwer zu duplizieren und kaum testbar. Monitoring as Code überträgt die bewährten Prinzipien aus dem Infrastructure-as-Code-Umfeld direkt auf die Monitoring-Konfiguration – mit dem Ziel, Checks reproduzierbar, überprüfbar und automatisch ausrollbar zu machen.
Was bedeutet Monitoring as Code?
Beim Monitoring as Code werden sämtliche Monitoring-Regeln, Schwellenwerte, Alarmbedingungen und Check-Definitionen als Konfigurationsdateien gepflegt. Diese Dateien leben in einem Git-Repository, durchlaufen einen definierten Review-Prozess und werden über eine CI/CD-Pipeline automatisch in das Monitoring-System eingespielt.
Monitoring-Änderungen werden damit zu normalen Software-Änderungen: Sie werden begutachtet, getestet und nachvollziehbar dokumentiert. Gleichzeitig entsteht ein vollständiges Audit-Log darüber, wer wann welchen Alarm verändert hat – ein deutlicher Vorteil gegenüber manuell gepflegten Oberflächen, bei denen Änderungen oft spurlos verschwinden.
Warum Monitoring-Konfigurationen in Git gehören
Ein typisches Problem in wachsenden IT-Teams: Es gibt Hunderte von Monitoren, aber niemand weiß mehr genau, warum bestimmte Schwellenwerte so gesetzt wurden wie sie sind. Checks für längst abgeschaltete Services existieren weiter und produzieren regelmäßig Fehlalarme. Neue Umgebungen werden nicht mit dem gleichen Monitoring aufgesetzt, weil sich die bestehende Konfiguration nicht einfach exportieren oder duplizieren lässt.
Wenn Monitoring-Konfigurationen in Git verwaltet werden, lösen sich diese Probleme auf natürliche Weise. Änderungen sind durch Commit-Messages begründet. Pull Requests erzwingen Reviews. Branches ermöglichen das Testen neuer Alarm-Bedingungen ohne Risiko für die Produktion. Und das gesamte Monitoring lässt sich in einer neuen Umgebung innerhalb kurzer Zeit identisch aufbauen – zum Beispiel für Staging-Systeme oder nach einer Migration.
Tools und Ansätze im Überblick
Je nach verwendetem Monitoring-Stack gibt es unterschiedliche Werkzeuge:
Terraform und Monitoring-Provider
Für viele kommerzielle Monitoring-Dienste existieren Terraform-Provider. Damit lassen sich Checks, Alarme und Notification-Regeln als Terraform-Ressourcen deklarieren und über terraform apply automatisch ausrollen. Der Vorteil: Der gleiche Infrastructure-as-Code-Workflow, den viele Teams bereits für Cloud-Ressourcen verwenden, gilt jetzt auch für das Monitoring. Neuer Check? Ein .tf-File, ein Pull Request, ein Merge.
Prometheus und Alert-Konfigurationen als YAML
Im Open-Source-Umfeld ist Prometheus das Standardwerkzeug. Alerting-Regeln werden als YAML-Dateien definiert und direkt in die Prometheus-Konfiguration eingebunden. Mit dem mitgelieferten Tool promtool lassen sich diese Regeln syntaktisch validieren und sogar mit Unit-Tests gegenprüfen. Ein Lint-Schritt in der CI-Pipeline stellt sicher, dass fehlerhafte Alert-Regeln nie in Produktion gelangen.
Synthetische Checks und Blackbox-Konfigurationen
Auch synthetische Uptime-Checks lassen sich als Code definieren. Der Prometheus Blackbox Exporter erlaubt es, HTTP-, TCP-, DNS- und SSL-Checks als strukturierte Konfiguration zu hinterlegen. Endpunkte, Timeouts und Erwartungswerte werden versioniert und automatisch ausgerollt. Änderungen an Check-Endpunkten – etwa nach einer Migration – sind damit in wenigen Sekunden nachvollziehbar.
Der Workflow in der Praxis
Ein typischer Monitoring-as-Code-Workflow folgt diesem Ablauf:
- Ein Ingenieur öffnet einen Pull Request mit einer neuen Alert-Regel oder einem geänderten Schwellenwert.
- Die CI-Pipeline validiert die Syntax und führt, falls vorhanden, Unit-Tests für die Alarm-Logik aus.
- Ein zweiter Ingenieur reviewed die Änderung und prüft, ob der neue Schwellenwert fachlich sinnvoll ist.
- Nach dem Merge rollt eine CD-Pipeline die Konfiguration automatisch in das Monitoring-System ein.
- Ein Smoke-Test verifiziert, dass der neue Check korrekt registriert wurde und Daten liefert.
Dieser Prozess mag auf den ersten Blick aufwändiger wirken als ein Klick in einer Oberfläche. In der Praxis spart er erheblich Zeit – weil Fehler früh erkannt werden, keine unbegründeten Konfigurationsänderungen entstehen und das gesamte Monitoring reproduzierbar bleibt.
Typische Fallstricke
Wer mit Monitoring as Code beginnt, begegnet einigen bekannten Problemen:
- Gemischte Änderungspfade: Wenn manuelle Änderungen über die Web-Oberfläche und automatische Deployments gleichzeitig möglich sind, entstehen Inkonsistenzen. Teams müssen klar festlegen: Konfigurationen werden ausschließlich über den Code-Pfad geändert. Manuell vorgenommene Anpassungen werden beim nächsten Deployment überschrieben.
- Migrations-Aufwand: Bestehende Monitoring-Setups haben oft Hunderte von historisch gewachsenen Checks. Die Migration sollte schrittweise erfolgen – beginnend mit kritischen Diensten.
- Testbarkeit: Alert-Regeln zu testen ist anspruchsvoll. Tools wie pint (ein Prometheus-Linter) oder die eingebauten Prometheus-Unit-Tests helfen dabei, häufige Fehler automatisch zu finden, bevor sie in Produktion gelangen.
- Secrets in Konfigurationsdateien: Passwörter, API-Keys oder SNMP-Community-Strings dürfen nie direkt in Git versioniert werden. Secrets werden über Umgebungsvariablen oder ein Secret-Management-System eingebunden.
Monitoring as Code in kleinen Teams
Monitoring as Code ist kein Privileg großer Platform-Teams. Auch kleinere IT-Teams profitieren davon, wenn sie ihre Checks als YAML oder Terraform-Konfigurationen pflegen. Der Einstieg kann mit einem einfachen Repository beginnen, das nur die wichtigsten Alerting-Regeln enthält. Mit wachsender Erfahrung lässt sich der Scope sukzessive erweitern.
Wichtig ist, dass das Team die Konvention konsequent einhält: Kein Check über die Web-Oberfläche ohne anschließende Übernahme in das Repository. Anderenfalls driften Konfiguration und Code schnell auseinander.
KI-Unterstützung im Monitoring-as-Code-Workflow
Aktuelle KI-Werkzeuge können den Prozess sinnvoll ergänzen. Sprachmodelle sind in der Lage, aus einem Incident-Postmortem automatisch Vorschläge für neue Alert-Regeln zu generieren. Sie können bestehende Konfigurationen analysieren und redundante oder nie auslösende Alarme identifizieren. Einige Teams nutzen KI-Assistenten direkt im Code-Editor, um Prometheus-YAML oder Terraform-Ressourcen auf Basis von natürlichsprachlichen Beschreibungen zu erstellen.
Der Review durch Menschen bleibt dabei unverzichtbar. KI generiert Vorschläge – die fachliche Beurteilung, ob ein Schwellenwert für das konkrete System sinnvoll ist, liegt weiterhin beim Engineering-Team. Gut beschriebene Alert-Regeln mit Kommentaren erleichtern außerdem das spätere Debugging und machen KI-Vorschläge präziser.
Monitoring as Code ist kein Selbstzweck. Es dient dem Ziel, dass das gesamte Team zu jeder Zeit nachvollziehen kann, was überwacht wird – und warum.
Bild: Grafana-Dashboard-Screenshot von Wikimedia Commons (Public Domain, 2018)
Quellen
- Prometheus-Dokumentation: Alerting-Regeln, promtool und Unit-Tests (prometheus.io/docs)
- Cloudflare pint – Prometheus Rule Linter (cloudflare.github.io/pint)
- HashiCorp Terraform-Dokumentation zu Infrastructure as Code (terraform.io/docs)
