Galapunktu uzraudzība

Kas ir "endpoints"?

Endpoint ir viss, kas ir adresējams internetā un ko var pieprasīt, lai pārbaudītu pieejamību. Tipisks gadījums ir tīmekļa lapas URL — taču mūsdienu infrastruktūrā lietas, par kurām rūpējies, ir daudz daudzveidīgākas: REST API, GraphQL endpointi, pasta serveri, datubāzu klausītāji, ziņojumu rindas, konteineru health-check porti, iekšējie administrācijas paneļi, webhook saņēmēji. DiagnoSEO Uptime Monitoring visus tos uztver vienādi: definē, kas nozīmē "veselīgs" šim endpointam, iestati pārbaudes grafiku, saņem brīdinājumu par kļūmi.

Šī lapa apraksta katru endpointa tipu, ko rīks atbalsta, kam tas ir piemērots un kādu signālu dod monitorings.

HTTP / HTTPS endpointi (tīmekļa lapas)

Noklusējuma gadījums. Tu ievadi https://example.com un monitors veic GET pieprasījumu noteiktā intervālā (1 minūte, 5, 10, 30 vai 60 minūtes atkarībā no plāna). Veiksmīga pārbaude nozīmē: izveidots TCP savienojums, TLS handshake ir pabeigts (HTTPS gadījumā), saņemta HTTP atbilde ar gaidīto statusa kodu (noklusēti: 2xx vai 3xx), un papildu – izvēlēts atslēgvārds ir (vai nav) atbildes body. Pārbaude reģistrē Time To First Byte, kopējo atbildes laiku, satura izmēru, pārvirzīšanas ķēdi un pilnu atbilžu galviņu komplektu.

HTTP endpointi ir pareizā izvēle mārketinga lapām, blogiem, e-komercijas veikaliem, SaaS informācijas paneļiem, dokumentācijas portāliem — visur, kur cilvēki apmeklē ar pārlūkprogrammu.

API endpointi (REST / GraphQL / JSON-RPC)

API ir vajadzīgs kas vairāk par “vai atbildēja” — nepieciešams pārliecināties “vai atbildēja pareizi”. Tu konfigurē monitoru ar pielāgotu HTTP metodi (GET, POST, PUT, DELETE, PATCH), pielāgotām galvenēm (autentifikācijas tokeni, content-type), pieprasījuma body (JSON payload POST/PUT gadījumā) un JSON apgalvojumiem atbildē (data.status jābūt "ok", result.count jābūt lielākam par 0, errors[] jābūt tukšam). API, kas atgriež HTTP 200 ar bojātu payload, ir vissliktākais kļūmes veids — tas izskatās vesels naivam monitoringam, taču pieviļ katru klientu. JSON apgalvojumi to atklāj.

Skaties API monitoringa īpašo pamācību, lai uzzinātu par konfigurācijas detaļām un apgalvojumu sintaksi.

TCP portu endpointi

Ne-HTTP pakalpojumiem: SMTP (ports 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), datubāzu klausītāji (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), pielāgoti aplikāciju porti. Monitors atver TCP savienojumu ar norādīto host:port un ziņo par panākumiem, ja savienojums pieņemts noteiktā timeout logā. Bez protokola līmeņa handshake — vienkārši “vai dēmons klausās”.

Šis ir īstais monitorings katram TCP balstītam pakalpojumam, kur tev rūp pieejamība un nav vajadzīga protokola līmeņa pārbaude. SMTP banner verifikācijai vai datubāzes vaicājumu līmenī izmanto heartbeat monitoru (tavs pakalpojums pingo mūs, kad ir vesels, skaties cron-job / heartbeat monitoring).

Ping endpointi (ICMP)

Piekļuves pārbaude 3. slānī. Monitors sūta ICMP echo pieprasījumu mērķa resursdatoram vai IP un gaida atbildi. Noderīgi maršrutētājiem, slēdžiem, IoT ierīcēm, jebkam, kas atbild uz ping, bet nepiedāvā HTTP. Atceries, ka daudzi mākoņpakalpojumu sniedzēji (AWS, GCP, Azure) noklusēti bloķē ICMP savās drošības grupās, pat ja resursdators ir vesels — mākoņa darba slodzēm dod priekšroku HTTP vai TCP portu pārbaudēm.

Resursdatoru / DNS endpointi

DNS atrisināšanas monitorings. Rīks regulāri atrisina tavas domēna A, AAAA, MX, NS, TXT un CNAME ierakstus, izveido rezultātu momentuzņēmumu un brīdina, ja kāds mainās. Atklāj: nesankcionētu DNS pārņemšanu, nejaušas konfigurācijas kļūdas DNS sniedzēja migrācijas laikā, ārējos pakalpojumus, kas atjaunina savus endpointus bez paziņojuma (piemēram, tavs CDN nomaina IP blokus), MX ierakstus, kas izdzēsti drukas kļūdas dēļ.

DNS monitorings nav par pieejamību — tavs DNS sniedzējs gandrīz noteikti ir uzticamāks par originu. Te svarīgā ir izmaiņu atklāšana. Skaties DNS izmaiņu monitoringu pilnam aprakstam.

SSL sertifikātu endpointi

Katrā HTTPS endpointā automātiski tiek veikts SSL monitorings papildus uptime pārbaudei. Rīks nolasa sertifikātu, izanalizē derīguma termiņu un izdevēju, un brīdina 30, 14, 7, 3 un 1 dienu pirms termiņa beigām. Skaties SSL sertifikātu monitoringu sīkākai informācijai.

Domēna derīguma termiņa endpointi

Katrai monitoringā esošai URL rīks arī vaicā WHOIS reizi dienā un seko līdzi domēna reģistrācijas derīguma termiņam. Brīdinājumi tiek izsūtīti tajos pašos sliekšņos kā SSL (30/14/7/3/1 diena). Neapmaksāti atjauninājumi ir katastrofāli — domēns kļūst bez īpašnieka, un kāds to var piereģistrēt uzreiz pēc grace perioda beigām. Skaties domēna derīguma termiņa monitoringu.

Pareizā endpointa tipa izvēle

Ja nezini, kuru monitoringa tipu lietot, sāc ar HTTP/HTTPS visam ar tīmekļa saskarni, TCP portu pārbaudi pārējiem, un pievieno heartbeat pārbaudes batch uzdevumiem, kuriem nav tīkla virsmas. Vienu mērķi vari monitorēt ar vairākiem tipiem — piemēram, TCP ports 443 pārbaude atklās “serveris ir online, bet TLS handshake ir bojāts”, ko HTTP pārbaude uz tā paša URL arī atzīmētu, kamēr heartbeat no tava iekšējā monitoringa aģenta apstiprina, ka tavas aplikācijas loģika patiešām darbojas.

Biežāk uzdotie jautājumi

• Kas ir endpoints?

  Jebkas, kas ir adresējams internetā: HTTP/HTTPS URL, REST API, TCP porti (SMTP, MySQL, pielāgoti), resursdatoru nosaukumi pingam, DNS ieraksti, SSL sertifikāti un domēna reģistrācijas ieraksti. Konfigurē vienu monitoru katram endpointa tipam.

• Lietot HTTP vai TCP porta pārbaudi?

  HTTP ir labs noklusējuma variants katram tīmekļa pakalpojumam. TCP ports ir labāks ne-HTTP pakalpojumiem (datubāzes, pasta serveri, pielāgoti protokoli), kur svarīgs tikai “vai dēmons pieņem savienojumus”. Lieto TCP zemākā līmeņa pieejamības pārbaudei, HTTP — kad vajag pārliecināties, ka aplikācija patiesi atbild pareizi.

• Ar ko heartbeat monitori (cron-job) atšķiras?

  Heartbeat darbojas pretēji — nevis mēs vaicājam tavam pakalpojumam, bet tavs pakalpojums pingo mūs noteiktā URL. Ja nesaņemam ping noteiktajā laikā, brīdinājums tiek ģenerēts. Lieto cron jobiem, partiju procesiem un jebkam, kas darbojas pēc grafika bez tīkla intervences iespējas.

• Vai vienam URL var būt vairāki monitori?

  Jā. Vienu un to pašu mērķi vari monitorēt ar dažādiem pārbaudes tipiem — piem., HTTP pārbaude pilnai pieejamībai plus TCP port 443 pārbaude, kas atklāj TLS handshake problēmas. Katrs monitors darbojas neatkarīgi un brīdina atsevišķi.

• Vai SSL un domēns jāmonitorē atsevišķi?

  Nē — katram HTTPS endpointam automātiski tiek veikts SSL monitorings papildus uptime pārbaudei, un katrs monitorētais URL saņem arī ikdienas domēna derīguma beigu uzraudzību. Abi komplektā, bez papildu konfigurācijas. Domēna monitorings ir uz katru domēnu — vairāki monitori vienam domēnam dalās ar WHOIS datiem.