Endpoint-Überwachung

Was ist ein „Endpoint“?

Ein Endpoint ist alles, was im Internet adressierbar ist und abgefragt werden kann, um die Verfügbarkeit zu prüfen. Der klassische Fall ist die URL einer Webseite – aber in moderner Infrastruktur sind die Elemente, um die du dich kümmerst, viel vielfältiger: REST API, GraphQL-Endpoints, Mailserver, Datenbank-Listener, Message Queues, Health-Check-Ports von Containern, interne Admin-Panels, Webhook-Empfänger. DiagnoSEO Uptime Monitoring behandelt sie einheitlich: Du definierst, was „gesund“ für diesen Endpoint bedeutet, stellst den Check-Zeitplan ein und erhältst bei Ausfall einen Alarm.

Diese Seite beschreibt jeden Typ von Endpoint, den das Tool unterstützt, wofür jeder geeignet ist und welche Signale das Monitoring liefert.

HTTP/HTTPS-Endpoints (Webseiten)

Der Standardfall. Du gibst https://example.com ein und der Monitor führt in definierten Intervallen (1, 5, 10, 30 oder 60 Minuten je nach Plan) einen GET-Request aus. Ein erfolgreicher Check bedeutet: TCP-Verbindung hergestellt, TLS-Handshake abgeschlossen (für HTTPS), HTTP-Antwort mit erwartetem Statuscode empfangen (standardmäßig: 2xx oder 3xx) und optional ist ein Keyword im Antwort-Body vorhanden (oder nicht vorhanden). Der Check erfasst Time To First Byte, gesamte Antwortdauer, Inhaltsgröße, Weiterleitungsketten und den vollständigen Satz der Antwort-Header.

HTTP-Endpoints sind die richtige Wahl für: Marketingseiten, Blogs, E-Commerce-Shops, SaaS-Dashboards, Dokumentationsportale – überall, wo Nutzer mit dem Browser zugreifen.

API-Endpoints (REST / GraphQL / JSON-RPC)

APIs brauchen mehr als „hat geantwortet“ – sie benötigen „hat korrekt geantwortet“. Du konfigurierst den Monitor mit individueller HTTP-Methode (GET, POST, PUT, DELETE, PATCH), individuellen Headern (Auth-Tokens, Content-Type), Request-Body (JSON-Payload für POST/PUT) sowie JSON-Asserts auf die Antwort (data.status muss gleich "ok" sein, result.count muss größer als 0 sein, errors[] muss leer sein). Eine API, die HTTP 200 mit beschädigtem Payload zurückliefert, ist der schlimmste Ausfall – sie sieht für einen naiven Monitor gesund aus, enttäuscht aber jeden Client. JSON-Asserts erkennen genau das.

Siehe den dedizierten Leitfaden für API-Monitoring für Konfigurationsdetails und Syntax der Asserts.

TCP-Port-Endpoints

Für Nicht-HTTP-Dienste: SMTP (Port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), Datenbank-Listener (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), individuelle Applikationsports. Der Monitor öffnet eine TCP-Verbindung zu host:port und meldet Erfolg, wenn die Verbindung innerhalb des Timeout akzeptiert wird. Kein Protokoll-Handshake – einfach „hört der Dienst?“

Das ist der richtige Monitor für jeden TCP-basierten Service, bei dem du auf Verfügbarkeit Wert legst und keinen protokollbewussten Check brauchst. Für SMTP-Bannerprüfung oder Checks auf Datenbankabfrage-Ebene nutze das Heartbeat-Monitoring (dein Dienst pingt uns, wenn er gesund ist, siehe Cron-Job / Heartbeat Monitoring).

Ping-Endpoints (ICMP)

Verfügbarkeits-Check auf Layer 3. Der Monitor sendet ein ICMP-Echo-Request an den Ziel-Hostname oder die IP und wartet auf eine Antwort. Nützlich für Router, Switches, IoT-Geräte – alles, was auf Ping reagiert, aber kein HTTP bereitstellt. Bedenke, dass viele Cloud-Anbieter (AWS, GCP, Azure) standardmäßig ICMP auf Security-Group-Ebene blockieren, auch wenn der Host gesund ist – für Cloud-Workloads verwende bevorzugt HTTP-Checks oder TCP-Ports.

Hostname / DNS-Endpoints

DNS-Resolution-Monitoring. Das Tool löst regelmäßig die A-, AAAA-, MX-, NS-, TXT- und CNAME-Records deiner Domain auf, macht einen Snapshot der Ergebnisse und benachrichtigt dich, wenn sich etwas ändert. Erkennt: unautorisierte DNS-Übernahmen, versehentliche Konfigurationsfehler beim Provider-Wechsel, externe Dienste, die ihre Endpoints ohne Hinweis aktualisieren (z. B. CDN wechselt IP-Blöcke), MX-Records, die durch Tippfehler gelöscht werden.

DNS-Monitoring prüft nicht die Verfügbarkeit – dein DNS-Provider ist quasi immer zuverlässiger als das Origin. Es dient dem Erkennen von Änderungen. Siehe DNS-Änderungsmonitoring für die vollständige Beschreibung.

SSL-Zertifikat-Endpoints

Jeder HTTPS-Endpoint erhält ein automatisches SSL-Monitoring zusätzlich zu seinem Uptime-Check. Das Tool liest das Zertifikat aus, analysiert Gültigkeitsdauer und Aussteller und warnt 30, 14, 7, 3 und 1 Tag vor Ablauf. Siehe SSL-Zertifikats-Monitoring für Details.

Domainablauf-Endpoints

Für jede überwachte URL fragt das Tool auch einmal täglich WHOIS ab und verfolgt das Domainablaufdatum. Warnungen werden zu den gleichen Zeitpunkten wie bei SSL ausgelöst (30/14/7/3/1 Tage). Nicht bezahlte Verlängerungen sind katastrophal – die Domain ist dann herrenlos und kann im Moment der Grace-Periode-Überschreitung von jemand anderem registriert werden. Siehe Domainablauf-Monitoring.

Die richtige Endpoint-Art wählen

Wenn du dir unsicher bist, mit welchem Monitor du starten sollst, beginne mit HTTP/HTTPS für alles mit Web-Interface, wähle TCP-Port für den Rest und ergänze Heartbeat-Checks für Batch-Jobs, die keine Netzwerkoberfläche anbieten. Du kannst für dasselbe Ziel mehrere Typen überwachen – z.B. überprüft ein TCP-Port-Check auf 443, ob der „Server erreichbar ist, aber TLS-Handshake defekt“, was der HTTP-Check auf der gleichen URL ebenfalls erkennen würde, während der Heartbeat deines eigenen Monitoring-Agents bestätigt, dass die Logik deiner Anwendung tatsächlich funktioniert.

Häufig gestellte Fragen

• Was ist ein Endpoint?

  Alles, was im Internet adressierbar ist: HTTP/HTTPS-URLs, REST-APIs, TCP-Ports (SMTP, MySQL, eigene), Hostnamen zum Anpingen, DNS-Records, SSL-Zertifikate und Domain-Einträge. Konfiguriere einen Monitor pro Endpunkttyp.

• Soll ich einen HTTP-Check oder einen TCP-Port wählen?

  HTTP ist eine gute Standardwahl für jeden Web-Service. Der TCP-Port ist besser für Nicht-HTTP-Dienste (Datenbanken, Mailserver, eigene Protokolle), wenn du nur wissen möchtest, ob der Dienst Verbindungen akzeptiert. Nutze TCP für Low-Level-Verfügbarkeit, HTTP für „antwortet die Anwendung tatsächlich korrekt“.

• Worin unterscheiden sich Heartbeat-Monitore (Cron-Job)?

  Heartbeat funktioniert umgekehrt – statt dass wir deinen Dienst abfragen, pingt dein Dienst uns an eine bekannte URL. Erhalten wir innerhalb des erwarteten Zeitfensters keinen Ping, alarmieren wir. Genutzt für Cronjobs, Batch-Prozesse und alles, das nach Zeitplan läuft, aber keine Netzwerkoberfläche zur Prüfung bietet.

• Kann eine URL mehrere Monitore haben?

  Ja. Du kannst dasselbe Ziel mit verschiedenen Check-Arten überwachen – z. B. HTTP-Check für volle Erreichbarkeit plus TCP-Port-Check 443, der TLS-Handshake-Probleme erkennt. Jeder Monitor arbeitet und alarmiert unabhängig.

• Muss ich SSL und Domain getrennt überwachen?

  Nein – jeder HTTPS-Endpoint erhält automatisch SSL-Monitoring zusätzlich zu seinem Uptime-Check und jede überwachte URL wird täglich auf Domainablauf geprüft. Beides inklusive, ohne zusätzliche Konfiguration. Domainmonitoring erfolgt pro Domain – mehrere Monitore auf derselben Domain teilen sich die WHOIS-Daten.