HTTP vs. TCP vs. Ping Monitoring: Welches Protokoll sollten Sie nutzen?

Beim Einrichten von Uptime Monitoring steht früh die Frage, welches Protokoll Sie für Ihre Checks nutzen. HTTP, TCP und Ping (ICMP) testen unterschiedliche Schichten Ihrer Infrastruktur — die richtige Wahl bestimmt, welche Probleme Sie erkennen.

Die Schichten verstehen

Ihr Anwendungsstack hat mehrere Schichten; jedes Monitoring-Protokoll testet eine andere Tiefe:

```
┌─────────────────────────┐
│ Anwendung (HTTP) │ ← HTTP-Monitoring testet hier
├─────────────────────────┤
│ Dienst (TCP-Ports) │ ← TCP-Monitoring testet hier
├─────────────────────────┤
│ Netzwerk (ICMP) │ ← Ping-Monitoring testet hier
├─────────────────────────┤
│ Physisch / Cloud │
└─────────────────────────┘
```

Eine Schicht kann ausfallen, während darunter liegende gesund bleiben. Ihr Server kann per Ping erreichbar sein (Netz ok), während der Webserver-Prozess abgestürzt ist (HTTP schlägt fehl, TCP auf Port 80 ebenfalls). Das hilft, das passende Protokoll pro Dienst zu wählen.

HTTP-/HTTPS-Monitoring

Funktionsweise

Ein HTTP-Monitor sendet eine vollständige HTTP-Anfrage (meist GET) an eine URL und wertet die Antwort aus. Geprüft wird:

• Verbindung: TCP-Verbindung und TLS-Handshake erfolgreich?
• Statuscode: Erwarteter Status (200, 301, …)?
• Antwort-Body: Enthält (oder enthält nicht) bestimmte Inhalte?
• Antwortzeit: Wie lange dauerte der gesamte Request/Response-Zyklus?
• SSL-Zertifikat: Gültig und nicht bald ablaufend?

Wann HTTP-Monitoring

Websites und Web-Apps: Jede per Browser erreichbare URL — die Standardwahl für die meisten Fälle.

REST-APIs: Health-Checks (/health, /api/status), um zu prüfen, ob die API korrekt antwortet.

Webhooks: Prüfen, dass Webhook-Endpunkte Anfragen annehmen.

Content-Verifizierung: Nicht nur laden, sondern richtigen Inhalt prüfen. Ein Server kann 200 OK mit Fehlerseite liefern — HTTP-Keyword-Monitoring fängt das.

Vorteile

• Testet den vollen Anwendungsstack inkl. Anwendungscode
• Kann Antwortinhalte verifizieren, nicht nur Erreichbarkeit
• Überwacht SSL-Gültigkeit und Ablauf
• Misst realistische Nutzer-Antwortzeiten
• Unterstützt Authentifizierung (Header, Cookies)

Grenzen

• Nur für HTTP/HTTPS-Dienste
• Höherer Overhead pro Check als TCP oder Ping
• Kein Monitoring nicht-web-Dienste (Datenbanken, Mail, Gameserver)

Beispiele

| Ziel | URL | Erwartung |
|------|-----|-----------|
| Startseite | https://example.com | Status 200 |
| API-Health | https://api.example.com/health | Status 200, Body enthält „ok“ |
| Login | https://app.example.com/login | Status 200 |
| Webhook | https://hooks.example.com/ingest | Status 200 oder 405 |

TCP-Monitoring

Funktionsweise

Ein TCP-Monitor versucht, eine Verbindung zu IP und Port zu öffnen. Geprüft wird:

• Port offen: Lässt sich eine TCP-Verbindung aufbauen?
• Verbindungszeit: Wie schnell nimmt der Port die Verbindung an?
• Port-Antwort: Reagiert der Dienst innerhalb des Timeouts?

TCP-Monitoring sendet keine Anwendungsdaten — es testet nur, ob der Port lauscht und Verbindungen annimmt.

Wann TCP-Monitoring

Datenbanken: PostgreSQL (5432), MySQL (3306), MongoDB (27017), Redis (6379).

Mailserver: SMTP (25/587), IMAP (143/993), POP3 (110/995).

Eigene Dienste: Alles mit TCP-Port ohne HTTP — Gameserver, MQTT, FTP, SSH.

Load Balancer: Port offen und Verbindungen werden angenommen.

Vorteile

• Funktioniert für jeden TCP-Dienst, nicht nur HTTP
• Geringerer Overhead als HTTP-Checks
• Keine Anwendungskonfiguration nötig
• Erkennt Port-Probleme (Dienst abgestürzt, Firewall falsch)

Grenzen

• Nur „Port offen“, nicht ob die Anwendung sinnvoll antwortet
• Keine Inhaltsprüfung
• Keine Anwendungslogik (Datenbank kann Verbindungen annehmen und trotzdem alle Queries verwerfen)

Beispiele

| Ziel | Host:Port | Zweck |
|------|-----------|-------|
| PostgreSQL | db.internal:5432 | Datenbank-Verfügbarkeit |
| Redis | cache.internal:6379 | Cache-Verfügbarkeit |
| SSH | bastion.example.com:22 | Jump-Server |
| SMTP | mail.example.com:587 | E-Mail-Versand |
| Custom API | service.internal:8080 | Microservice-Health |

Ping-(ICMP-)Monitoring

Funktionsweise

Ping sendet ICMP Echo Request an einen Host und wartet auf Echo Reply. Geprüft wird:

• Host erreichbar: Antwortet der Host auf Netzwerkebene?
• Round-Trip-Zeit: Wie lange dauert Hin- und Rückweg?
• Paketverlust: Werden Pakete verworfen?

Wann Ping-Monitoring

Netz-Infrastruktur: Router, Switches, Firewalls ohne Anwendungsdienste.

Server-Erreichbarkeit: Schnell prüfen, ob ein Server an und im Netz ist.

Netz-Performance: Ping-Zeiten und Paketverluste zeigen die Qualität des Pfads zwischen Monitoring und Ziel.

Ergänzung zu HTTP/TCP: Hilft zwischen „Server komplett weg“ und „Server da, Anwendung kaputt“ zu unterscheiden.

Vorteile

• Geringster Overhead
• Testet die grundlegendste Konnektivität
• Nützlich für Geräte ohne Anwendungsdienste
• Hilft bei der Einordnung: Netz vs. Anwendung

Grenzen

• Nur Netz-Erreichbarkeit — keine Anwendungsgesundheit
• Manche Hosts/Firewalls blockieren ICMP — Ping unzuverlässig
• In Cloud-Umgebungen oft kein ICMP zu bestimmten Ressourcen
• Kein Nachweis, dass ein bestimmter Dienst läuft

Beispiele

| Ziel | Host | Zweck |
|------|------|-------|
| VPN-Gateway | vpn.example.com | Netz-Zugang |
| Router | 10.0.0.1 | Netz-Infrastruktur |
| Server | web-1.internal | Basis-Erreichbarkeit |
| ISP-Hop | isp-gateway.net | Pfad-Gesundheit |

Das richtige Protokoll wählen

Ist es Website, Web-App oder REST-API?
→ HTTP-Monitoring. Vollständiger Stack, die nützlichsten Daten.

Lauscht ein Dienst auf einem TCP-Port ohne HTTP?
→ TCP-Monitoring. Datenbanken, Mail, Games, eigene Dienste.

Netzgerät oder nur Basis-Erreichbarkeit?
→ Ping-Monitoring. Router, Switches, VPN, grober Server-Check.

Unsicher?
→ HTTP für alles mit URL, TCP für alles mit Port, Ping für Infrastruktur.

Kombination für volle Abdeckung

Die besten Strategien nutzen mehrere Protokolle für verschiedene Ausfallbilder. Typischer Web-Stack:

| Komponente | Protokoll | Check |
|------------|-----------|-------|
| Website | HTTP | https://example.com → 200 |
| API | HTTP | https://api.example.com/health → 200 |
| Datenbank | TCP | db.internal:5432 |
| Redis | TCP | cache.internal:6379 |
| Server | Ping | web-1.internal |

Wenn HTTP fehlschlägt, TCP und Ping aber ok sind, liegt das Problem in der Anwendung. Wenn alles fehlschlägt, ist es Server- oder Netzproblem. Diese Schichtung beschleunigt die Diagnose.

Fazit

Es gibt kein einziges „bestes“ Monitoring-Protokoll — jedes testet eine andere Schicht. HTTP ist für Webdienste am umfassendsten, TCP für Nicht-HTTP-Dienste, Ping für Netz-Sichtbarkeit.

Für die meisten Teams gilt: alle drei, auf die passenden Ziele angewendet. Mit HTTP für nutzerseitige Dienste starten, TCP für Infrastruktur-Dienste ergänzen, Ping für Netz-Health.

Jede Schicht Ihres Stacks monitoren. Kostenlos starten — HTTP-, TCP- und Ping-Monitoring in jedem Plan.