Végpontok felügyelete

Mi az az „endpoint”?

Az endpoint minden, ami az interneten címezhető, és lekérdezhető annak elérhetőségének ellenőrzésére. A klasszikus eset a weboldal URL-je, ám a modern infrastruktúrában az általad felügyelt „dolgok” sokkal változatosabbak: REST API, GraphQL endpointok, levelezőszerverek, adatbázis-listenerek, üzenetsorok, konténer health-check portok, belső admin panelek, webhook-címzettek. A DiagnoSEO Uptime Monitoring ezeket egységesen kezeli: megadod, mit jelent az, hogy az endpoint „egészséges”, beállítod az ellenőrzési ütemezést, és hibánál riasztást kapsz.

Ez az oldal leírja az egyes endpointtípusokat, amelyeket az eszköz kezel, mire alkalmasak, és milyen jelzést ad a monitorozásuk.

HTTP / HTTPS endpointok (weboldalak)

Az alapértelmezett eset. Megadod a https://example.com címet, és a monitor az előírt időközönként (1, 5, 10, 30 vagy 60 percenként a csomagtól függően) GET kérést hajt végre. Sikeres ellenőrzés: TCP kapcsolat létrejött, TLS-kézfogás sikeres (HTTPS esetén), HTTP-válasz érkezett a várt státuszkóddal (alapértelmezésben: 2xx vagy 3xx), illetve opcionálisan a kulcsszó jelenléte (vagy hiánya) a válasz törzsben. Az ellenőrzés rögzíti a Time To First Byte-ot, a teljes válaszidőt, a tartalomméretet, az átirányítási láncot és a teljes válaszfejléc-készletet.

A HTTP endpoint ideális választás marketingoldalak, blogok, e-kereskedelmi áruházak, SaaS dashboardok, dokumentációs portálok esetében – minden olyan helyen, amit böngészőn keresztül látogatnak az emberek.

API endpointok (REST / GraphQL / JSON-RPC)

Az API-knál többre van szükség, mint hogy „válaszolt-e” – azt kell tudni, hogy „helyesen válaszolt-e”. A monitort konfigurálhatod egyedi HTTP metódussal (GET, POST, PUT, DELETE, PATCH), egyedi fejlécekkel (auth tokenek, content-type), lekérdezés törzzsel (pl. JSON payload POST/PUT esetén), valamint JSON-aszerciókkal a válaszban (data.status értékének "ok" kell lennie, result.count nagyobb, mint 0, errors[] üres). Egy HTTP 200-at visszaadó API hibás payload-dal a legrosszabb típusú hiba – egy naiv monitor szerint minden rendben, de minden kliens számára használhatatlan. A JSON-aszerciók ezt kiszűrik.

Lásd az API-monitorozás dedikált útmutatóját a konfiguráció és az aszerció szintaxisának részleteiért.

TCP port endpointok

Nem-HTTP szolgáltatásokhoz: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), adatbázis-listenerek (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), egyedi alkalmazásportok. A monitor TCP-kapcsolatot nyit a beállított host:port címhez, és sikeresnek tekinti, ha a kapcsolatot a timeout ablakon belül elfogadja a szerver. Nincs protokollszintű kézfogás – csupán azt nézi, „figyel-e a démon”.

Ez a monitor minden TCP-alapú szolgáltatáshoz megfelelő, amikor lényeges a rendelkezésre állás, de nem kell protokolltudatos ellenőrzés. SMTP banner validálásához vagy adatbázis lekérdezésszintű ellenőrzéséhez használj heartbeat monitort (a szolgáltatásod pingel minket, amikor egészséges – lásd cron-job / heartbeat monitoring).

Ping endpointok (ICMP)

Elérhetőségi ellenőrzés 3-as szinten. A monitor ICMP echo kérést küld a megadott hostnévhez vagy IP-hez, és választ vár. Hasznos routerek, switchek, IoT-eszközök és minden olyan dolog esetén, ami válaszol pingre, de nem fut rajta HTTP. Ne feledd, hogy sok felhőszolgáltató (AWS, GCP, Azure) alapértelmezetten blokkolja az ICMP-t a security groupok szintjén, még ha a host egyébként egészséges – felhős workloadoknál inkább használj HTTP vagy TCP port ellenőrzést.

Hostname / DNS endpointok

DNS feloldás monitorozás. Az eszköz időszakosan feloldja a domained A, AAAA, MX, NS, TXT és CNAME rekordjait, pillanatképet készít az eredményekről, és riaszt, ha bármelyik megváltozik. Kiszűri: jogosulatlan DNS-átvételt, véletlen konfigurációs hibákat DNS szolgáltatóváltáskor, külső szolgáltatásokat, amelyek értesítés nélkül módosítják az endpointjaikat (pl. a CDN szolgáltatód IP-blokkokat cserél), vagy MX rekordokat, amelyeket elírás törölt le.

A DNS monitorozás nem a rendelkezésre állásról szól – a DNS-szolgáltatód szinte biztosan megbízhatóbb, mint az origin. Itt a változás felismerése a lényeg. Lásd a DNS-változás monitorozást a részletes leírásért.

SSL tanúsítvány endpointok

Minden HTTPS endpoint automatikusan SSL-figyelést kap az uptime ellenőrzés tetején. Az eszköz leolvassa a tanúsítványt, elemzi a lejárati időt és a kibocsátót, és 30, 14, 7, 3 és 1 nappal a lejárat előtt figyelmeztet. Részletekért lásd az SSL tanúsítvány figyelést.

Domainek lejárati endpointjai

Minden monitorozott URL-nél az eszköz naponta egyszer WHOIS lekérdezést is futtat, rögzíti a domain regisztráció lejárati dátumát. A figyelmeztetések megegyeznek az SSL esetében használt küszöbökkel (30/14/7/3/1 nap). Megújítási díj elmaradása végzetes lehet – a domain tulajdonos nélkülivé válik, valaki azonnal regisztrálhatja a türelmi idő leteltével. Lásd a domain lejárati ellenőrzést.

A megfelelő endpoint típus kiválasztása

Ha nem tudod, melyik monitor típust válaszd, kezdj HTTP/HTTPS-sel minden webes felület esetén, TCP porttal a többi szolgáltatásnál, és adj hozzá heartbeat ellenőrzést a batch feladatokhoz, amelyeknek nincs hálózati elérhetősége. Egy célt többféle típussal is ellenőrizhetsz – például egy TCP port 443 ellenőrző vizsgálat kiszűrheti, ha a szerver elérhető, de a TLS-kézfogás hibás; ezt egy HTTP ellenőrzés ugyanazon az URL-en szintén jelezné, miközben saját belső monitoring ügynököd heartbeat-je megerősítené, hogy az alkalmazáslogika ténylegesen működik.

Gyakran ismételt kérdések

• Mi az az endpoint?

  Minden, ami az interneten címezhető: HTTP/HTTPS URL-ek, REST API-k, TCP portok (SMTP, MySQL, egyedi portok), pingelhető hostnevek, DNS rekordok, SSL tanúsítványok és domain regisztrációs bejegyzések. Minden endpoint típushoz állíts be egy monitort.

• HTTP vagy TCP port ellenőrzést használjak?

  A HTTP jó alapértelmezett választás minden webes szolgáltatáshoz. A TCP port jobb nem-HTTP szolgáltatásoknál (adatbázisok, levelezőszerverek, egyedi protokollok), ahol csak az számít, „fogad-e a démon kapcsolatot”. A TCP az alacsony szintű elérhetőségre való, a HTTP pedig azt ellenőrzi, hogy az alkalmazás valóban helyesen válaszol-e.

• Miben különböznek a heartbeat (cron-job) monitorok?

  A heartbeat fordított — nem mi kérdezzük le a szolgáltatásodat, hanem a szolgáltatásod pingel minket egy ismert URL-en. Ha az elvárt időablakon belül nem érkezik ping, riasztást küldünk. Cron joboknál, batch folyamatoknál és minden olyan esetben használatos, ahol nincs hálózaton elérhető felület az ellenőrzéshez.

• Lehet egy URL-hez több monitor?

  Igen. Ugyanazt a célt többféle ellenőrzéssel is monitorozhatod – például HTTP vizsgálat teljes elérhetőségre, plusz TCP check a 443-as porton, ami TLS-kézfogási problémákat észlelhet. Minden monitor függetlenül működik és jelez.

• Külön kell monitorozni az SSL-t és a domaint?

  Nem – minden HTTPS endpoint automatikusan SSL-figyelést kap az uptime ellenőrzés mellé, minden monitorozott URL-nél automatikus domain lejárati követés van. Mindkettő alapból jár, külön beállítás nélkül. A domain monitorozás domain-szintű — több monitor ugyanazon a domainen közös WHOIS adatokat használ.