Overvåking av endepunkt

Hva er et "endpoint"?

Et endpoint er alt som har en adresse på internett og kan forespørres for å sjekke tilgjengelighet. Typisk eksempel er en nettside-URL — men i moderne infrastruktur er ressursene du følger opp mye mer varierte: REST API-er, GraphQL-endepunkt, e-postservere, database-listere, meldingskøer, porter for container health-checks, interne adminpaneler, mottakere av webhooks. DiagnoSEO Uptime Monitoring behandler dem likt: du definerer hva som betyr "frisk" for denne endepunkttypen, setter opp en sjekkskjema, og får varsel ved feil.

Denne siden beskriver hver type endpoint som verktøyet støtter, hva det egner seg til, og hva slags signal du får ut av overvåkingen.

HTTP / HTTPS-endepunkt (nettsider)

Standardtilfellet. Du oppgir https://example.com og overvåkningsverktøyet foretar en GET-forespørsel med gitt intervall (1 minutt, 5, 10, 30 eller 60 minutter avhengig av abonnement). En vellykket sjekk betyr: TCP-tilkobling ble opprettet, TLS-håndtrykket ble fullført (for HTTPS), HTTP-svar med forventet statuskode ble mottatt (standard: 2xx eller 3xx), og valgfritt at et nøkkelord er til stede (eller ikke) i svarbodyen. Sjekken registrerer Time To First Byte, total svartid, innholdsstørrelse, omdirigeringskjede og fullt sett av respons-headere.

HTTP-endepunkt er riktig valg for: markedsføringssider, blogger, nettbutikker, SaaS-dashboarder, dokumentasjonsportaler — alle steder der folk besøker via nettleser.

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

API-er trenger mer enn "svarte den" — de trenger "svarte den riktig". Du konfigurerer overvåkningen med en tilpasset HTTP-metode (GET, POST, PUT, DELETE, PATCH), tilpassede headere (auth tokens, content-type), request-body (JSON-payload for POST/PUT) samt JSON-assertsjoner på responsen (data.status må være lik "ok", result.count må være større enn 0, errors[] må være tom). Et API som returnerer HTTP 200 med ødelagt payload er det verste feilsystemet — det ser friskt ut for en naiv monitor, men svikter alle klienter. JSON-assertsjoner fanger dette opp.

Se dedikert API-overvåkningsveiledning for detaljer om oppsett og assertsjonssyntaks.

TCP-portendepunkt

For ikke-HTTP-tjenester: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), database-listere (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), tilpassede applikasjonsporter. Monitoren åpner en TCP-tilkobling til angitt host:port og rapporterer suksess hvis tilkoblingen ble akseptert innenfor timeout-vinduet. Ingen protokollhandshake — bare "lytter tjenesten".

Dette er riktig type for enhver TCP-basert tjeneste der du bryr deg om tilgjengelighet, men ikke trenger protokollbevisst sjekk. For å verifisere SMTP-banner eller gjøre forespørsler mot en database, bruk heartbeat-overvåkning (din tjeneste sender ping til oss når den er frisk, se cron-jobb / heartbeat-overvåkning).

Ping-endepunkt (ICMP)

Tilgjengelighetssjekk på lag 3. Overvåkeren sender ICMP echo-request til mål-hostnavn eller IP og venter på svar. Nyttig for rutere, svitsjer, IoT-enheter, alt som svarer på ping men kjører ikke HTTP. Husk at mange skyleverandører (AWS, GCP, Azure) blokkerer ICMP som standard på security-gruppen, selv om verten ellers er frisk — for sky workloads, foretrekk HTTP- eller TCP-port-sjekker.

Hostname- / DNS-endepunkt

DNS-oppløsningsovervåkning. Verktøyet oppløser jevnlig A-, AAAA-, MX-, NS-, TXT- og CNAME-poster for domenet ditt, tar et snapshoot av resultatene og sender varsel ved endring. Fanger opp: uautoriserte DNS-overtakelser, feil under migrering hos DNS-provider, eksterne tjenester som oppdaterer endepunkt uten varsel (f.eks. CDN bytter IP-blokker), slettede MX-poster pga. skrivefeil.

DNS-overvåkning handler ikke om tilgjengelighet — din DNS-leverandør er trolig mer stabil enn origin. Det handler om å oppdage endringer. Se DNS-endringsovervåkning for full beskrivelse.

SSL-sertifikatendepunkt

Hvert HTTPS-endepunkt får automatisk SSL-overvåkning på toppen av sin uptime-sjekk. Verktøyet leser sertifikatet, parserer gyldighetsperiode og utsteder, og varsler 30, 14, 7, 3 og 1 dag før utløp. Se SSL-sertifikatovervåkning for detaljer.

Domenefornyelses-endepunkt

For hver overvåket URL forespør også verktøyet WHOIS én gang daglig og følger med på domenets utløpsdato. Varsler sendes på samme terskler som for SSL (30/14/7/3/1 dager). Manglende fornyelse kan være katastrofalt — domenet blir eierløst og noen andre kan registrere det i ende av behovsperioden. Se overvåkning av domeneutløp.

Velge riktig type endpoint

Hvis du er usikker på hvilken type overvåking du skal bruke, start med HTTP/HTTPS for alt med webgrensesnitt, TCP-port for resten, og legg til heartbeat-sjekker for batch-jobber som ikke eksponerer noen nettverksflate. Du kan overvåke samme mål med flere typer — for eksempel vil en TCP-port-sjekk på 443 fange opp "serveren er oppe, men TLS-håndtrykket feiler", som HTTP-sjekk på samme URL også vil flagge, mens heartbeat fra din egen interne monitor-agent bekrefter at applikasjonslogikken faktisk fungerer.

Ofte stilte spørsmål

• Hva er et endpoint?

  Alt som kan adresseres på internett: HTTP/HTTPS-URL-er, REST API, TCP-porter (SMTP, MySQL, tilpassede), hostnavn for ping, DNS-poster, SSL-sertifikater og domeneregistreringer. Opprett én monitor per endepunkt-type.

• Bør jeg bruke HTTP-sjekk eller TCP-port?

  HTTP er et godt standardvalg for all webtjenester. TCP-port er bedre for ikke-HTTP-tjenester (databaser, e-postservere, tilpassede protokoller) hvor du kun bryr deg om "lytter demon på tilkoblinger". Bruk TCP for lavnivå tilgjengelighet, HTTP for "svarer applikasjonen faktisk riktig".

• Hva er forskjellen på heartbeat-monitorer (cron-jobb)?

  Heartbeat er motsatt — i stedet for at vi spør tjenesten din, er det tjenesten din som sender ping til oss på en kjent URL. Hvis vi ikke mottar ping innen forventet tidsvindu, sender vi varsel. Brukes for cron-jobber, batch-prosesser og alt som kjøres etter tidsskjema uten nettverksflate å sjekke opp mot.

• Kan én URL ha flere overvåkere?

  Ja. Du kan overvåke samme mål med ulike typer sjekker — f.eks. HTTP-sjekk for full tilgjengelighet pluss TCP-port 443-sjekk som fanger problemer med TLS-håndtrykk. Hver monitor fungerer og varsler uavhengig.

• Må jeg overvåke SSL og domene separat?

  Nei — hvert HTTPS-endepunkt får automatisk SSL-overvåkning i tillegg til uptime-sjekk, og hver overvåket URL får daglig oppfølging av domenets utløp. Begge inngår, ingen ekstra oppsett. Domenet overvåkes per domene — flere monitorer på samme domene deler WHOIS-data.