Endpointbewaking

Wat is een "endpoint"?

Een endpoint is alles wat via internet adresseerbaar is en bevraagd kan worden om beschikbaarheid te verifiëren. Een klassiek voorbeeld is een website-URL — maar in moderne infrastructuur zijn de zaken waar je om geeft veel diverser: REST API, GraphQL-endpoints, mailservers, database-listeners, berichtenwachtrijen, health-check poorten van containers, interne adminpanels, webhook-ontvangers. DiagnoSEO Uptime Monitoring behandelt ze allemaal op dezelfde manier: je definieert wat "gezond" betekent voor dat endpoint, stelt een check-interval in, en ontvangt een alert bij een storing.

Deze pagina beschrijft elk type endpoint dat de tool ondersteunt, waar elk geschikt voor is en welk signaal het monitoren geeft.

HTTP / HTTPS endpoints (webpagina’s)

De standaardkeuze. Je vult https://example.com in en de monitor voert op het ingestelde interval een GET-request uit (1 minuut, 5, 10, 30 of 60 minuten afhankelijk van het abonnement). Een geslaagde check betekent: TCP-verbinding tot stand gebracht, TLS-handshake voltooid (voor HTTPS), HTTP-antwoord ontvangen met de verwachte statuscode (standaard: 2xx of 3xx), en optioneel aanwezigheid (of afwezigheid) van een keyword in de body van het antwoord. De check registreert Time To First Byte, totale reactietijd, contentgrootte, redirectketen en volledige set van responseheaders.

HTTP-endpoints zijn geschikt voor: marketingwebsites, blogs, e-commerce shops, SaaS-dashboards, documentatieportalen — overal waar mensen met een browser bezoeken.

API endpoints (REST / GraphQL / JSON-RPC)

API’s hebben meer nodig dan "is er antwoord" — ze hebben "is het antwoord correct" nodig. Je configureert de monitor met een aangepaste HTTP-methode (GET, POST, PUT, DELETE, PATCH), aangepaste headers (auth-tokens, content-type), request body (JSON-payload voor POST/PUT) en JSON-asserties op het antwoord (data.status moet gelijk zijn aan "ok", result.count moet groter zijn dan 0, errors[] moet leeg zijn). Een API die HTTP 200 retourneert met kapotte payload is het slechtste soort storing — lijkt gezond voor een simpele monitor maar faalt voor elke client. JSON-asserties pikken dit eruit.

Zie de speciale API monitoringsgids voor details over configuratie en assertiesyntax.

TCP-poorten endpoints

Voor niet-HTTP diensten: SMTP (poort 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), database-listeners (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), aangepaste applicatiepoorten. De monitor opent een TCP-verbinding naar het opgegeven host:port en rapporteert succes als de verbinding binnen de timeout geaccepteerd wordt. Zonder handshake op het protocolniveau — puur "luistert de daemon".

Dit is de juiste monitor voor elke TCP-dienst waar je alleen geïnteresseerd bent in de beschikbaarheid en geen protocol-bewuste check nodig hebt. Voor verificatie van SMTP-banners of query-checks op database-niveau, gebruik een heartbeat-monitor (jouw dienst ‘pingt’ ons wanneer hij gezond is, zie cron-job / heartbeat monitoring).

Ping endpoints (ICMP)

Beschikbaarheidscheck op laag 3. De monitor stuurt een ICMP echo-request naar de doel-hostname of IP en wacht op een antwoord. Handig voor routers, switches, IoT-apparaten, alles wat reageert op ping maar geen HTTP uitvoert. Houd er rekening mee dat veel cloudproviders (AWS, GCP, Azure) standaard ICMP blokkeren op security-group niveau, zelfs als de host verder gezond is — geef bij cloud-workloads de voorkeur aan HTTP- of TCP-poort-checks.

Hostname / DNS endpoints

DNS-resolutie monitoring. De tool lost periodiek je domein op via A-, AAAA-, MX-, NS-, TXT- en CNAME-records, maakt een snapshot van de resultaten en geeft een alert als er iets wijzigt. Detecteert: ongeautoriseerde DNS-overname, toevallige configfouten bij migratie van DNS-provider, externe diensten die zonder aankondiging hun endpoints aanpassen (bijvoorbeeld jouw CDN die IP-blokken wisselt), MX-records verwijderd door een typefout.

DNS-monitoring draait niet om beschikbaarheid — jouw DNS-provider is vrijwel zeker betrouwbaarder dan de origin. Hier draait het om het detecteren van wijzigingen. Zie DNS wijzigingsmonitoring voor een volledige uitleg.

SSL-certificaat endpoints

Elke HTTPS-endpoint krijgt automatische SSL-monitoring bovenop de uptime-check. De tool leest het certificaat uit, parseert de geldigheidsperiode en uitgever, en waarschuwt je 30, 14, 7, 3 en 1 dag voor het verlopen. Zie SSL-certificaatmonitoring voor details.

Domein-verloop endpoints

Voor elke gemonitorde URL bevraagt de tool dagelijks WHOIS en volgt de verloopdatum van de domeinregistratie. Waarschuwingen worden getriggerd op dezelfde intervallen als SSL (30/14/7/3/1 dagen). Gemiste verlengingen kunnen rampzalig zijn — het domein komt eigendomloos en iemand kan het direct na afloop van de grace-periode registreren. Zie domeinverloop-monitoring.

Het kiezen van het juiste type endpoint

Als je niet weet welk monitortype je moet gebruiken, begin dan met HTTP/HTTPS voor alles met een webinterface, TCP-poort voor de rest, en voeg heartbeat-checks toe voor batchtaken die geen eigen netwerkoppervlak hebben. Je kunt hetzelfde doel met meerdere types monitoren — bijvoorbeeld een TCP-poort check op 443 detecteert "server is up, maar TLS-handshake kapot" wat een HTTP-check op dezelfde URL ook zou signaleren, terwijl een heartbeat van jouw interne monitoring-agent extra bevestigt dat je applicatielogica echt werkt.

Veelgestelde vragen

• Wat is een endpoint?

  Alles wat via internet adresseerbaar is: HTTP/HTTPS URL’s, REST API’s, TCP-poorten (SMTP, MySQL, custom), hostnamen om te pingen, DNS-records, SSL-certificaten en domeinregistratie. Configureer één monitor per type endpoint.

• Moet ik HTTP-check of TCP-poort gebruiken?

  HTTP is een goede standaardkeuze voor iedere webdienst. TCP-poort is beter voor niet-HTTP diensten (databases, mailservers, custom protocols) waar je alleen wilt weten "accepteert de daemon verbindingen". Gebruik TCP voor low-level beschikbaarheid, HTTP voor "reageert de applicatie daadwerkelijk correct".

• Wat is het verschil met heartbeat-monitors (cron-job)?

  Heartbeat is omgekeerd – in plaats van dat wij jouw dienst bevragen, pingt jouw dienst ons op een bekend URL. Krijgen wij geen ping binnen het verwachte tijdsvenster, dan sturen wij een alert. Gebruikt voor cronjobs, batchprocessen en alles wat periodiek draait zonder netwerkoppervlak om te monitoren.

• Kan één URL meerdere monitors hebben?

  Ja. Je kunt hetzelfde doel op verschillende manieren controleren — bv. HTTP-check voor volledige beschikbaarheid plus een TCP-port check op 443 die TLS-handshake-problemen vangt. Elke monitor draait onafhankelijk en genereert afzonderlijk alerts.

• Moet ik SSL en domein apart monitoren?

  Nee — elke HTTPS-endpoint krijgt automatisch SSL-monitoring bovenop de uptime-check, en elke gemonitorde URL krijgt dagelijkse monitoring van domeinverloop. Beide inbegrepen, zonder extra configuratie. Domeinmonitoring is per domein — meerdere monitors op hetzelfde domein delen de WHOIS-data.