Nadzor končnih točk

Kaj je "endpoint"?

Endpoint je vse, kar je naslovljivo na internetu in ga je mogoče povprašati, da se preveri razpoložljivost. Klasični primer je URL spletne strani — a v sodobni infrastrukturi so stvari, za katere skrbiš, veliko bolj raznolike: REST API-ji, GrafQL endpointi, poštni strežniki, poslušalci podatkovnih baz, vrste sporočil, health-check porti kontejnerjev, notranje admin panele, prejemniki webhookov. DiagnoSEO Uptime Monitoring jih obravnava enotno: definiraš, kaj pomeni "zdrav" za ta endpoint, nastaviš urnik preverjanja in prejmeš opozorilo ob izpadu.

Ta stran opisuje vsako vrsto endpointa, ki jo orodje podpira, za kaj je vsaka primerna in kakšen signal daje spremljanje.

HTTP / HTTPS endpointi (spletne strani)

Privzeti primer. Vneseš https://example.com in monitor izvaja zahtevo GET v določenem intervalu (1 minuta, 5, 10, 30 ali 60 minut, odvisno od paketa). Uspešna kontrola pomeni: vzpostavljena TCP povezava, TLS handshake zaključen (za HTTPS), prejeta HTTP-odgovor s pričakovano statusno kodo (privzeto: 2xx ali 3xx), in opcijsko prisotnost (ali odsotnost) ključne besede v telesu odgovora. Kontrola beleži Time To First Byte, skupni čas odgovora, velikost vsebine, verigo preusmeritev in celoten nabor odgovornih glavek.

HTTP endpointi so prava izbira za: marketinške strani, bloge, e-trgovine, SaaS nadzorne plošče, portale z dokumentacijo — povsod, kjer ljudje obiščejo v brskalniku.

API endpointi (REST / GraphQL / JSON-RPC)

API-ji potrebujejo več kot le "ali je odgovoril" — potrebujejo "ali je odgovoril pravilno". Konfiguriraš monitor s poljubno HTTP-metodo (GET, POST, PUT, DELETE, PATCH), poljubnimi glavekami (auth tokeni, content-type), bodyjem zahteve (JSON payload za POST/PUT) ter JSON asercijami na odgovoru (data.status mora biti enak "ok", result.count mora biti večji od 0, errors[] mora biti prazen). API, ki vrne HTTP 200 s pokvarjenim payloadom, je najslabša vrsta izpada — navidez zdrav za naiven monitor, a odpove vsaki stranki. JSON asercije to zaznajo.

Oglejte si poseben vodič za spremljanje API-jev za podrobnosti o nastavitvah in sintaksi asercij.

TCP port endpointi

Za ne-HTTP storitve: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), poslušalci podatkovnih baz (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), posebej določeni porti aplikacij. Monitor vzpostavi TCP povezavo do podanega host:port in poroča o uspehu, če je povezava sprejeta v oknu timeouta. Brez handshaka na ravni protokola — zgolj "ali demon posluša".

To je pravi monitor za vsako storitev, ki temelji na TCP in kjer ti je pomembna dosegljivost, ne pa preverjanje protokola. Za preverjanje SMTP bannerja ali testiranje na ravni poizvedb do baze uporabi heartbeat monitor (tvoja storitev nas pinga, ko je zdrava, glej cron-job / heartbeat monitoring).

Ping endpointi (ICMP)

Preverjanje dosegljivosti na 3. sloju. Monitor pošlje ICMP echo zahtevo na ciljni hostname ali IP in počaka na odgovor. Uporabno za usmerjevalnike, stikala, IoT naprave, vse, kar odgovarja na ping, a ne poganja HTTP-ja. Pomni, da veliko ponudnikov oblakov (AWS, GCP, Azure) privzeto blokira ICMP na ravni varnostnih skupin, četudi je gostitelj sicer zdrav — za cloud delovne naloge raje uporabi HTTP ali TCP port preverjanja.

Endpointi hostname / DNS

Spremljanje razreševanja DNS. Orodje občasno razrešuje A, AAAA, MX, NS, TXT in CNAME zapise tvoje domene, shrani rezultate in opozori, če se kateri koli spremeni. Zazna: nepooblaščene prevzeme DNS, naključne napake v nastavitvah med migracijo DNS ponudnika, zunanje storitve, ki posodabljajo svoje endpoint-e brez obvestila (tvoj CDN preklopi IP bloke, na primer), MX zapisi izbrisani zaradi tipkarske napake.

Spremljanje DNS ni za dosegljivost — tvoj DNS ponudnik je skoraj zagotovo bolj zanesljiv kot origin. Gre za zaznavo sprememb. Oglej si spremljanje sprememb DNS za celoten opis.

Endpointi SSL certifikatov

Vsak HTTPS endpoint dobi samodejno spremljanje SSL na vrhu svojega preverjanja uptime. Orodje prebere certifikat, razbere veljavnost in izdajatelja ter te opozori 30, 14, 7, 3 in 1 dan pred iztekom. Oglej si spremljanje SSL certifikatov za podrobnosti.

Endpointi izteka domene

Za vsak spremljan URL orodje prav tako izvaja WHOIS poizvedbo enkrat dnevno in spremlja datum izteka registracije domene. Opozorila se sprožijo na enakih pragovih kot za SSL (30/14/7/3/1 dni). Neplačane podaljšave so katastrofalne — domena ostane brez lastnika in nekdo jo lahko registrira, ko se konča grace perioda. Oglej si spremljanje izteka domene.

Izbira prave vrste endpointa

Če ne veš, katero vrsto monitorja uporabiti, začni s HTTP/HTTPS za vse z web vmesnikom, TCP portom za ostalo in dodaj heartbeat preverjanja za batch naloge, ki nimajo nobene omrežne površine. Lahko spremljaš isti cilj z več vrstami — na primer, TCP port preverjanje na 443 ujame "strežnik je aktiven, TLS handshake pa ni v redu", kar bi tudi HTTP preverjanje na istem URL označilo, medtem ko heartbeat iz tvojega lastnega notranjega monitoring agenta potrdi, da logika tvoje aplikacije dejansko deluje.

Najpogosteje zastavljena vprašanja

• Kaj je endpoint?

  Vse, kar je naslovljivo na internetu: HTTP/HTTPS URL-ji, REST API-ji, TCP porti (SMTP, MySQL, po meri), hosti za pinganje, DNS zapisi, SSL certifikati in podatki registracije domen. Nastavi en monitor za vsako vrsto endpointa.

• Naj uporabim HTTP ali TCP port preverjanje?

  HTTP je dobra privzeta izbira za vsako spletno storitev. TCP port je boljši za storitve, ki niso HTTP (podatkovne baze, poštni strežniki, lastni protokoli), kjer ti je pomembno le "ali demon sprejema povezave". Uporabi TCP za osnovno dosegljivost, HTTP za preverjanje "ali aplikacija dejansko pravilno odgovarja".

• V čem se heartbeat monitorji (cron-job) razlikujejo?

  Heartbeat je obrnjen — namesto da mi preverjamo tvojo storitev, tvoja storitev pinga nas na znani URL. Če pinga ne prejmemo v pričakovanem intervalu, opozorimo. Uporablja se za cron jobe, batch procese in vse, kar teče po urniku brez omrežne površine za preverjanje.

• Ali lahko en URL nadzira več monitorjev?

  Da. Lahko spremljaš isti cilj z različnimi vrstami preverjanj — npr. HTTP za popolno dosegljivost plus TCP port 443, ki zazna težave s TLS-handshakeom. Vsak monitor deluje neodvisno in opozarja neodvisno.

• Ali moram SSL in domeno spremljati ločeno?

  Ne — vsak HTTPS endpoint samodejno prejme spremljanje SSL poleg preverjanja razpoložljivosti, vsak spremljan URL pa dnevno spremljanje izteka domene. Oboje je vključeno, brez dodatnih nastavitev. Spremljanje domene je na domeno — več monitorjev na isti domeni si deli WHOIS podatke.