Ping-Überwachung

Wozu Ping, wenn ich bereits HTTP überwache?

HTTP-Monitoring zeigt, ob die Website eine korrekte Antwort zurückgibt. Ping-Monitoring zeigt, ob die Maschine überhaupt erreichbar ist. Das sind unterschiedliche Fragen, und der Unterschied zählt, wenn etwas ausfällt. Wenn die Webanwendung abstürzt, aber der Server noch lebt, fällt HTTP aus – Ping funktioniert weiter. Das grenzt die Diagnose sofort ein. Wenn beides ausfällt – Netzwerk- oder Infrastrukturproblem. Wenn nur Ping ausfällt – vielleicht blockiert eine Firewall plötzlich die Prüfungen, aber HTTP funktioniert für die Nutzer weiterhin.

Ping-Monitoring ist auch das richtige Werkzeug für Hosts, auf denen kein HTTP läuft: Datenbankserver, Mailserver, App-Server hinter dem Load-Balancer, VPN-Gateways, interne Services – überall dort, wo du einfach nur wissen musst, "lebt die Kiste und ist sie erreichbar?".

Warum TCP-basierter Ping?

Das klassische ICMP-Ping (der „ping“-Befehl) ist auf dem Desktop großartig, aber für Cloud-Monitoring nicht zuverlässig. Die meisten modernen Firewalls blockieren oder limitieren ICMP, besonders aus öffentlichen Netzwerken – daher kann bei ICMP-Timeout sowohl „Server ausgefallen“ als auch „Firewall hat das Paket verschluckt“ bedeuten. Solche Uneindeutigkeiten sind eine Katastrophe für ein Alerting-Tool.

DiagnoSEO Uptime Monitoring verwendet TCP-basierten Ping: Der Check öffnet eine TCP-Verbindung auf einen bekannten Port (zuerst 80, Fallback 443) mit 5-Sekunden-Timeout. Kommt ein SYN/ACK zurück – Host ist erreichbar. Wenn nicht – bekommst du einen echten Fehlerstatus direkt aus dem Kernel (Verbindung abgelehnt, Timeout, kein Routing zum Host), was das Triage beschleunigt.

Was wird gespeichert?

Jeder Ping speichert das Ergebnis (up/down) und die RTT-Zeit in Millisekunden. Das landet in der gleichen Historie wie die HTTP-Monitore – du bekommst ein Sparkline der letzten Checks, Uptime-Prozente für 24h und 30d sowie eine Heatmap der Erreichbarkeit für die letzten 30 Tage. Wenn der Host ausfällt, wird ein Incident geöffnet und Benachrichtigungen werden über die aktivierten Kanäle gesendet.

Tipps für Ping-Monitore

• Wähle ein kurzes Intervall: Ping ist günstig, stelle 1–5 Minuten ein, wenn es dein Plan erlaubt. Schnellere Erkennung mit geringeren Kosten.
• Kombiniere mit Port-Monitoren: Wenn du z. B. eine Datenbank auf 5432 oder Mail auf 25 betreibst, füge auch einen Port-Monitor hinzu. Ping sagt „die Kiste lebt“, Port sagt „der Dienst lauscht“.
• Behalte die RTT im Auge: Die Antwortzeit wird bei jedem Check gespeichert. Plötzliche RTT-Spikes gehen häufig größeren Ausfällen voraus – konfiguriere einen Schwellwert, um sie zu entdecken, bevor sie zu Incidents werden.
• Nutze Schwellenwert für Bestätigung: Netzwerke zucken manchmal. Die Standardeinstellung von 2 aufeinanderfolgenden Fehlversuchen schützt vor Fehlalarmen.

Wie fügt es sich ins Dashboard ein?

Ping-Monitore erscheinen neben HTTP-, Port-, Keyword-, API- und Heartbeat-Monitoren in derselben Liste. Du kannst sie taggen ("infra", "intern"), nach Status filtern, nach RTT sortieren und wie alle anderen pausieren/fortsetzen. Alarme laufen über die gleichen Kanäle (E-Mail, Telegram, Slack, Discord, SMS) mit den gleichen Nachtruhe-Regeln und Schwellenwertbestätigungen.

Konfiguration

Öffne das Tool, klicke auf „Monitor hinzufügen“, wähle den Typ „Ping (TCP)“, füge den Host ein (z. B. db.internal.firma.com), lege das Intervall fest und speichere. Ab dem nächsten Zyklus öffnet der Monitor jede Minute eine TCP-Verbindung, speichert die RTT und benachrichtigt, wenn der Host nicht mehr antwortet.

Häufig gestellte Fragen

• Wofür wird Ping-Monitoring eingesetzt?

  Prüft die Erreichbarkeit auf Layer 3 — ob der Host auf ICMP Echo antwortet. Nützlich für Router, Switches, IoT-Geräte, interne Infrastruktur und alles, was nicht auf HTTP läuft, aber trotzdem erreichbar sein muss.

• Warum besteht mein AWS/Cloud-Server den Ping-Check nicht?

  Die meisten Cloud-Provider blockieren ICMP standardmäßig auf der Ebene der Security-Groups oder Firewalls. Der Server ist ansonsten gesund, antwortet aber nicht auf Ping. Für Cloud-Workloads bevorzuge HTTP- oder TCP-Port-Checks. Du kannst ICMP explizit in Security-Groups erlauben, wenn du wirklich Ping brauchst.

• Was ist der Unterschied zwischen Ping und einem TCP-Port-Check?

  Ping nutzt ICMP (ohne Port – reine Layer-3-Erreichbarkeit). TCP-Port öffnet eine Verbindung zu einem bestimmten Port – bestätigt Layer-4-Konnektivität. Ein Host kann beim Ping durchkommen und bei TCP versagen (Firewall blockiert den Port) oder umgekehrt (ICMP blockiert, Port offen).

• Messt ihr die Round-Trip-Zeit des Pings?

  Ja – die Antwortzeit (Round-Trip) wird bei jedem Check protokolliert und über die Zeit verfolgt. Nützlich, um Netzwerkdegradierungen zu erkennen: Derselbe Host, dessen RTT langsam von 20ms auf 200ms steigt, weist auf Routing- oder Überlastprobleme hin.

• Kann ich interne IPs anpingen?

  Nur, wenn die IP von unseren Checker-Servern aus erreichbar ist – also eine öffentliche IP. Private RFC1918-Ranges (192.168.x.x, 10.x.x.x, 172.16-31.x.x) funktionieren nicht mit externem Monitoring. Für interne Infrastruktur installiere einen Self-Hosted Heartbeat-Agenten im internen Netz, der uns anpingt.