Lõpp-punktide jälgimine

Mis on "endpoint"?

Endpoint on kõik, mis on internetis adresseeritav ja mida saab pärida, et kontrollida selle kättesaadavust. Klassikaline näide on veebilehe URL — kuid tänapäevases infrastruktuuris on sinu hallatavad objektid oluliselt mitmekesisemad: REST API, GraphQL endpointid, meiliserverid, andmebaasi kuulajad, sõnumijärjekorrad, konteinerite health-check pordid, sisemised adminpaneelid, webhooki vastuvõtjad. DiagnoSEO Uptime Monitoring käsitleb neid ühtlaselt: määratled, mida "terve" antud endpointi puhul tähendab, seadistad kontrollimissageduse ja saad häire teate katkestuse korral.

See leht kirjeldab iga endpointi tüüpi, mida tööriist toetab, milleks iga tüüp sobib ja millist signaali jälgimine annab.

HTTP / HTTPS endpointid (veebilehed)

Vaikimisi juhtum. Sisestad https://example.com ning monitor teeb määratud intervalliga (1 minut, 5, 10, 30 või 60 minutit, sõltuvalt paketist) GET-päringu. Õnnestunud kontroll tähendab: TCP-ühendus on loodud, TLS-handshake lõpetatud (HTTPS puhul), HTTP-vastus tuli oodatud staatusekoodiga (vaikimisi: 2xx või 3xx), ning vajadusel peab vastuse sisus olema määratud märksõna (või selle puudumine). Kontroll salvestab Time To First Byte, kogu vastuse aja, sisu suuruse, ümbersuunamiste ahela ja kõik vastuse päised.

HTTP endpointid sobivad: turunduslehtede, blogide, e-kaubanduse poodide, SaaS-dashboardide, dokumentatsiooni portaalide jaoks — kõikjal, kus inimesed külastavad brauseriga.

API endpointid (REST / GraphQL / JSON-RPC)

API vajab rohkemat kui ainult "kas vastas" — vajalik on "kas vastas korrektselt". Seadistad monitooringu kohandatud HTTP-meetodiga (GET, POST, PUT, DELETE, PATCH), kohandatud päistega (autentimistekid, content-type), päringu sisuga (JSON payload POST/PUT puhul) ja JSON-väidete kontrolliga vastuses (data.status peab võrduma "ok", result.count peab olema suurem kui 0, errors[] peab olema tühi). API, mis tagastab HTTP 200, kuid katkise payloadiga, on probleemne rike — näeb terve välja lihtsalt monitoori jaoks, kuid ebaõnnestub kõikide klientide jaoks. JSON-väited tuvastavad selle.

Vaata pühendatud API monitoorimise juhendit konfigureerimisvõimaluste ja väidete süntaksi kohta.

TCP-pordi endpointid

Teenustele, mis ei ole HTTP-põhised: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), andmebaasi kuulajad (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), kohandatud rakenduse pordid. Monitor avab TCP-ühenduse etteantud host:port ja annab poolt edu, kui ühendus aktsepteeritakse timeout’i aknas. Protokollitasemel handshake'i ei toimu — lihtsalt "kas deemon kuulab".

See on sobilik monitor kõigile TCP-ga seotud teenustele, kus hoolid kättesaadavusest, kuid ei vaja protokolliteadlikke kontrolle. SMTP bannersõnumi kontrolliks või andmebaasi päringu tasandil kontrolliks kasuta heartbeat-monitoorimist (sinu teenus pingib meid, kui see on terve, vaata cron-job / heartbeat monitoring).

Ping-endpointid (ICMP)

Kättesaadavuse kontrolli 3. võrgu kihil. Monitor saadab ICMP echo-päringu sihthostname'ile või IP-le ja ootab vastust. Kasulik ruuterite, switch’ide, IoT-seadmete või muu jaoks, mis vastab pingile, kuid ei jooksuta HTTP-d. Pea meeles, et paljud pilveteenuse pakkujad (AWS, GCP, Azure) blokeerivad vaikimisi ICMP-liikluse turvagruplis, isegi kui host ise töötab — pilvekoormuste puhul eelistada HTTP- või TCP-pordi kontrolli.

Hostname / DNS endpointid

DNS lahendamise monitooring. Tööriist lahendab perioodiliselt sinu domeeni A-, AAAA-, MX-, NS-, TXT- ja CNAME-kirjed, teeb nende tulemusest hetkepildi ning hoiatab, kui mõni muutub. Tuuastab ära: volitamata DNS-i hõivamised, juhuslikud seadistusvead DNS teenusepakkujat vahetades, väliste teenuste endpointide muutused ilma ette teatamata (nt sinu CDN vahetab IP-blokke), MX-kirjed kustutatakse kirjavea tõttu.

DNS-i monitoorimine ei tähenda kättesaadavuse kontrolli — sinu DNS-teenusepakkuja on peaaegu kindlasti töökindlam kui serveri päritolu. Siin on eesmärgiks muudatuste avastamine. Vaata DNS-i muudatuste monitoorimist täpsemaks kirjeldamiseks.

SSL-sertifikaatide endpointid

Iga HTTPS-endpoint saab automaatse SSL-monitooringu oma uptiem-checki peale. Tööriist loeb sertifikaadi, parsib kehtivusaja ja väljastaja ning annab hoiatuse 30, 14, 7, 3 ja 1 päeva enne aegumist. Vaata SSL-sertifikaadi monitooringut täpsemalt.

Domeeni aegumise endpointid

Iga monitooritava URL-i puhul pärib tööriist WHOIS-st kord päevas ja jälgib domeeni registreeringu kehtivusaega. Hoiatused tulevad samadel päevadel nagu SSL-i puhul (30/14/7/3/1 päeva). Pikendamata jäetud domeenid võivad olla katastroofilised — domeen jääb omaniku järelvalveta ja keegi võib selle kohe registreerida pärast grace periodi lõppu. Vaata domeeni aegumise monitooringut.

Õige endpoint-tüübi valik

Kui sa pole kindel, millist monitooritüüpi kasutada, alusta HTTP/HTTPS-ga kõige jaoks, millel on veebiliides, TCP-pordiga muu jaoks ning lisa heartbeat-kontrollid batch-tööde jaoks, mis ei jaga ühtegi võrgu pinda. Sa võid sama sihtmärki monitorida mitut tüüpi kontrollidega — näiteks TCP-port 443 kontroll püüab kinni "server on töös, kuid TLS handshake katki" olukorrad, mille HTTP-check samal URL-il samuti tuvastaks, samas kui sinu sisemine heartbeat-agent kinnitab, et sinu rakenduse loogika töötab päriselt.

Korduma kippuvad küsimused

• Mis on endpoint?

  Kõik, mis on internetis adresseeritav: HTTP/HTTPS URL-id, REST API-d, TCP-pordid (SMTP, MySQL, kohandatud), hostnimed pingimiseks, DNS-kirjed, SSL-sertifikaadid ja domeeni registreeringud. Sea üks monitor igale endpointi tüübile.

• Kas kasutada HTTP-checki või TCP-porti?

  HTTP on hea vaikimisi valik iga veebiteenuse jaoks. TCP-port sobib paremini mitte-HTTP teenustele (andmebaasid, meiliserverid, kohandatud protokollid), kus hoolid ainult sellest, kas deemon võtab ühendusi vastu. Kasuta TCP-d madala taseme kättesaadavuse jaoks, HTTP-d selleks, et näha, kas rakendus vastab korrektselt.

• Kuidas erinevad heartbeat monitorid (cron-job)?

  Heartbeat töötab vastupidiselt — selle asemel, et meie pärime sinu teenust, pingib sinu teenus meid teadaolevale URL-ile. Kui me ei saa määratud aja jooksul ping’i, saadame häire. Kasutatakse cron-job’ide, batch-protsesside ja kõige jaoks, mis töötab ajakava põhjal ja pole võrgu kaudu kontrollitav.

• Kas üks URL võib olla mitme monitori all?

  Jah. Sa võid sama sihtmärki jälgida erinevate kontrollitüüpidega — nt HTTP-check täieliku kättesaadavuse jaoks pluss TCP-port 443 check, mis püüab kinni TLS handshake’i probleemid. Iga monitor töötab iseseisvalt ja teavitab sõltumatult.

• Kas ma pean SSL-i ja domeeni eraldi jälgima?

  Ei — iga HTTPS endpoint saab automaatselt SSL-i monitooringu oma uptime checki juurde ning iga monitoritud URL saab igapäevase domeeni aegumise jälgimise. Mõlemad kuuluvad komplekti, lisaseadistust pole vaja. Domeeni monitooring on domeenipõhine — mitu monitori samal domeenil kasutavad samu WHOIS-andmeid.