Övervakning av slutpunkter

Vad är en "endpoint"?

En endpoint är allt som är adresserbart på internet och kan frågas för att verifiera tillgänglighet. Det klassiska fallet är en webbsida-URL — men i modern infrastruktur är det du ansvarar för mycket mer varierat: REST API:er, GraphQL-endpoints, e-postservrar, databaslyssnare, meddelandeköer, containers hälsokontroll-portar, interna adminpaneler, webhook-mottagare. DiagnoSEO Uptime Monitoring behandlar dem enhetligt: du definierar vad "frisk" betyder för din endpoint, ställer in kontrollschemat och får varningar vid fel.

Den här sidan beskriver varje typ av endpoint som verktyget stöder, vad varje är bäst lämpad för och vilken signal du får av övervakningen.

HTTP/HTTPS-endpoints (webbsidor)

Standardfallet. Du skriver in https://example.com och monitorn gör en GET-förfrågan med givet intervall (1 min, 5, 10, 30 eller 60 minuter beroende på plan). Ett lyckat test betyder: en TCP-anslutning upprättades, TLS-handshake (för HTTPS) slutförd, HTTP-svar mottaget med förväntad statuskod (standard: 2xx eller 3xx), samt valfritt att nyckelordet finns (eller saknas) i svaret. Testet registrerar Time To First Byte, total svarstid, innehållsstorlek, redirect-kedja och hela uppsättningen svarshuvuden.

HTTP-endpoints är rätt val för: marknadssajter, bloggar, e-handelsbutiker, SaaS-dashboards, dokumentationsportaler — överallt där människor besöker via webbläsare.

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

API:er kräver något mer än "svarar den" — de behöver "svarar den korrekt". Du konfigurerar montern med egen HTTP-metod (GET, POST, PUT, DELETE, PATCH), egna huvuden (auth-token, content-type), request body (JSON-payload för POST/PUT) samt JSON-asserter på svar (data.status ska vara "ok", result.count ska vara större än 0, errors[] ska vara tom). Ett API som returnerar HTTP 200 men trasig payload är den värsta sortens fel — det ser friskt ut för en naiv monitor men misslyckas för alla klienter. JSON-assertioner fångar detta.

Se dedikerad guide för API-övervakning för detaljer om konfiguration och assert-syntax.

TCP-portendpoints

För tjänster som inte är HTTP: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), databaslyssnare (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), egna applikationsportar. Monitorn öppnar en TCP-anslutning mot host:port och rapporterar lyckat om anslutningen accepteras innan timeout. Ingen handshake på protokollnivå — helt enkelt "lyssnar daemonen".

Detta är rätt monitor för varje TCP-baserad tjänst där du behöver tillgänglighet men inte protokollsmedvetna tester. För banner-koll på SMTP eller queries i databas, använd heartbeat-monitor (din tjänst pingar oss när den är frisk — se cron-jobb/heartbeat-övervakning).

Ping-endpoints (ICMP)

Kontroll av tillgänglighet på lager 3. Monitorn skickar en ICMP echo-förfrågan till målets värdnamn eller IP och väntar på svar. Användbart för routrar, switchar, IoT, allt som svarar på ping men inte kör HTTP. Observera att många molnleverantörer (AWS, GCP, Azure) som standard blockerar ICMP i security-groups även om hosten egentligen är frisk — för moln-workloads är HTTP- eller TCP-porttester att föredra.

Hostname-/DNS-endpoints

Övervakning av DNS-resolution. Verktyget utför periodiskt uppslag mot A, AAAA, MX, NS, TXT och CNAME-poster för din domän, tar en snapshot av resultaten och varnar om någon ändras. Upptäcker: otillåten DNS-övertagning, oavsiktliga konfigurationsfel vid DNS-providerbyte, externa tjänster som uppdaterar sina endpoints utan att meddela (exempelvis CDN som byter IP-block), MX-poster som raderas på grund av stavfel.

DNS-övervakning handlar inte om tillgänglighet — din DNS-provider är nästan säkert mer pålitlig än ursprunget. Det handlar om att upptäcka ändring. Se DNS-ändringsövervakning för komplett beskrivning.

SSL-certifikatendpoints

Varje HTTPS-endpoint får automatisk SSL-övervakning utöver sin uptime-check. Verktyget läser certifikatet, tolkar giltighetstid och utfärdare, och varnar 30, 14, 7, 3 och 1 dag innan utgång. Se SSL-certifikatövervakning för detaljer.

Utgång av domänendpoints

För varje övervakad URL gör verktyget även en WHOIS-koll dagligen och följer domänregistreringens utgångsdatum. Varningströsklar är samma som för SSL (30/14/7/3/1 dagar). Missade förnyelser är katastrofala — domänen blir ägarelös och någon kan registrera den så fort grace-perioden löper ut. Se övervakning av domänutgång.

Välja rätt endpoint-typ

Om du inte vet vilken typ av monitor du ska använda, börja med HTTP/HTTPS för allt med webgränssnitt, TCP-port för resten och lägg till heartbeat-test för batchjobb som inte exponerar någon nätverksyta. Du kan övervaka samma mål med flera typer — till exempel en TCP-port 443-check upptäcker "servern är uppe men TLS-handshake trasig" vilket HTTP-checken på samma URL också skulle signalera, medan en heartbeat från din interna agent bekräftar att applikationslogiken faktiskt fungerar.

Vanliga frågor och svar

• Vad är en endpoint?

  Allt adresserbart på internet: HTTP/HTTPS-URL:er, REST API:er, TCP-portar (SMTP, MySQL, egna), värdnamn att pinga, DNS-poster, SSL-certifikat och domänregistreringar. Konfigurera en monitor per endpoint-typ.

• Ska jag använda HTTP-check eller TCP-port?

  HTTP är ett bra standardval för alla webbtjänster. TCP-port är bättre för icke-HTTP-tjänster (databaser, e-postservrar, egna protokoll) där du bara bryr dig om "tar daemonen emot anslutningar". Använd TCP för low-level tillgänglighet, HTTP för "svarar applikationen faktiskt korrekt".

• Hur skiljer sig heartbeat-monitorer (cron-jobb)?

  Heartbeat är omvänt — istället för att vi frågar din tjänst så pingar din tjänst oss på en känd URL. Om vi inte får en ping inom förväntat fönster, larmar vi. Används för cron-jobb, batch-processer och allt som körs enligt schema utan egen nätverksyta att kolla.

• Kan en URL ha flera monitorer?

  Ja. Du kan övervaka samma mål med olika typer av tester — t.ex. HTTP-check för full tillgänglighet plus TCP-port 443-check som fångar problem med TLS-handshake. Varje monitor jobbar och larmar oberoende.

• Måste jag övervaka SSL och domän separat?

  Nej — varje HTTPS-endpoint får automatiskt SSL-övervakning utöver sin uptime-check, och varje övervakad URL övervakas dagligen för domänutgång. Båda ingår utan extra konfiguration. Domänövervakning sker per domän — flera monitorer för samma domän delar WHOIS-data.