Servermonitoring mit Gatus

Worum es geht — Active-Probing statt Agent-Telemetrie

Gatus ist ein in Go geschriebenes Open-Source-Werkzeug für synthetisches Endpoint-Monitoring. Es prüft in regelmäßigen Intervallen aus der Außensicht, ob ein definierter Endpoint erreichbar ist, korrekt antwortet und sich erwartungsgemäß verhält — und es erzeugt aus diesen Prüfungen eine Statusseite, die intern oder öffentlich geteilt werden kann. Bei Auffälligkeiten löst es Alarme über die üblichen Channels aus.

Wichtig ist die saubere Einordnung: Gatus ist kein Infrastructure-Monitoring. Es ersetzt weder Zabbix noch Prometheus. Es sammelt keine CPU-, RAM- oder Disk-Metriken vom Hostsystem, es scrapt keine Metriken-Endpunkte, es schreibt keine Time-Series. Was Gatus liefert, ist ein zeitlich aggregiertes „antwortet — antwortet nicht" pro Endpoint, ergänzt um Antwortzeit, ausgewählte Body-Inhalte und Zertifikatsdetails.

Diese bewusste Begrenzung ist die eigentliche Stärke. Wer 200 Services über drei Rechenzentren betreibt und wissen will, ob die kundenrelevanten APIs aus der Außensicht erreichbar sind, bekommt mit Gatus in wenigen Stunden ein produktives System. Wer dasselbe mit einem klassischen Monitoring-Stack erreichen will, plant Tage bis Wochen. Genau in diese Lücke zielt das Werkzeug: zwischen den schwergewichtigen Infrastructure-Suiten (Zabbix, Nagios, Icinga) auf der einen Seite und reinen Visualisierungs-Plattformen (Grafana) auf der anderen.

Lizenz und Reife sind unauffällig solide: Apache 2.0, aktiv gepflegt, regelmäßige Releases, eine wachsende Nutzerbasis. Kein kommerzielles Backing, aber auch kein Hobby-Repo — die Art von Projekt, die man in regulierten Branchen ohne schlechtes Gewissen produktiv einsetzt.

Architektur und Datenfluss

Gatus läuft als einzelnes Go-Binary. Es gibt keinen Agent, keinen separaten Sammler, keinen Konfigurations-Server. Die gesamte Konfiguration liegt in einer YAML-Datei, die beim Start gelesen und bei Änderungen automatisch nachgeladen wird. Drei Bestandteile arbeiten zusammen.

Ein Scheduler führt für jeden konfigurierten Endpoint einen Probe-Loop im konfigurierten Intervall aus. Eine Conditions-Engine prüft die Antwort des Endpoints gegen die deklarierten Erwartungen — Status-Code, Body-Inhalt, Antwortzeit, Zertifikatslaufzeit. Ein Storage-Backend hält die History der Ergebnisse: wahlweise im Arbeitsspeicher (flüchtig), in einer SQLite-Datei (für Einzelinstanzen üblich) oder in einer PostgreSQL-Datenbank (für hochverfügbare Setups).

Auf der Ausgabeseite stehen drei gleichberechtigte Konsumenten: die mitgelieferte Web-Oberfläche, die gleichzeitig als Statusseite dient, eine REST-API für externe Integrationen, und der Alerting-Fan-out an Slack, Microsoft Teams, PagerDuty, Opsgenie, Email, Webhooks und ein gutes Dutzend weiterer Channels. Die folgende Abbildung zeigt den Fluss in der Übersicht — von der Konfiguration links über die aktiven Probes in der Mitte bis zur Aggregation und Darstellung rechts.

Drei Eigenschaften dieser Architektur sind in der Praxis entscheidend. Erstens: alles in einem Prozess. Es gibt kein Deployment-Diagramm mit fünf Komponenten, kein Helm-Chart mit zwölf Sub-Charts. Sie starten ein Binary, mounten eine YAML-Datei, und das System läuft — als Docker-Container, in Kubernetes mit einem schlichten Deployment, hinter einem Reverse-Proxy oder direkt auf einer kleinen Linux-VM.

Zweitens: das Probing ist aktiv und außenstehend. Gatus fragt den Endpoint, anstatt von einem Agent auf dem Zielsystem gespeist zu werden. Das hat zwei Konsequenzen. Sie messen exakt das, was auch Ihre Anwender erleben — Netzwerk, TLS-Handshake, Reverse-Proxy, alles inklusive. Und Sie müssen auf dem überwachten System keine Software installieren. Bei externen Drittsystemen — Behörden-APIs, Bank-Webservices, Zahlungsanbietern — ist das ohnehin der einzig mögliche Weg.

Drittens: die Konfiguration ist Code. Die YAML-Datei lebt in einem Git-Repository, wird per Pull-Request geändert, im CI validiert und über GitOps auf das laufende System ausgerollt. Reviewbar, versionierbar, reproduzierbar. Wer im Bereich kritischer Infrastrukturen oder regulierter Branchen arbeitet, kennt den Wert dieser Eigenschaft sofort.

Probes und die Conditions-DSL

Gatus bringt eine breite Palette von Probe-Typen mit, die die meisten praxisrelevanten Fälle abdecken: HTTP und HTTPS, TCP, UDP, ICMP (Ping), DNS, TLS- und STARTTLS-Zertifikatsprüfung, SSH, gRPC, WebSocket. Diese Auswahl deckt den Großteil dessen ab, was im Enterprise-Umfeld als „prüfbarer Endpoint" gilt — von der öffentlichen REST-API bis zum internen LDAP-Server.

Spannender als die reine Probe-Liste ist die Conditions-DSL. Anstatt einen Endpoint nur darauf zu prüfen, ob er einen HTTP-200 zurückgibt, lassen sich strukturierte Erwartungen formulieren.

endpoints:
  - name: buergerportal-status
    url: https://portal.musterstadt.de/api/health
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 800"
      - "[BODY].status == UP"
      - "[BODY].database.status == UP"
      - "[CERTIFICATE_EXPIRATION] > 240h"

Was hier passiert, ist mehr als ein klassischer Liveness-Check. Es wird geprüft, ob der Endpoint antwortet ([STATUS]), ob er das innerhalb akzeptabler Zeit tut ([RESPONSE_TIME]), ob der zurückgegebene JSON-Body die fachlich richtigen Werte enthält ([BODY]…), und ob das TLS-Zertifikat noch lange genug gültig ist — [CERTIFICATE_EXPIRATION] > 240h, also mindestens zehn Tage Restlaufzeit. Fällt eine dieser Bedingungen aus, gilt der Endpoint als nicht in Ordnung.

Diese DSL erspart eine ganze Klasse separater Werkzeuge. Zertifikats­ablauf-Überwachung, Health-Check-Validierung, einfache Funktionstests gegen produktive APIs — alles im selben System, mit derselben Syntax. Für komplexere Fälle existieren Helfer wie len(...) für Längenprüfungen, pat(...) für Pattern-Matches und has(...) für strukturelle Tests.

Ein zweites Beispiel zeigt, dass auch reine Netzwerk-Probes denselben Komfort bekommen:

endpoints:
  - name: keycloak-ldap-bridge
    url: tcp://ldap.intranet.local:636
    interval: 5m
    conditions:
      - "[CONNECTED] == true"
      - "[RESPONSE_TIME] < 1500"

  - name: zertifikat-portal
    url: https://portal.musterstadt.de
    interval: 1h
    conditions:
      - "[CERTIFICATE_EXPIRATION] > 336h"

Im ersten Fall verlässt Gatus die HTTP-Welt und prüft einen TCP/TLS-Endpoint — die Conditions arbeiten unverändert. Im zweiten Fall genügt ein stündlicher Lauf, der ausschließlich die Restlaufzeit des Zertifikats prüft; abgelaufene Zertifikate werden so zwei Wochen vorher zum Thema, lange bevor ein Anwender den Browser-Warnhinweis sieht.

Alerting, Storage und Statusseite

Drei Bereiche, in denen Gatus über die reine Probe-Funktion hinausgeht — und in denen es seine pragmatischen Defaults ausspielt.

Alerting

Pro Endpoint und pro Channel wird ein Schwellwert konfiguriert: eine failure-threshold (etwa: erst nach drei aufeinander­folgenden Fehlschlägen alarmieren) und eine success-threshold für die Recovery-Meldung. Diese Mechanik unterdrückt das berüchtigte Flapping zuverlässig — ein kurzes Netzhickup führt nicht zur Mitternachts-SMS. Die Channels reichen von Slack, Microsoft Teams, Mattermost und Discord über Email (SMTP), PagerDuty, Opsgenie, Telegram, Matrix bis zu Twilio (SMS), Pushover, Gotify, Ntfy und generischen Webhooks. Letztere öffnen die Tür für n8n, Zapier oder eigene Endpoints — etwa, um automatisch ein Ticket im internen ITSM anzulegen.

Storage

Drei Backends stehen zur Wahl. Für die schnelle Auswertung in der Entwicklungs­umgebung genügt der Memory-Speicher; nach einem Neustart ist die History weg. Für produktive Einzelinstanzen ist SQLite die übliche Empfehlung — eine Datei, die mit dem Binary mitläuft, ohne separaten Datenbank-Server. Wer Hochverfügbarkeit oder mehrere Replicas braucht, hängt PostgreSQL an. Die Storage-Wahl ist eine YAML-Zeile, kein Architektur-Beschluss.

Statusseite

Die mitgelieferte Web-Oberfläche ist gleichzeitig Statusseite. Endpoints lassen sich in Gruppen ordnen und pro Gruppe als sichtbar oder versteckt markieren. Eine öffentliche Statusseite, wie sie SaaS-Anbieter unter status.… betreiben, ist damit eine Konfigurations­frage, kein eigenes Produkt. Für regulierte Branchen ist das relevant: die Statusseite läuft self-hosted, auf eigener Infrastruktur, ohne dass Daten an einen Drittanbieter fließen. Wer im öffentlichen Sektor oder im Finanzumfeld eine Statusseite betreibt, kennt die andernfalls langwierigen Datenschutz­fragen mit US-amerikanischen SaaS-Anbietern.

Gatus, Zabbix und Grafana — drei Werkzeuge, drei Fragen

Wer Gatus zum ersten Mal sieht, fragt fast immer, wie es sich zu den etablierten Schwergewichten verhält. Die saubere Antwort: die drei Werkzeuge beantworten unterschiedliche Fragen und sind komplementär, nicht konkurrent.

Zabbix beantwortet die Frage: „Wie geht es meinen Servern, Netzwerken und Diensten von innen?" Es arbeitet primär agent-basiert. Auf jedem überwachten System läuft ein Zabbix-Agent, der Metriken in den zentralen Server pusht (alternativ pollt der Server). CPU-Last, RAM, Disk-Belegung, SNMP-Daten aus Netzwerk-Hardware, Logfile-Inhalte, Trigger-Logik in einer eigenen Sprache. Das System speichert Metriken in einer eigenen Datenbank, hat ein komplettes Web-Frontend und kann Auto-Discovery in großen Netzen. Zabbix ist mächtig — und der Aufwand entspricht der Mächtigkeit. Eine produktive Inbetriebnahme misst man in Wochen, nicht in Stunden.

Grafana beantwortet die Frage: „Wie visualisiere und korreliere ich Metriken, Logs und Traces, die andere Systeme erheben?" Es ist primär eine Visualisierungs-Plattform. Die Datenquellen sind Prometheus (Metriken), Loki (Logs), Tempo (Traces), Influx oder Elasticsearch. Grafana selbst probt nicht — es zeichnet Dashboards aus dem, was andere Komponenten gesammelt haben. (Grafana Synthetic Monitoring und k6 Cloud sind separate Produkte, die das Probing nachreichen, in der Regel als Cloud-Dienst.)

Gatus beantwortet die Frage: „Sind meine Endpoints aus Anwendersicht erreichbar und korrekt — und wo zeige ich das?" Es probt aktiv, von außen, gegen definierte URLs und Hosts. Es hat keine Time-Series-Sicht, keine Korrelations-Dashboards, keine Host-Agenten. Dafür hat es eine Statusseite, eine deklarative DSL und einen Footprint, der auf einem Raspberry Pi läuft.

Eine kombinierte Aufstellung ist in vielen Projekten die richtige Antwort: Zabbix oder Prometheus erfassen die Infrastruktur-Metriken, Grafana visualisiert, Gatus beantwortet aus Außensicht die einfache Frage „läuft es?" und betreibt die öffentliche Statusseite. Die drei Werkzeuge schneiden sich nur an der schmalen Stelle „HTTP-Health-Check" — und dort gewinnt das, was schneller produktiv ist und für die Statusseite mitkommt.

Wann Gatus passt — und wann nicht

Gatus ist kein Universal­werkzeug — und genau das macht es brauchbar. Die folgenden Kriterien helfen, die Methode in einem konkreten Projekt einzuordnen.

Passend, wenn …

• ein konkreter Satz von Endpoints — eigene APIs, Drittanbieter-Services, TLS-Zertifikate, DNS-Einträge — aus Anwendersicht überwacht werden soll, ohne dass ein Agent auf jedem System installiert werden kann;
• eine öffentliche oder interne Statusseite gewünscht ist, ohne externen SaaS-Anbieter und ohne ein eigenes Frontend zu bauen;
• die Konfiguration als Code im Repository leben soll — GitOps, Pull-Request-Reviews, CI-Validierung;
• ein kleiner, regulierter Stack gesucht wird, der sich self-hosted betreiben lässt, ohne Daten an Drittanbieter zu schicken;
• die Time-to-Value wichtiger ist als die maximale Feature-Tiefe: in einer Stunde ein laufendes System, in einer Woche ein konsolidiertes Setup.

Weniger geeignet, wenn …

• Sie tiefe Host-Telemetrie brauchen — CPU-Profile, RAM-Trends, Disk-Capacity-Planung, Network-Flows. Hier ist Zabbix oder Prometheus die richtige Antwort.
• Sie Metriken über die Zeit korrelieren wollen, mit Dashboards, Drill-Downs und SLO-Berechnungen. Das ist Grafanas Domäne.
• Sie eine multiregionale Sicht brauchen — Gatus probt aus einem Netzwerkstandort. Für „Wie sieht meine API aus Tokio, Frankfurt und São Paulo aus?" braucht es mehrere Instanzen plus Aggregation oder ein dafür gebautes SaaS-Produkt.
• sehr große Setups mit mehreren tausend Endpoints in kurzen Intervallen geplant sind — die Skalierungs-Grenze ist nicht hart dokumentiert, aber jenseits weniger hundert Endpoints lohnt sich die Lastmessung.

In den meisten regulierten Branchen, mit denen wir arbeiten — kommunale Bürgerportale, Versicherungs-APIs, Bank-Schnittstellen — passt Gatus genau in die Lücke, die zwischen Zabbix und Grafana bleibt: die Außensicht auf die Services, die Anwender tatsächlich erleben. Im zweiten Teil dieser Reihe beleuchten wir denselben Bereich mit Zabbix und Grafana — als die schwergewichtige Alternative für tiefere Infrastruktur-Sicht und für Setups, in denen das Probing nur einen Teil der Story ausmacht.