Monitoring-Typen erklärt: HTTP, TCP, Heartbeat, Manual & AMC

Monitoring ist nicht gleich Monitoring. Ein HTTP-Check der alle 60 Sekunden eine URL aufruft, reicht für eine Marketing-Website. Aber was ist mit der Datenbank hinter deiner API? Dem Cron Job der nachts Rechnungen verschickt? Dem TCP-Service auf Port 5432?

Jeder Check-Typ löst ein anderes Problem. Wer den falschen wählt, überwacht entweder das Falsche — oder bekommt Alerts die keine echten Ausfälle sind.

Dieser Artikel erklärt die fünf Check-Typen, die ein modernes Monitoring abdecken sollte: HTTP(S), TCP, Heartbeat, Manual und AMC. Für jeden Typ: was er prüft, wann du ihn brauchst und wie du ihn konfigurierst.

HTTP(S) Check — Websites und APIs überwachen

Was er prüft

Ein HTTP(S)-Check sendet eine Anfrage an eine URL und prüft die Antwort. Das klingt simpel, aber die Konfigurationsmöglichkeiten machen den Unterschied zwischen nützlichem und nutzlosem Monitoring.

Ein guter HTTP-Check prüft nicht nur, ob eine URL erreichbar ist. Er prüft:

• Status Code: Antwortet der Server mit 200 OK — oder mit 500, 502, 403?
• Keywords: Enthält die Antwort einen bestimmten Text? Das ist entscheidend, weil ein Server 200 OK zurückgeben kann, obwohl die Seite eine Fehlermeldung anzeigt.
• SSL-Validierung: Ist das Zertifikat gültig? Läuft es bald ab?
• Response Time: Wie lange dauert die Antwort? Ein Server der 15 Sekunden braucht, ist technisch erreichbar — aber für Nutzer praktisch unbenutzbar.

Wann du ihn brauchst

HTTP-Checks sind der Standard für alles mit einer URL: Websites, APIs, Webhooks, Login-Seiten, Dashboards. Wenn ein Endnutzer es über einen Browser oder eine API-Anfrage erreicht, gehört ein HTTP-Check drauf.

Konfiguration in der Praxis

Ein typischer HTTP-Check sieht so aus:

Tipp: Prüfe nicht die Startseite. Prüfe einen Health-Endpoint der tatsächlich bestätigt, dass die Anwendung funktioniert — inklusive Datenbankverbindung und kritischer Abhängigkeiten. Eine statische HTML-Seite kann erreichbar sein, während die Anwendung dahinter längst abgestürzt ist.

Erweiterte Optionen

• POST-Requests: Für APIs die nur auf POST reagieren. Nützlich für Webhook-Endpoints oder Formulare.
• Custom Headers: Für Authentifizierung, API-Keys oder spezifische Content-Type-Anforderungen.
• Basic Auth: Für geschützte Staging-Umgebungen oder interne Dashboards.

TCP Check — Netzwerkdienste überwachen

Was er prüft

Ein TCP-Check testet, ob ein bestimmter Port auf einem Server erreichbar ist und eine Verbindung akzeptiert. Kein HTTP, kein Protokoll-spezifischer Inhalt — nur: Ist der Port offen und kann eine Verbindung aufgebaut werden?

Wann du ihn brauchst

TCP-Checks sind das Mittel der Wahl für Dienste die kein HTTP sprechen:

• Datenbanken — PostgreSQL (5432), MySQL (3306), Redis (6379)
• Mail-Server — SMTP (25/587), IMAP (993), POP3 (995)
• Game-Server — Beliebige Ports
• SSH — Port 22
• Custom Services — Alles was auf einem definierten Port lauscht

Konfiguration in der Praxis

TCP-Checks sind bewusst einfach. Sie beantworten eine binäre Frage: Kann eine Verbindung hergestellt werden oder nicht? Für tiefergehende Prüfungen — etwa ob eine Datenbank tatsächlich Queries akzeptiert — brauchst du anwendungsspezifische Checks.

Tipp: Nutze TCP-Checks für Infrastruktur-Dienste die nicht über HTTP erreichbar sind. Für Datenbanken hinter einer API reicht oft ein HTTP-Check auf den Health-Endpoint der API — der implizit die Datenbankverbindung mitprüft.

Heartbeat Check — Passive Überwachung für Jobs und Prozesse

Was er prüft

Ein Heartbeat-Check — auch bekannt als Dead Man's Switch — dreht die Logik um: Statt dass das Monitoring-System den Service prüft, meldet sich der Service aktiv beim Monitoring. Wenn die Meldung ausbleibt, gibt es ein Problem.

Das Monitoring stellt eine URL bereit — einen Heartbeat-Endpoint. Dein Service ruft diese URL in einem definierten Intervall auf. Solange die Aufrufe kommen, ist alles in Ordnung. Bleibt ein Aufruf aus, wird nach einer konfigurierbaren Grace Period ein Alert ausgelöst.

Wann du ihn brauchst

Heartbeat-Checks lösen ein Problem, das HTTP- und TCP-Checks nicht abdecken: die Überwachung von Prozessen die nicht dauerhaft laufen.

• Cron Jobs — Nachtlauf für Rechnungen, Daten-Exporte, Cleanup-Tasks
• Backup-Prozesse — Tägliche Datenbank-Backups
• Queue Workers — Hintergrundprozesse die Jobs abarbeiten
• Batch-Prozesse — Datenimporte, Synchronisierungen
• Scheduled Tasks — Alles was regelmäßig laufen soll, aber nicht permanent aktiv ist

Konfiguration in der Praxis

Die Integration in bestehende Prozesse ist eine Zeile Code:

# Am Ende eines Cron Jobs
curl -fsS --retry 3 https://monitoring.beispiel.de/heartbeat/abc123

# In einem PHP Script
file_get_contents("https://monitoring.beispiel.de/heartbeat/abc123");

# In einem NodeJs Script
fetch("https://monitoring.beispiel.de/heartbeat/abc123").catch(()=>{});

Tipp: Setze die Grace Period nicht zu knapp. Wenn dein Cron Job normalerweise 10 Minuten läuft, aber bei Lastspitzen 25 Minuten braucht, sollte die Grace Period das abfangen. Lieber ein paar Minuten Puffer als unnötige Fehlalarme.

Manual Check — API-gesteuertes Monitoring

Was er prüft

Ein Manual Check hat kein automatisches Prüfintervall. Der Status wird ausschließlich über die API gesetzt — von deinem eigenen Code, deiner CI/CD-Pipeline oder einem externen System. Der Name ist dabei etwas irreführend: „Manual" bedeutet nicht, dass jemand per Klick einen Status setzt. Es bedeutet, dass die Steuerung extern passiert — programmatisch, über die REST API.

Wann du ihn brauchst

Manual Checks sind für Szenarien gedacht, die kein standardisiertes Monitoring abbilden kann:

• Externe Abhängigkeiten — Status eines Drittanbieter-Services den du nicht selbst prüfen kannst
• Manuelle Prozesse — Hardware-Checks, physische Infrastruktur
• Custom Logic — Eigene Monitoring-Skripte die komplexe Bedingungen prüfen und das Ergebnis per API melden
• CI/CD-Integration — Deployment-Status auf der Statuspage anzeigen

Konfiguration in der Praxis

# Status auf "down" setzen
curl -X PUT https://demo.livck.com/api/v2/monitoring/manual/123
\
  -H "Authorization: Bearer TOKEN" \
  -d '{"status": "UNAVAILABLE"}'

# Status auf "operational" zurücksetzen
curl -X PUT https://demo.livck.com/api/v2/monitoring/manual/123
\
  -H "Authorization: Bearer TOKEN" \
  -d '{"status": "AVAILABLE"}'

Manual Checks sind das flexibelste Werkzeug im Monitoring. Sie machen überall dort Sinn, wo die Standard-Check-Typen nicht passen — aber dafür brauchen sie eigene Logik die den Status pflegt.

Fehlalarme — das unterschätzte Problem

Bevor wir zum letzten Check-Typ kommen, ein Wort zu einem Problem das jedes Monitoring-Setup irgendwann trifft: Fehlalarme.

Ein Fehlalarm entsteht, wenn das Monitoring eine Störung meldet, die keine ist. Die Ursachen sind vielfältig:

• Netzwerk-Jitter — Ein einzelnes Paket geht verloren, der nächste Check ist wieder erfolgreich
• Kurze Lastspitzen — Der Server antwortet einmalig langsam, erholt sich aber sofort
• DNS-Propagation — Temporäre DNS-Auflösungsprobleme
• Wartung beim Hoster — Kurze Netzwerkunterbrechung ohne echten Ausfall
• Routing-Probleme — Das Problem liegt zwischen Monitoring-Server und Ziel, nicht beim Ziel selbst

Das Problem mit Fehlalarmen ist nicht der einzelne Alert. Das Problem ist die Gewöhnung. Wenn dein Team dreimal pro Woche um 3 Uhr nachts geweckt wird und jedes Mal ist es ein Fehlalarm, passiert etwas Gefährliches: Alerts werden ignoriert. Erst mental, dann aktiv — Benachrichtigungen werden stummgeschaltet, Eskalationen verzögert. Und wenn dann der echte Ausfall kommt, reagiert niemand rechtzeitig.

In der SRE-Community hat das einen Namen: Alert Fatigue. Und es ist einer der häufigsten Gründe warum Monitoring-Setups in der Praxis scheitern — nicht weil das Monitoring nicht funktioniert, sondern weil es zu oft falschen Alarm schlägt.

AMC (Advanced Monitor Check) — Multi-Step Re-Check gegen Fehlalarme

Das Konzept

AMC löst das Fehlalarm-Problem an der Wurzel: Statt bei einem einzelnen fehlgeschlagenen Check sofort einen Alarm auszulösen, führt AMC einen mehrstufigen, zeitversetzten Re-Check durch.

Die Logik:

1. Initialer Check schlägt fehl — Der reguläre Monitoring-Check erkennt eine potenzielle Störung
2. AMC übernimmt — Statt sofort zu alarmieren, startet ein zusätzlicher Prüfzyklus
3. Zeitversetzte Re-Checks — AMC führt weitere Prüfungen mit Verzögerung durch
4. Bestätigung oder Entwarnung — Nur wenn die Re-Checks die Störung bestätigen, wird ein Incident ausgelöst. War es ein temporäres Problem, bleibt der Status unverändert.

Warum das wichtig ist

Der entscheidende Unterschied: AMC prüft nicht einfach nochmal dasselbe. Durch die zeitliche Verzögerung zwischen den Re-Checks werden temporäre Störungen — Netzwerk-Jitter, kurze Lastspitzen, Routing-Probleme — zuverlässig herausgefiltert.

Ein einzelner fehlgeschlagener Check sagt wenig aus. Zwei oder drei fehlgeschlagene Checks über einen Zeitraum verteilt sind ein verlässliches Signal dass tatsächlich etwas nicht stimmt.

Was das in der Praxis bedeutet

Ohne AMC:

• Check schlägt fehl → Sofort Alert → Team wird geweckt → Service ist wieder online → Fehlalarm

Mit AMC:

• Check schlägt fehl → Re-Check nach Verzögerung → Service antwortet wieder → Kein Alert, kein Fehlalarm
• Check schlägt fehl → Re-Check nach Verzögerung → Service antwortet immer noch nicht → Bestätigter Ausfall → Alert

Das Ergebnis: Weniger Rauschen, mehr Signal. Dein Team wird nur alarmiert wenn es wirklich brennt.

Wie sich AMC von Standard-Retries unterscheidet

Die meisten Monitoring-Tools bieten einfache Retries — ein sofortiger zweiter Check. Das filtert Timeouts, aber nicht die häufigsten Ursachen für Fehlalarme: kurze Lastspitzen, Routing-Probleme oder Netzwerk-Jitter, die länger als eine Sekunde dauern.

AMC geht einen Schritt weiter. Der mehrstufige, zeitversetzte Ansatz gibt dem System gezielt Zeit, sich zu erholen, bevor eine Störung bestätigt wird. Das ist der Unterschied zwischen einem simplen Retry und einer echten Fehlalarm-Prävention — und der Grund warum AMC in der Praxis deutlich weniger Rauschen produziert als herkömmliche Retry-Mechanismen.

Welcher Check für welchen Use Case?

Best Practices

1. Prüfe was der Nutzer sieht

Überwache nicht interne Metriken die kein Nutzer wahrnimmt. Dein HTTP-Check sollte das prüfen, was ein echter Nutzer erleben würde: die Login-Seite, den API-Endpoint, den Checkout-Prozess. Wenn der Nutzer es nicht merkt, ist es kein Ausfall.

2. Kombiniere Check-Typen

Ein einzelner Check-Typ reicht selten. Eine typische Webanwendung braucht:

• HTTP-Check auf den Health-Endpoint (Anwendung + Datenbank)
• TCP-Check auf den Datenbank-Port (falls direkt erreichbar)
• Heartbeat-Check auf den Cron Job der E-Mails verschickt

3. Aktiviere AMC

Es gibt keinen guten Grund, AMC nicht zu aktivieren. Die minimale Verzögerung bei der Alarm-Auslösung wiegt die drastische Reduktion von Fehlalarmen bei weitem auf. Dein Team wird es dir danken.

4. Grace Periods und Timeouts sinnvoll setzen

Zu kurze Timeouts erzeugen Fehlalarme. Zu lange Timeouts verzögern die Erkennung. Als Faustregel:

• Timeout: 2-3x der normalen Response-Zeit
• Grace Period (Heartbeat): 1.5-2x der normalen Laufzeit des Jobs
• Intervall: Alle 60 Sekunden für kritische Services, alle 5 Minuten für unkritische

5. Unterscheide kritisch und unkritisch

Nicht jeder Service braucht 10-Sekunden-Intervalle und sofortige SMS-Benachrichtigung. Priorisiere: Welche Services sind kundensichtbar? Welche sind intern? Welche haben finanzielle Auswirkungen bei Ausfall?

Fazit

Monitoring-Typen sind kein akademisches Thema — sie bestimmen, ob dein Monitoring in der Praxis funktioniert oder ob es Rauschen produziert das alle ignorieren.

HTTP-Checks für alles mit einer URL. TCP-Checks für Infrastruktur-Dienste. Heartbeat-Checks für Prozesse die nicht dauerhaft laufen. Manual Checks für alles was keine Standardlösung abdeckt. Und AMC als Sicherheitsnetz gegen Fehlalarme, die jedes Monitoring-Setup ohne Gegenmaßnahme früher oder später unbrauchbar machen.

Die beste Monitoring-Konfiguration ist eine, die nur dann alarmiert wenn es wirklich brennt. AMC ist der Baustein der das möglich macht.

LIVCK vereint alle fünf Check-Typen in einer Plattform — zusammen mit Statuspage, Incident Management und Benachrichtigungen. Self-Hosted per Docker, als Managed Service oder bald als Cloud-Lösung.