Endpoint-overvågning

Hvad er et "endpoint"?

Et endpoint er alt, der kan adresseres på internettet og forespørges for at kontrollere tilgængelighed. Et klassisk eksempel er en webside-URL — men i moderne infrastruktur er de ting, du passer på, meget mere varierede: REST API, GraphQL-endpoints, mailservere, database-listeners, beskedkøer, health-check-porte for containere, interne admin-paneler, webhook-modtagere. DiagnoSEO Uptime Monitoring behandler dem ensartet: du definerer, hvad "sund" betyder for dette endpoint, sætter en tjekplan og får advarsel ved nedbrud.

Denne side beskriver hver type endpoint, som værktøjet understøtter, hvad de hver især egner sig til, og hvilket signal overvågningen giver.

HTTP / HTTPS-endpoints (websider)

Standardtilfældet. Du indtaster https://example.com, og monitoret sender en GET-request med det angivne interval (1 minut, 5, 10, 30 eller 60 minutter afhængigt af din plan). Et vellykket check betyder: TCP-forbindelse etableret, TLS-handshake gennemført (for HTTPS), HTTP-svar modtaget med forventet statuskode (standard: 2xx eller 3xx) og valgfrit keyword til stede (eller fraværende) i svaret. Tjekket registrerer Time To First Byte, samlet svartid, indholdsstørrelse, redirect-kæde og fuldt sæt af svar-headere.

HTTP-endpoints er det rigtige valg til: marketingsider, blogs, e-commerce shops, SaaS dashboards, dokumentationsportaler — alle steder, hvor folk besøger via browser.

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

API'er kræver mere end bare "svarede den" — de har brug for "svarede den korrekt". Du konfigurerer monitor med brugerdefineret HTTP-metode (GET, POST, PUT, DELETE, PATCH), brugerdefinerede headers (auth-tokens, content-type), request-body (JSON-payload for POST/PUT) samt JSON-assertioner på svaret (data.status skal være lig med "ok", result.count skal være større end 0, errors[] skal være tom). En API, der returnerer HTTP 200 men med ødelagt payload, er den værste slags nedetid — det ser sundt ud for et naivt monitor men fejler for alle klienter. JSON-assertioner fanger dette.

Se den dedikerede guide til overvågning af API for detaljer omkring konfiguration og assertion-syntaks.

TCP-port-endpoints

Til ikke-HTTP-tjenester: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), database-listeners (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), brugerdefinerede applikationsporte. Monitor åbner en TCP-forbindelse til angivne host:port og rapporterer succes hvis forbindelsen blev accepteret inden for timeout-vinduet. Ingen protokol-handshake — blot "lytter dæmonen?".

Dette er det rigtige monitor for enhver TCP-baseret tjeneste hvor du kun har brug for tilgængelighed, og ikke protokolbevidste checks. For at validere SMTP-banner eller forespørgsler på database-niveau skal du bruge heartbeat-monitoren (din tjeneste pinger os, når den er sund — se cron-job / heartbeat monitoring).

Ping-endpoints (ICMP)

Tilgængelighedstjek på lag 3. Monitoren sender en ICMP echo-anmodning til mål-hostname eller IP og venter på svar. Nyttigt for routere, switche, IoT-enheder, alt der svarer på ping men ikke kører HTTP. Husk, at mange cloud-udbydere (AWS, GCP, Azure) som standard blokerer ICMP på security group-niveau, selv hvis værten ellers er sund — til cloud workloads foretrækkes HTTP-tjek eller TCP-porte.

Hostname- / DNS-endpoints

Overvågning af DNS-opslag. Værktøjet løser periodisk A-, AAAA-, MX-, NS-, TXT- og CNAME-records for dit domæne, tager et snapshot af resultaterne og advarer, hvis noget ændrer sig. Opdager: uautoriserede DNS-overtagelser, tilfældige konfigurationsfejl ved DNS-udbyttemigration, eksterne tjenester der opdaterer deres endpoints uden varsel (din CDN frakobler IP-blokke, eksempelvis), MX-records slettet ved en tastefejl.

DNS-overvågning handler ikke om tilgængelighed — din DNS-udbyder er næsten altid mere pålidelig end origin. Det handler om at opdage ændringer. Se overvågning af DNS-ændringer for fuld beskrivelse.

SSL-certifikat-endpoints

Hvert HTTPS-endpoint får automatisk SSL-overvågning sammen med sin oppetids-tjek. Værktøjet aflæser certifikatet, parser gyldighed og udsteder, og advarer 30, 14, 7, 3 og 1 dag før udløb. Se SSL-certifikatovervågning for detaljer.

Domain-udløbsendpoints

For hver overvåget URL forespørger værktøjet også WHOIS én gang om dagen og følger udløbsdatoen for domæneregistreringen. Advarsler udløses på de samme tidspunkter som SSL (30/14/7/3/1 dage). Manglende betaling ved fornyelse er katastrofalt — domænet bliver uden ejer, og nogen kan registrere det i slutningen af grace perioden. Se overvågning af domæneudløb.

Valg af rigtig endpoint-type

Hvis du er usikker på hvilken monitor-type du skal bruge, så start med HTTP/HTTPS for alt med web-interface, TCP-port for resten, og tilføj heartbeat-checks for batch-opgaver, der ikke har en netværksflade. Du kan overvåge det samme mål med flere typer — for eksempel vil et TCP-port-tjek på 443 fange “serveren er oppe, men TLS-handshake fejler”, som et HTTP-tjek på samme URL også ville flagge, mens et heartbeat fra din egen interne monitoring-agent bekræfter, at din applikationslogik faktisk fungerer.

Ofte stillede spørgsmål

• Hvad er et endpoint?

  Alt adresserbart på internettet: HTTP/HTTPS-URLs, REST API, TCP-porte (SMTP, MySQL, brugerdefinerede), hostnames til ping, DNS-records, SSL-certifikater og domæneregistreringsposter. Konfigurér én monitor pr. endpoint-type.

• Skal jeg bruge HTTP-tjek eller TCP-port?

  HTTP er et godt standardvalg for enhver webtjeneste. TCP-port er bedre til ikke-HTTP-tjenester (databaser, mailservere, brugerdefinerede protokoller), hvor du kun går op i om “dæmonen accepterer forbindelser”. Brug TCP for lavniveau-tilgængelighed, HTTP for “svarer applikationen faktisk korrekt”.

• Hvordan adskiller heartbeat-monitorer sig (cron-job)?

  Heartbeat er omvendt — i stedet for at vi forespørger din tjeneste, pinger din tjeneste os på en kendt URL. Hvis vi ikke modtager ping inden for det forventede vindue, advarer vi. Bruges til cron-jobs, batch-processer og alt, der kører på et skema uden netværksflade til overvågning.

• Kan én URL have flere monitorer?

  Ja. Du kan overvåge det samme mål med forskellige typer af checks — fx et HTTP-tjek for fuld tilgængelighed plus et TCP-port 443-tjek, der fanger TLS-handshake-problemer. Hver monitor fungerer uafhængigt og advarer separat.

• Skal jeg overvåge SSL og domæne separat?

  Nej — hvert HTTPS-endpoint får automatisk SSL-overvågning sammen med sin oppetids-tjek, og hver overvåget URL får daglig sporing af domæneudløb. Begge dele er inkluderet uden ekstra konfiguration. Domæneovervågning er per domæne — flere monitors på samme domæne deler WHOIS-data.