Monitorizare endpointuri

Ce este un "endpoint"?

Un endpoint este orice este adresabil pe internet și poate fi interogat pentru a verifica disponibilitatea. Cazul clasic este URL-ul unei pagini web — dar în infrastructura modernă, lucrurile de care ai grijă sunt mult mai diverse: REST API, endpoint-uri GraphQL, servere de email, ascultătoare de baze de date, cozi de mesaje, porturi health-check ale containerelor, panouri admin interne, receptori de webhook-uri. DiagnoSEO Uptime Monitoring le tratează unitar: definești ce înseamnă „sănătos” pentru acel endpoint, setezi programul verificărilor, primești avertizare la defecțiuni.

Această pagină descrie fiecare tip de endpoint pe care unelta îl suportă, la ce folosește fiecare și ce semnal oferă monitorizarea.

Endpoint-uri HTTP / HTTPS (pagini web)

Cazul implicit. Introduci https://example.com și monitorul efectuează o cerere GET la un interval stabilit (1 minut, 5, 10, 30 sau 60 de minute, în funcție de plan). Un check reușit înseamnă: conexiunea TCP a fost stabilită, handshake-ul TLS finalizat (pentru HTTPS), a fost primit un răspuns HTTP cu cod de status așteptat (implicit: 2xx sau 3xx), și opțional un cuvânt cheie prezent (sau absent) în corpul răspunsului. Verificarea înregistrează Time To First Byte, timpul total de răspuns, dimensiunea conținutului, lanțul de redirect-uri și întregul set de headere din răspuns.

Endpoint-urile HTTP sunt alegerea potrivită pentru: pagini de prezentare, bloguri, magazine online, dashboard-uri SaaS, portaluri de documentație — peste tot unde oamenii accesează cu browserul.

Endpoint-uri API (REST / GraphQL / JSON-RPC)

API-urile au nevoie de ceva mai mult decât „a răspuns” — au nevoie de „a răspuns corect”. Configurezi monitorul cu o metodă HTTP personalizată (GET, POST, PUT, DELETE, PATCH), headere custom (tokenuri de autentificare, content-type), corpul cererii (payload JSON pentru POST/PUT) și aserțiuni JSON asupra răspunsului (data.status trebuie să fie egal cu "ok", result.count trebuie să fie mai mare de 0, errors[] trebuie să fie gol). Un API care întoarce HTTP 200 cu un payload defect este cel mai rău tip de defecțiune — arată sănătos pentru un monitor naiv dar eșuează pentru fiecare client. Aserțiunile JSON le surprind.

Vezi ghidul dedicat monitorizării API pentru detalii de configurație și sintaxa aserțiunilor.

Endpoint-uri port TCP

Pentru servicii non-HTTP: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), ascultătoare de baze de date (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), porturi custom de aplicație. Monitorul deschide o conexiune TCP la host:port și raportează succesul dacă conexiunea a fost acceptată în fereastra de timeout. Fără handshake la nivel de protocol — pur și simplu „dacă demonul ascultă”.

Acesta este monitorul potrivit pentru orice serviciu bazat pe TCP unde vrei să verifici disponibilitatea și nu ai nevoie de verificări sensibile la protocol. Pentru verificarea bannerului SMTP sau verificări la nivel de query pentru baze de date, folosește monitorul heartbeat (serviciul tău trimite ping când e sănătos, vezi monitorizarea cron-job / heartbeat).

Endpoint-uri ping (ICMP)

Verificare de disponibilitate la nivelul 3. Monitorul trimite o cerere ICMP echo către hostname-ul sau IP-ul țintă și așteaptă răspuns. Util pentru routere, switch-uri, dispozitive IoT, orice răspunde la ping dar nu rulează HTTP. Ține minte că mulți furnizori cloud (AWS, GCP, Azure) blochează implicit ICMP la nivel de security-group chiar dacă hostul e în rest sănătos — pentru workload-uri în cloud preferă verificări HTTP sau porturi TCP.

Endpoint-uri hostname / DNS

Monitorizarea rezolvării DNS. Unelta rezolvă periodic înregistrările A, AAAA, MX, NS, TXT și CNAME ale domeniului tău, face un snapshot al rezultatelor și alertează dacă vreuna se schimbă. Prinde: preluări DNS neautorizate, erori accidentale de configurare în timpul migrării provider-ului DNS, servicii externe ce își actualizează endpoint-urile fără notificare (CDN-ul tău schimbă blocuri IP, de exemplu), înregistrări MX șterse dintr-o greșeală de tastare.

Monitorizarea DNS nu este despre disponibilitate — providerul tău DNS este aproape sigur mai fiabil decât originea. Este despre detectarea schimbărilor. Vezi monitorizarea modificărilor DNS pentru detalii complete.

Endpoint-uri certificate SSL

Fiecare endpoint HTTPS primește monitorizare automată SSL peste verificarea principală de uptime. Unelta citește certificatul, parsează perioada de valabilitate și emițătorul, și avertizează cu 30, 14, 7, 3 și 1 zile înainte de expirare. Vezi monitorizarea certificatelor SSL pentru detalii.

Endpoint-uri expirare domeniu

Pentru fiecare URL monitorizat, unelta interoghează WHOIS o dată pe zi și urmărește data de expirare a înregistrării domeniului. Alertele pornesc la aceleași praguri ca SSL (30/14/7/3/1 zile). Neplata reînnoirilor e catastrofală — domeniul rămâne fără proprietar și altcineva îl poate înregistra când expiră perioada de grație. Vezi monitorizarea expirării domeniului.

Alegerea tipului potrivit de endpoint

Dacă nu știi ce tip de monitor să folosești, începe cu HTTP/HTTPS pentru tot ce are interfață web, port TCP pentru restul și adaugă verificări heartbeat pentru joburi batch care nu expun nicăieri la rețea. Poți monitoriza aceleași ținte cu mai multe tipuri — de exemplu verificarea portului TCP pe 443 va prinde „serverul este pornit, dar handshake-ul TLS e stricat”, pe când verificarea HTTP pe același URL va semnala de asemenea problema, iar heartbeat-ul de la propriul tău agent intern va confirma că logica aplicației chiar funcționează.

Întrebări frecvente

• Ce este un endpoint?

  Orice adresabil pe internet: URL-uri HTTP/HTTPS, REST API, porturi TCP (SMTP, MySQL, custom), hostname-uri de ping, înregistrări DNS, certificate SSL și date WHOIS de domeniu. Configurează un monitor pentru fiecare tip de endpoint.

• Să folosesc verificare HTTP sau port TCP?

  HTTP e o alegere implicită bună pentru orice serviciu web. Portul TCP e mai potrivit pentru servicii non-HTTP (baze de date, servere de email, protocoale personalizate) unde te interesează doar „dacă demonul acceptă conexiuni”. Folosește TCP pentru disponibilitate de bază, HTTP pentru „aplicația chiar răspunde corect”.

• Cu ce diferă monitoarele heartbeat (cron-job)?

  Heartbeat este invers — în loc să interogăm noi serviciul tău, serviciul tău ne face ping la un URL cunoscut. Dacă nu primim ping-ul în fereastra așteptată, emitem alertă. Se folosește pentru cron-jobs, procese batch și tot ce rulează programat fără expunere la rețea pentru verificare.

• Poate un URL avea mai multe monitoare?

  Da. Poți monitoriza aceeași țintă cu mai multe tipuri de verificare — ex. check HTTP pentru disponibilitate completă plus check TCP pe portul 443 care prinde probleme de handshake TLS. Fiecare monitor funcționează independent și emite alertă separat.

• Trebuie să monitorizez SSL și domeniul separat?

  Nu — fiecare endpoint HTTPS primește automat monitorizare SSL peste verificarea principală de uptime, iar fiecare URL monitorizat primește urmărire zilnică a expirării domeniului. Ambele la pachet, fără configurare suplimentară. Monitorizarea domeniului e per-domeniu — mai multe monitoare pe aceeași domeniu folosesc aceleași date WHOIS.