Synthetic Monitoring mit Puppet, YAML und Icinga2: Checkly-ähnliche Checks unter eigener Kontrolle

Viele Monitoring-Setups sind historisch gewachsen: einzelne HTTP-Checks, Sonderlogik in Templates, manuelle Anpassungen in Icinga2 und am Ende viel Wissen, das nur in Köpfen existiert. Spätestens wenn mehrere Plattformen oder Kundenumgebungen mit ähnlichen Anforderungen betreut werden, wird das unnötig teuer.

Genau aus diesem Grund haben wir ein neues Synthetic-Monitoring-Modul aufgebaut, das sich an einem klaren Prinzip orientiert: Checks werden deklarativ in YAML beschrieben, per Puppet ausgerollt und automatisch sauber in Icinga2 eingehängt.

Was das Modul konkret löst

Ziel war kein generisches Lab-Feature, sondern ein Pattern, das im Alltag von Betriebs- und Kundenumgebungen wirklich trägt.

Die Anforderungen waren klar:

• HTTP- und API-Checks zentral definieren
• keine manuelle Objektpflege in Icinga2
• wiederverwendbares Schema über mehrere Puppet-Repos hinweg
• JSON-basierte Assertions für APIs
• SSL-Laufzeit automatisch mitprüfen, wenn eine URL per HTTPS läuft
• Event-Kommandos direkt aus dem Check-Kontext heraus nutzbar machen

Damit entsteht ein Setup, das sich funktional an SaaS-Werkzeuge wie Checkly anlehnt, aber vollständig in die bestehende eigene Monitoring- und Puppet-Landschaft integriert bleibt.

Die Architektur: YAML → Puppet → Icinga2

Das Grundmodell ist bewusst einfach gehalten:

1. Checks werden in Hiera/YAML beschrieben
   URL, Methode, Header, Suchstrings, JSON-Assertions, Host-Zuordnung und optionale Event-Logik.

2. Puppet rendert daraus die Icinga2-Konfiguration
   inklusive passender Templates, Plugin-Deployment und sauberem Einhängen in die bestehende Struktur.

3. Icinga2 führt die Checks aus
   auf Basis eines eigenen Plugins für HTTP/API-Prüfungen mit Response- und JSON-Validierung.

Der eigentliche Gewinn liegt nicht im einzelnen Check, sondern in der Konsistenz: neue Prüfungen werden nicht mehr “irgendwie dazugebaut”, sondern folgen einem belastbaren Muster.

Was im Modul heute bereits enthalten ist

Im aktuellen Stand deckt das Modul mehr ab als einen einfachen URL-Check:

• klassische HTTP-Uptime-Checks
• API-Checks mit Headern und Request-Body
• JSON-Assertions über definierte Pfade
• Content-Checks über erwartete Strings
• automatische zusätzliche SSL-Zertifikatsprüfung bei https://
• Zuordnung über assigns an bestehende Check-Hosts
• Event-Kommandos für Reaktionen im Betrieb

Gerade die Kombination aus HTTP-Logik und API-Assertions ist im Alltag wertvoll. Eine Webseite kann 200 liefern und trotzdem funktional defekt sein. Für APIs gilt das erst recht: entscheidend ist nicht nur die Erreichbarkeit, sondern ob die erwartete Struktur und der inhaltliche Status zurückkommen.

Warum die Integration in bestehendes Monitoring wichtiger ist als ein Greenfield-Ansatz

Ein häufiger Fehler bei solchen Vorhaben ist, ein neues Monitoring-Konzept neben das bestehende System zu stellen. Das wirkt auf den ersten Blick sauber, führt aber oft zu doppelter Pflege und unklarer Zuständigkeit.

Deshalb wurde das Modul bewusst auf das vorhandene Pattern angepasst:

• dieselbe Hiera-Logik wie im bestehenden Monitoring
• derselbe Template-Stil für Icinga2-Services
• keine künstlichen Sonderhosts, sondern saubere Zuordnung an bestehende Check-Hosts
• README- und Betriebsdokumentation direkt mitgezogen

Das ist betrieblich der entscheidende Unterschied zwischen “funktioniert technisch” und “kann dauerhaft sauber betrieben werden”.

Die Realität liegt in den Details

Wie so oft lag der Aufwand nicht nur in der Idee, sondern in den Randfällen.

Ein paar Beispiele aus der Umsetzung:

• JSON-Pfade mit $ mussten für Icinga2 korrekt escaped werden, damit sie nicht als Macro interpretiert werden.
• Bestimmte APIs liefern ohne passende Header oder Format-Parameter nicht JSON, sondern XML.
• Das Service-Naming musste an die reale Monitoring-Sprache angepasst werden.
• Event-Script-Integration war wichtig, damit Checks nicht nur melden, sondern auch in bestehende Reaktionspfade passen.

Genau an solchen Punkten trennt sich ein schönes Konzept von einem belastbaren Betriebsmodul.

Wofür sich das in der Praxis eignet

Das Pattern ist besonders interessant für Umgebungen, in denen viele externe oder interne Endpunkte geprüft werden müssen, zum Beispiel:

• Websites mit kritischen Login- oder Checkout-Pfaden
• Kundenportale und API-Endpunkte
• Plattformen mit mehreren Check-Hosts und unterschiedlichen Zuständigkeiten
• Monitoring-Setups, in denen SSL-Zustand, Inhalt und API-Antworten gemeinsam bewertet werden sollen

Damit wird aus “Seite erreichbar” ein deutlich aussagekräftigeres Service-Monitoring.

Was sich daraus operativ ableiten lässt

Der eigentliche Hebel liegt nicht nur in der Einführung eines neuen Moduls, sondern in der Standardisierung.

Wenn neue Checks sauber in YAML beschrieben, reproduzierbar ausgerollt und konsistent dokumentiert werden, sinken drei Dinge gleichzeitig:

• manueller Pflegeaufwand
• Fehler bei Änderungen
• Abhängigkeit von Einzellösungen pro Kunde oder Plattform

Das verbessert nicht nur das Monitoring, sondern auch die Änderbarkeit der gesamten Betriebsumgebung.

Fazit

Synthetic Monitoring wird besonders dann interessant, wenn es nicht als Insel gebaut wird, sondern sauber in die vorhandene Betriebsrealität passt. Genau dort liegt der Mehrwert dieses Moduls: deklarative Checks, konsistente Puppet-Ausrollung, Icinga2-Integration und genügend Flexibilität für reale API- und Web-Szenarien.

Wenn ihr ähnliche Monitoring-Strecken standardisieren wollt, helfen meist drei Dinge am meisten: klare YAML-Schemata, saubere Template-Patterns und ein Betriebsteam, das nicht jeden neuen Check wieder neu erfinden muss. Für die Umsetzung rund um Puppet, Managed IT und stabile Server-Infrastrukturen unterstützen wir gern.