Überwachung als Code: Uptime-Checks gehören in den Pull Request

Öffnen Sie Ihr Überwachungs-Dashboard und zählen Sie die Checks, die niemand erklären kann. Der mit dem 47-Sekunden-Intervall: Warum 47? Die zwei, die immer noch auf einen Staging-Server zeigen, der im März abgeschaltet wurde. Der HTTP-Check, der schon so lange gelb ist, dass das ganze Team Gelb als Grün liest. Jeden davon hat irgendwann jemand mit Absicht angelegt. Dann hat diese Person das Team gewechselt oder die Firma verlassen, und die Begründung ist mit ihr zur Tür hinausgegangen.

Das macht das Klicken auf Buttons mit der Überwachung. Die Konfiguration ist echt, sie trägt Gewicht, und sie steht nirgends, wo Sie sie lesen können. Sie können sie nicht diffen, nicht reviewen, und Sie können git blame nicht fragen, wer diesen Timeout gesetzt hat und was er sich dabei gedacht hat. Der Monitor soll das sein, worauf Sie sich verlassen, wenn alles andere brennt, und Sie haben ihn auf einem Haufen undokumentierter Klicks gebaut.

Legen Sie die Konfiguration also in die Versionsverwaltung. Nicht, weil Infrastruktur als Code eine Tugend wäre, die man sammelt, sondern weil ein Monitor genau die Art von stiller, langlebiger Konfiguration ist, die in dem Moment zum Risiko wird, in dem sie unsichtbar ist.

Kurz gesagt

Ein Monitor, der in einem Dashboard zusammengeklickt wurde, hat keinen Diff, keinen Verlauf und keinen Vermerk, warum er so ist. Verschieben Sie ihn in ein Repository, und jede Änderung wird zu einem Pull Request mit Review, den Sie per git blame nachvollziehen können; eine neue Region wird zu einem einzigen apply statt zu einem Nachmittag voller Klicks. Der Preis ist eine State-Datei, die Sie pflegen müssen. Uptimepage unterstützt das über Terraform, eine REST-API und MCP.

Was „als Code“ Ihnen tatsächlich bringt

Es ist nicht das Tippen. Einen Monitor in HCL zu deklarieren kostet mehr Tastenanschläge als ein Klick auf „Neuer Check“, und wer Ihnen erzählt, es gehe ums Tippen, hat nie mehr als drei davon gepflegt.

Es geht um den Pull Request. Wenn ein Monitor in einem Repository liegt, wird jede Änderung daran zu etwas, das sich eine zweite Person ansieht, bevor sie wirksam wird. „Warum senken wir das Intervall beim Zahlungs-Check auf zehn Sekunden?“ ist ein Gespräch, das man viel besser in einem PR führt als in einem Postmortem. Sie bekommen einen Diff, und Sie bekommen einen Verlauf. Sie können eine ganz neue Region aufbauen und vierzig Monitore mit einem apply reproduzieren statt mit vierzig Nachmittagen voller Klicks. Und wenn die Person, die den Schwellenwert gesetzt hat, geht, bleiben der Schwellenwert und seine Begründung in der Datei zurück.

Hier das kleinste Beispiel, das funktioniert, mit dem Terraform-Provider von Uptimepage:

terraform {
  required_providers {
    uptimepage = {
      source = "uptimepage/uptimepage"
    }
  }
}

resource "uptimepage_target" "api" {
  name     = "api prod"
  interval = 60

  check = {
    type = "http"
    http = {
      url = "https://api.example.com/healthz"
      expected_status = {
        kind  = "exact"
        exact = 200
      }
    }
  }
}

Beachten Sie, dass der check-Block verschachtelt ist und kein flacher Haufen von Feldern. Sie setzen type = "http" und füllen dann ein http = { ... } aus. Das ist eine bewusste Entscheidung im Schema, und eine gute: Eine flache Ressource, bei der url, port, host, record_type und cert_days alle auf oberster Ebene hängen, würde Sie Unsinn schreiben lassen, etwa einen TCP-Check mit einem HTTP-Status-Matcher, und Sie würden es erst beim Apply merken. Die verschachtelte Form sorgt dafür, dass sich ungültige Zustände gar nicht erst ausdrücken lassen. Die http-Felder können Sie nur setzen, wenn der Typ http ist. Das liest sich etwas umständlich und bewahrt Sie vor einer ganzen Kategorie von Fehlern, zu denen die flache Variante einlädt.

Was der Quickstart auslässt

Jedes Terraform-Tutorial hört bei „und jetzt apply ausführen“ auf. Drei Dinge, die man Ihnen dort nicht sagt, grob danach geordnet, wie schmerzhaft sie zubeißen.

Der State zählt, nicht das Dashboard. Terraform hält fest, was seiner Ansicht nach existiert. Erhöhen Sie ein Intervall in der Web-UI, weiß Terraform nichts davon; der nächste plan schlägt fröhlich vor, Ihre Änderung von Hand auf das zurückzusetzen, was im Code steht. Das ist so gewollt: Sobald ein Monitor im Code steht, gewinnt der Code, und Herumklicken im Dashboard wird zu einer Abweichung, die Terraform stillschweigend rückgängig macht. Legen Sie das vorab fest. Führen Sie terraform plan -refresh-only aus, um Abweichungen zu sehen, bevor sie Sie überraschen.

Block gelöscht, Monitor gelöscht. Entfernen Sie diese acht Zeilen aus Ihrer .tf-Datei, führen Sie apply aus, und der echte Check läuft nicht mehr. Stillschweigend. Bei den meisten Ressourcen ist das ein Achselzucken wert. Bei dem, was Ihre Produktiv-API überwacht, ist „Ich habe etwas Konfiguration aufgeräumt, und wir haben eine Woche lang die Zahlungen nicht überwacht“ ein echter Satz, den Leute laut ausgesprochen haben. Ich war näher daran, ihn zu sagen, als mir lieb ist. Behandeln Sie einen entfernten Monitor mit demselben Misstrauen wie eine gelöschte Tabelle, denn die Tragweite ist dieselbe: Sie bemerken es erst, wenn das, was Sie nicht mehr überwachen, kaputtgeht.

Geheimnisse im State. Wenn Ihr Check Basic Auth oder ein Token braucht, muss dieser Wert irgendwie zum Provider gelangen, und was immer Sie übergeben, wird im Klartext in die State-Datei geschrieben, lesbar für jeden mit Lesezugriff auf das Backend. Der Provider markiert das Passwort als sensitive, und es lohnt sich, genau hinzusehen, was Ihnen das bringt: sensitive hält den Wert aus der Plan-Ausgabe und aus Logs heraus. Aus dem State hält es ihn nicht heraus. Terraform 1.11 hat schon im Februar 2025 die eigentliche Lösung eingeführt, Write-only-Argumente: Werte, die beim Apply an den Provider durchgereicht und nie im State gespeichert werden. Bis der Uptimepage-Provider sie übernimmt, behandeln Sie die State-Datei selbst als Geheimnis:

variable "admin_password" {
  type      = string
  sensitive = true
}

resource "uptimepage_target" "admin" {
  name     = "admin panel"
  interval = 120

  check = {
    type = "http"
    http = {
      url = "https://admin.example.com/"
      expected_status = {
        kind = "range"
        range = {
          min = 200
          max = 299
        }
      }
      basic_auth = {
        username = "uptime"
        password = var.admin_password
      }
    }
  }
}

Das Passwort erreicht die API und taucht nicht in Ihrem Terminal auf, landet aber trotzdem im State. Nutzen Sie ein Backend, das ruhende Daten verschlüsselt, und entscheiden Sie bewusst, wer es lesen darf. Sobald der Provider Write-only-Argumente unterstützt, berührt das Passwort den State überhaupt nicht mehr; bis dahin ist das verschlüsselte Backend das, was es tatsächlich schützt.

Bauen Sie nicht neu, was Sie schon haben

Wenn Sie bereits von Hand angelegte Monitore haben, und die haben Sie, müssen Sie sie nicht neu eingeben. Den konfigurationsgesteuerten Import gibt es in Terraform seit 1.5: Schreiben Sie den Ressourcenblock so, wie Sie ihn haben wollen, ergänzen Sie einen import-Block, der auf die ID des bestehenden Monitors zeigt, und apply übernimmt ihn, statt ein Duplikat anzulegen.

import {
  to = uptimepage_target.api
  id = "the-existing-monitor-id"
}

Führen Sie plan aus und lesen Sie das Ergebnis mit Argusaugen. Ein sauberer Import zeigt keine Änderungen. Will der Plan etwas ändern, passt Ihr HCL noch nicht zur Wirklichkeit; korrigieren Sie also den Code, nicht den Monitor, bis der Diff leer ist. Löschen Sie dann den import-Block; er hat seine Aufgabe erfüllt. Ein Haken aus dem vorigen Abschnitt: Ein Geheimnis wie das Basic-Auth-Passwort lässt sich nicht über die API zurücklesen, ein Import stellt es also nicht wieder her. Sie setzen es einmal selbst in der Konfiguration, und ab da übernimmt Terraform.

Ein Workflow, der Sie nicht aus dem Bett holt

Die Form, die sich bewährt: Remote State mit Locking (damit nicht zwei Personen gleichzeitig ein Apply ausführen und ihn beschädigen), terraform plan automatisch bei jedem Pull Request, damit Reviewer den Diff sehen, und apply erst nach einem Merge in Ihren Hauptbranch. Niemand startet um 2 Uhr nachts ein apply vom Laptop. Dieselbe Disziplin, die Sie sich bei einer Datenbankmigration wünschen würden, angewandt auf das, was Ihnen meldet, dass die Datenbank ausgefallen ist.

Monitore, Statusseiten und Benachrichtigungskanäle sind hier alle einfach Ressourcen (uptimepage_status_page, uptimepage_notification_channel und Co.), und so lässt sich das gesamte öffentliche Gesicht Ihrer Überwachung (welche Seite was zeigt, wer über welchen Kanal alarmiert wird) im selben PR prüfen wie die Checks selbst.

Derselbe Trick funktioniert auch in die andere Richtung: Ein MCP-Server ist selbst etwas, das ausfallen kann, und der Monitor, der ihn überwacht, lässt sich hier neben allen anderen deklarieren.

Und dieselben Monitore, die Sie im Code deklarieren, kann ein KI-Assistent über MCP zurücklesen: „Was ist gerade kaputt, und seit wann?“, beantwortet in einfacher Sprache, aus genau der Konfiguration, die in Ihrem Repository liegt. Auf der einen Seite in einem Pull Request deklariert, auf der anderen von einem Assistenten abgefragt. Dieselben Daten, dieselben Scopes.

Langweilig, auch im Code

Wir haben schon früher argumentiert, dass Ihr Monitor das langweiligste und vertrauenswürdigste Ding sein sollte, das Sie besitzen. Die Konfiguration gehört dazu, und das sollten Sie bei der Wahl eines Tools berücksichtigen: Unter den Open-Source- und selbst gehosteten Optionen altern diejenigen, die ihre Konfiguration in einer Datei halten, die Sie committen können, besser als die, die sie hinter Klicks verstecken. Prüfen Sie auch, wer den Provider tatsächlich pflegt, denn viele Tools behaupten, Terraform zu unterstützen, und überlassen das einem Freiwilligen; die Terraform-Provider für Überwachung im Vergleich zeigt, wer was veröffentlicht. Ein Monitor, dessen Definition Sie lesen, reviewen, diffen und zurückrollen können, ist ein langweiligerer Monitor als einer, der aus Klicks zusammengesetzt ist, an die sich niemand erinnert, und langweilig ist hier ganz und gar als Lob gemeint.

Legen Sie die Konfiguration ins Repository. Lassen Sie eine zweite Person den Diff lesen. Ihr zukünftiges Ich, das in achtzehn Monaten mit zusammengekniffenen Augen auf ein 47-Sekunden-Intervall starrt, kann dann wenigstens git blame ausführen und herausfinden, dass Sie es waren.