September 2026

Der Pathly-Terraform-Provider, in der Praxis

APIHinter den Kulissen

Er ist auf der Registry veröffentlicht. Hier die Dateien, die man wirklich schreibt: die kleinste sinnvolle, ein ganzer Bestand als Datum beschrieben, und die Übernahme handgepflegter Überwachung.

Installieren

Der Provider heißt pathlyhq/pathly auf der öffentlichen Registry. Es gibt nichts zu kompilieren und nichts in einen Spiegel zu legen: die Versionsangabe genügt, und der Init-Befehl lädt ihn herunter. Die Bedingung ~> 0.1 lässt Korrekturen zu und weist eine spätere 0.2 ab, was die richtige Einstellung ist, solange das Schema nicht durch eine 1.0 eingefroren ist.

terraform {
  required_version = ">= 1.6"
  required_providers {
    pathly = {
      source  = "pathlyhq/pathly"
      version = "~> 0.1"
    }
  }
}

# Aucun argument : la clé vient de PATHLY_API_TOKEN.
provider "pathly" {}

Der provider-Block ist leer, und das ist keine Nachlässigkeit. Der Schlüssel wird aus der Umgebungsvariablen PATHLY_API_TOKEN gelesen. Über eine Terraform-Variable übergeben, landete er im Klartext in der Statusdatei, die man immer erst zu verschlüsseln vergisst, nachdem man sie irgendwohin geschoben hat. Der Provider weigert sich zudem, mit etwas anderem als localhost http zu sprechen: der Schlüssel reist in einem Autorisierungs-Header und wäre für jeden Vermittler lesbar.

Die kleinste sinnvolle Datei

Ein Szenario, eine Adresse, ein Intervall und ein Text, den man auf der Seite erwartet. Der letzte Punkt macht den Unterschied zwischen Server- und Seitenüberwachung: eine Anwendungsfehlerseite antwortet bestens mit HTTP 200, und nur der erwartete Text entlarvt sie.

resource "pathly_scenario" "site" {
  name         = "Home page"
  url          = "https://shop.example.com"
  interval_sec = 300
  expect_text  = "Our products"
  tags         = ["prod"]
}

Ein Bestand als Datum beschrieben

Ab drei oder vier Abläufen wird ein Block je Ressource zu einer Liste, die man bei jeder Ergänzung erneut liest. Sie in einer Variablen zu beschreiben und darüber zu iterieren ändert den Charakter der Datei: ein Ablauf hinzuzufügen wird zu einer Datenzeile, und Schwellen-, Ordner- und Etikettenregeln bleiben für alle gleich, ohne dass jemand daran denken muss.

resource "pathly_scenario" "journey" {
  for_each = var.journeys

  name         = each.value.name
  url          = each.value.url
  interval_sec = each.value.interval_sec
  expect_text  = each.value.expect_text

  # Un seuil de latence par parcours : le paiement tolère
  # moins qu'une page d'accueil servie depuis le cache.
  max_latency_ms  = each.value.max_latency_ms
  expected_status = 200
  severity        = each.value.severity
  tags            = concat(["terraform", var.environment], each.value.tags)
}

# Un objectif de disponibilité par parcours critique, qui
# alerte à 80 % du budget d'erreur dépensé : au-delà, il
# reste trop peu de marge pour le reste du mois.
resource "pathly_sla_target" "objective" {
  for_each = {
    for key, j in var.journeys : key => j if j.severity == "critical"
  }

  scenario_id          = pathly_scenario.journey[each.key].id
  objective_pct        = 99.9
  window_days          = 30
  exclude_maintenance  = true
  warn_at_budget_ratio = 0.8
}

Das Verfügbarkeitsziel schließt Wartungsfenster aus, was nur sinnvoll ist, wenn diese Fenster auch im Code stehen. Eine auf der einen Seite deklarierte Wartung und ein Ziel, das sie auf der anderen ignoriert, verbrauchen das Fehlerbudget durch eine angekündigte Unterbrechung — also eine Warnung, die einen geplanten Eingriff bestraft.

# Sauvegarde hebdomadaire : les échecs dans cette fenêtre
# ne dépensent pas le budget d'erreur.
resource "pathly_maintenance_window" "backup" {
  weekday      = 7 # dimanche
  start_minute = 3 * 60
  duration_min = 120
  reason       = "Weekly backup"
}

Erkennen, was von Hand angelegt wurde

Das ist der nützlichste Einsatz der Datenquelle und der, an den man am wenigsten denkt. Sie liest den Bestand so, wie die API ihn sieht. Verglichen mit dem, was der Code deklariert, benennt die Differenz die in der Konsole angelegten und in den Dateien fehlenden Szenarien: jene, die niemand prüft und die niemand beim Abbau einer Umgebung entfernt.

data "pathly_scenarios" "prod" {
  filter_tag = var.environment
  depends_on = [pathly_scenario.journey]
}

output "scenarios_outside_terraform" {
  value = [
    for s in data.pathly_scenarios.prod.scenarios : s.name
    if !contains([for j in pathly_scenario.journey : j.id], s.id)
  ]
}

Dasselbe gilt für Werte, die die API nie zurückgibt. Ein Webhook-Ziel wird geschrieben und nicht zurückgelesen: stattdessen eine Prüfsumme aus zwölf Zeichen, die sich ändert, sobald sich die Adresse ändert. Sie erlaubt keine Rekonstruktion des Ziels und genügt, um im Plan zu sehen, dass es anderswo geändert wurde.

output "webhook_fingerprint" {
  value = pathly_webhook.alerts.url_fingerprint
}

Bestehende Überwachung übernehmen

Niemand baut seinen Bestand neu auf, um zu Code zu wechseln, und der Provider verlangt es nicht. Jede Ressource wird über ihre Kennung importiert, jene in der Adresse des Szenarios in der Konsole. Nach dem Import zeigt der Plan die Differenz zwischen Bestehendem und dem, was die Datei beschreibt: solange er nicht leer ist, ändert das Anwenden das Szenario an Ort und Stelle, statt ein zweites anzulegen.

terraform import pathly_scenario.checkout mon_01H8ZK…

Das Kriterium, das über die Brauchbarkeit entscheidet, passt in einen Satz: nach einem Apply muss der nächste Plan leer sein. Ein Provider, der bei jedem Durchlauf eine Änderung vorschlägt, bringt seinen Nutzern sehr schnell bei, seine Pläne nicht mehr zu lesen — und an dem Tag, an dem der Plan etwas Wahres sagt, sieht es niemand. Das ist die unsichtbarste Arbeit am Provider, und die, auf der seine Tests am meisten bestehen.

Was der Provider nie tun wird

Einen API-Schlüssel ausstellen oder widerrufen: ein Schlüssel, der das kann, hebt die Geltungsbereiche aller anderen auf, und eine Konfigurationsdatei darf sich nicht selbst erweitern.
Ein Mitglied einladen: dieselbe Rechteausweitung über Umwege, denn das neue Konto stellt danach beliebige Schlüssel aus.
Den Tarif wechseln oder die Abrechnung anfassen: eine CI-Pipeline darf keine wiederkehrenden Ausgaben verursachen.

Diese Lücken sind keine verspäteten Funktionen. Ein Provider, der alles abdeckt, verlangt am Ende einen Schlüssel, der alles kann, und dieser Schlüssel liegt dann in den Variablen einer Pipeline, die mehr Leute lesen als gedacht. Was hier fehlt, fehlt absichtlich und geschieht in der Oberfläche, durch einen identifizierten Menschen.