Ping-Monitoring sendet in regelmäßigen Abständen kleine Prüfpakete an einen Host und erfasst, ob er antwortet, wie lange der Hin- und Rückweg dauert und wie viele Pakete verloren gehen. Es zeigt, ob eine Maschine im Netzwerk erreichbar ist – nicht, ob die darauf laufende Anwendung funktioniert. Setzen Sie Ping für Geräte und Dienste ohne Web-Endpunkt ein und HTTP-Checks überall dort, wo es um eine Seite oder eine API-Antwort geht.
So funktioniert Ping-Monitoring
Ein klassischer Ping ist ein ICMP Echo Request, der mit einem Echo Reply beantwortet wird. Das Monitoring erfasst:
- Round-Trip-Time (RTT): die Latenz von der Anfrage bis zur Antwort, meist als Durchschnitt und p95.
- Paketverlust: der Anteil der Pakete, die nie zurückkommen. Anhaltender Verlust von mehr als etwa 1–2 % auf einer kabelgebundenen Strecke sollte in der Regel untersucht werden.
- Jitter: die Schwankung der RTT zwischen einzelnen Messungen, relevant für VoIP und Echtzeitverkehr.
Viele Netzwerke blockieren ICMP oder begrenzen es. Ein TCP-Ping, der den Verbindungsaufbau zu einem offenen Port wie 22 oder 443 misst, liefert dann ein verlässliches Erreichbarkeitssignal, während UDP-Prüfungen Dienste wie DNS auf Port 53 abdecken. Die technischen Details erklärt der Beitrag Wie Ping-Monitoring funktioniert.
Ping vs. HTTP-Checks: Layer 3 vs. Layer 7
Der entscheidende Unterschied liegt darin, wo eine Prüfung endet: Ping auf der Netzwerkschicht, HTTP auf der Anwendungsschicht.
| Frage | Ping (ICMP/TCP/UDP) | HTTP-Check |
|---|---|---|
| Ist der Host erreichbar? | Ja | Indirekt |
| Verschlechtert sich die Route (Latenz, Verlust)? | Ja | Teilweise |
| Liefert der Webserver 200 zurück? | Nein | Ja |
| Ist der Inhalt der Antwort korrekt? | Nein | Ja, mit Keyword- oder JSON-Assertions |
| Funktioniert es bei Geräten ohne Webserver? | Ja | Nein |
Ein Server kann einwandfrei auf Ping antworten, während Nginx 502-Fehler liefert oder die Anwendung in einer Crash-Schleife hängt. Ein erfolgreicher Ping beweist nie, dass eine Website verfügbar ist.
Wann Ping die richtige Wahl ist
Ping eignet sich besser als primäre Prüfung, wenn das Ziel keine HTTP-Schnittstelle hat oder der Netzwerkpfad selbst im Mittelpunkt steht:
- Router, Switches und Firewalls. Sie bieten oft nur SSH oder SNMP. Ping bestätigt, dass sie laufen, und macht steigende Latenz auf Uplinks sichtbar.
- VPN-Gateways und Site-to-Site-Tunnel. Ein Ping auf einen Host hinter dem Tunnel zeigt, ob tatsächlich Verkehr durchgeht – nicht nur, ob das Gateway eingeschaltet ist.
- Datenbank- und Cache-Hosts. PostgreSQL-, MySQL- oder Redis-Hosts sollten kein HTTP ausliefern. Ein TCP-Ping auf den Dienst-Port ist hier das aussagekräftige Signal.
- IoT- und Edge-Geräte. Kameras, Sensoren und Kassensysteme haben oft nur eine IP-Adresse und einen ICMP-Responder.
- Mail-, Game- und andere Nicht-HTTP-Server. SMTP, eigene TCP-Dienste und UDP-Gameserver lassen sich gut mit TCP- oder UDP-Prüfungen überwachen.
Üblich sind Intervalle von 30–60 Sekunden, mit Alarmierung nach zwei oder drei aufeinanderfolgenden Fehlschlägen, um kurzzeitige Aussetzer herauszufiltern.
Wann Sie HTTP-Checks brauchen
Alles, was Kunden über einen Browser oder eine Client-Bibliothek erreichen, braucht HTTP-Monitoring: Websites, Login- und Checkout-Prozesse, REST- und GraphQL-APIs. HTTP-Checks validieren Statuscodes, Antwortzeit, Weiterleitungen und Inhalte und erkennen so Fehler oberhalb der Netzwerkschicht, etwa fehlerhafte Deployments, Datenbankfehler, die als 500er auftauchen, oder falsch konfigurierte CDNs. Wenn Ihr SLA erfolgreiche Requests zählt, kann Ping allein ihn nicht messen.
Warum die Kombination die Fehleranalyse beschleunigt
Laufen beide Prüfungen gegen denselben Dienst, wird aus einem „Seite down“-Alarm eine Diagnose:
- Ping schlägt fehl, HTTP schlägt fehl: wahrscheinlich ein Netzwerk-, Host- oder Providerproblem.
- Ping erfolgreich, HTTP schlägt fehl: Der Host ist erreichbar – prüfen Sie Webserver, Anwendung, TLS oder vorgelagerte Abhängigkeiten.
- Beide erfolgreich, Latenz steigt: Vergleichen Sie RTT und HTTP-Antwortzeit, um Netzwerküberlastung von langsamem Code zu unterscheiden.
Mehrere Regionen liefern eine zusätzliche Dimension: Verliert nur ein Standort den Ping, liegt eher ein regionales Routing-Problem vor als ein Fehler auf Ihrem Server. UpScanX führt ICMP-, TCP- und UDP-Prüfungen neben HTTP/HTTPS-Checks von mehr als 15 globalen Standorten aus, sodass beide Signale auf einer gemeinsamen Zeitachse liegen. Die KI-Berichte korrelieren zusammenhängende Alarme und liefern Hinweise auf die Ursache. Benachrichtigungen gehen per E-Mail, Slack, Telegram, Microsoft Teams oder Webhook raus.
Das Wichtigste in Kürze
- Ping misst Erreichbarkeit, RTT, Paketverlust und Jitter auf der Netzwerkschicht; über den Zustand der Anwendung sagt es nichts aus.
- Setzen Sie Ping – oder TCP- und UDP-Prüfungen, wo ICMP gefiltert wird – für Router, Firewalls, VPN-Gateways, Datenbank-Hosts, IoT-Geräte und Nicht-HTTP-Server ein.
- Nutzen Sie HTTP-Checks für alles, worauf Nutzer oder API-Clients angewiesen sind.
- Kombinieren Sie beide bei kritischen Diensten, damit schon das Alarmmuster zeigt, welche Schicht ausgefallen ist.
Um Prüfungen auf Netzwerkebene neben Ihren Uptime-Monitoren einzurichten, starten Sie mit dem Ping-Monitoring von UpScanX.