Päätepisteiden valvonta

Mikä on "endpoint"?

Endpoint on mikä tahansa internetissä osoitettavissa oleva asia, jota voidaan kysellä saatavuuden varmistamiseksi. Klassinen tapaus on WWW-sivun URL — mutta nykyaikaisessa infrastruktuurissa asiat, joista huolehdit, ovat paljon monimuotoisempia: REST API:t, GraphQL-endpointit, sähköpostipalvelimet, tietokantakuuntelijat, viestijonot, konttien health-check-portit, sisäiset hallintapaneelit, webhook-vastaanottajat. DiagnoSEO Käytettävyysvalvonta käsittelee näitä yhtenäisesti: määrittelet mikä tarkoittaa "tervettä" kyseiselle endpointille, määrität tarkistusten aikataulun, saat hälytyksen vikatilanteessa.

Tämä sivu kuvaa jokaisen endpoint-tyypin, jota työkalu tukee, mihin kukin sopii ja minkälaista signaalia valvonta antaa.

HTTP / HTTPS -endpointit (WWW-sivut)

Oletustapaus. Syötät https://example.com ja monitori tekee GET-pyynnön määritetyin välein (1 minuutti, 5, 10, 30 tai 60 minuuttia suunnitelmasta riippuen). Onnistunut tarkistus tarkoittaa: TCP-yhteys muodostettu, TLS-kättely valmis (HTTPS:lle), vastattu HTTP-odotetulla statuskoodilla (oletuksena: 2xx tai 3xx), sekä valinnainen avainsana vastauksen bodysta löytynyt (tai puuttuu). Tarkistus kirjaa Time To First Byte -ajan, koko vasteajan, sisällön koon, uudelleenohjausketjun ja täydellisen vastausotsikkosarjan.

HTTP-endpointit ovat paras valinta markkinointisivustoille, blogeille, verkkokaupoille, SaaS-hallintapaneeleille, dokumentaatioportaaleille — kaikkialle, missä ihmiset vierailevat selaimella.

API-endpointit (REST / GraphQL / JSON-RPC)

API:lle pelkkä "vastasiko" ei riitä — tarvitset "vastasiko oikein". Konfiguroit monitorin omalla HTTP-metodilla (GET, POST, PUT, DELETE, PATCH), mukautetuilla otsikoilla (auth-tokenit, content-type), pyyntöbodyn (POST/PUT JSON-payload) sekä JSON-väitteillä vastaukseen (data.status on oltava "ok", result.count on oltava suurempi kuin 0, errors[] on oltava tyhjä). API, joka palauttaa HTTP 200 mutta viallisella payloadilla, on pahin vikatyyppi — näyttää terveeltä naivilta valvojalta, mutta epäonnistuu jokaiselle asiakkaalle. JSON-väitteet havaitsevat tämän.

Katso oma API-valvonnan opas asetusten ja väitelauseiden syntaksin yksityiskohtiin.

TCP-porttien endpointit

Ei-HTTP-palveluille: SMTP (portti 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), tietokantakuuntelijat (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), custom-sovellusportit. Monitori avaa TCP-yhteyden annettuun host:port ja raportoi onnistumisen, jos yhteys hyväksytään aikakatkaisuikkunassa. Ei protokollatason kättelyä — vain "kuunteleeko palvelin".

Tämä on oikea valvonta kaikille TCP-pohjaisille palveluille, kun saatavuus on tärkeää mutta et tarvitse protokollatietoista tarkistusta. SMTP-bannerin varmistukseen tai tietokantatasoiseen kyselytarkistukseen käytä heartbeat-monitoria (palvelusi lähettää pingin meille ollessaan terve, ks. cron-job / heartbeat-valvonta).

Ping-endpointit (ICMP)

Käytettävyystarkistus kerroksessa 3. Monitori lähettää ICMP-echo-pyynnön kohdeisäntänimeen tai IP:hen ja odottaa vastausta. Hyödyllinen reitittimille, kytkimille, IoT-laitteille — kaikelle, mikä vastaa pingiin muttei tarjoa HTTP:tä. Muista, että monet pilvipalveluntarjoajat (AWS, GCP, Azure) estävät oletuksena ICMP:n security-group-tasolla, vaikka isäntä olisi muuten terve — pilvityökuormille suosi HTTP- tai TCP-porttitarkistuksia.

Hostname- / DNS-endpointit

DNS-resoluution valvonta. Työkalu ratkaisee määräajoin domainisi A-, AAAA-, MX-, NS-, TXT- ja CNAME-tietueet, ottaa tuloksista snapshotin ja hälyttää, jos jokin muuttuu. Havaitsee: luvattomat DNS-kaappaukset, satunnaiset konfiguraatiovirheet DNS-tarjoajan vaihdossa, ulkoiset palvelut jotka päivittävät omat endpointinsa ilmoittamatta (esim. CDN vaihtaa IP-blokit), MX-tietueet tuhoutuvat kirjoitusvirheen vuoksi.

DNS-valvonnassa kyse ei ole saatavuudesta — DNS-palveluntarjoajasi on lähes varmasti luotettavampi kuin origin-palvelimesi. Kyse on muutoksen havaitsemisesta. Katso DNS-muutosten valvonta kattavampaan kuvaukseen.

SSL-varmenteiden endpointit

Jokainen HTTPS-endpoint saa automaattisen SSL-valvonnan käytettävyystarkistuksen lisäksi. Työkalu lukee varmenteen, jäsentää voimassaoloajan ja myöntäjän ja varoittaa 30, 14, 7, 3 ja 1 päivää ennen vanhenemista. Katso SSL-varmenteiden valvonta lisätietoja varten.

Verkkotunnuksen vanhenemisen endpointit

Jokaiselle valvotulle URL:lle työkalu kysyy myös WHOISia kerran päivässä ja seuraa verkkotunnuksen rekisteröinnin vanhentumispäivää. Varoitukset lähtevät samoilla tasoilla kuin SSL:ssä (30/14/7/3/1 päivää). Uusimismaksujen laiminlyönti on katastrofaalista — domain jää ilman omistajaa ja joku voi rekisteröidä sen heti grace-jakson päätyttyä. Katso domainin vanhenemisen valvonta.

Oikean endpoint-tyypin valinta

Jos et tiedä, minkä tyyppistä monitoria käyttää, aloita HTTP/HTTPS:llä kaikelle, jolla on webbikäyttöliittymä, TCP-portilla muille, ja lisää heartbeat-tarkistuksia batch-tehtäville, jotka eivät tarjoa verkkopintaa. Voit valvoa samaa kohdetta useilla eri tyypeillä — esimerkiksi TCP-portin tarkistus portilla 443 havaitsee "palvelin pystyssä, mutta TLS-kättely rikki" -tyyppiset ongelmat, jotka HTTP-tarkistus samalle URL:lle myös liputtaisi, kun taas heartbeat sisäiseltä omalta agentiltasi varmistaa, että sovelluksesi logiikka todella toimii.

Usein kysytyt kysymykset

• Mikä on endpoint?

  Kaikki internetissä osoitettavissa oleva: HTTP/HTTPS-URList, REST API, TCP-portit (SMTP, MySQL, customit), pingattavat hostnamet, DNS-tietueet, SSL-varmenteet ja domainin rekisteröintitiedot. Konfiguroi yksi monitori per endpoint-tyyppi.

• Kannattaako käyttää HTTP- vai TCP-porttitarkistusta?

  HTTP on hyvä oletusvalinta kaikille web-palveluille. TCP-portti on parempi ei-HTTP-palveluille (tietokannat, sähköpostipalvelimet, omat protokollat), joissa riittää tieto "ottaako palvelin yhteyksiä vastaan". Käytä TCP:tä matalan tason saatavuuteen, HTTP:tä kun haluat tietää "vastaako sovellus oikein".

• Miten heartbeat (cron-job) -monitori eroaa?

  Heartbeat toimii toisinpäin — sen sijaan, että me kyselisimme palveluasi, palvelusi lähettää meille pingin tunnettuun URL-osoitteeseen. Jos emme saa pingia odotetussa ikkunassa, hälytämme. Käytetään cron-tehtäville, batch-prosesseille ja tehtäville, jotka pyörivät aikataulun mukaan ilman tarkistettavaa verkko-interfacesoa.

• Voiko yhdellä URL:lla olla useita monitoreja?

  Kyllä. Voit valvoa samaa kohdetta eri tyyppisillä tarkistuksilla — esim. HTTP-tarkistus käytettävyyteen ja lisäksi TCP-portin 443 tarkistus, joka havaitsee TLS-kättelyyn liittyviä ongelmia. Jokainen monitori toimii itsenäisesti ja hälyttää erikseen.

• Pitääkö SSL ja domain monitoroida erikseen?

  Ei — jokainen HTTPS-endpoint saa automaattisesti SSL-valvonnan käytettävyystarkistuksen lisäksi ja jokaisella valvotulla URL:lla seurataan domainin vanhenemista päivittäin. Molemmat sisältyvät pakettiin ilman lisäasetuksia. Domainin valvonta on domain-kohtaista — useat monitorit samalla domainilla jakavat WHOIS-tiedot.