Sähköpostihälytys kolme sekuntia verkkosivuston kaatuessa ja ei enää viiden tunnin käyttökatko

Jokaisen valvontakerranksen alussa ja lopussa on aina sama raja: käyttökatko, joka kesti liian kauan, koska kukaan ei valvonut. Ennen valvontaa palvelimen ongelmat löydetään sattumalta. Kollegat mainitsevat, että sivusto tuntuu hitaalta. Asiakas lähettää vihaisesti sähköpostin. Kehittäjä yrittää ottaa päivityksen käyttöön ja huomaa, että palvelin on ollut tavoittamattomissa tuntikausia. Malli on surullisen johdonmukainen kaikissa organisaatioissa. Valvonnan jälkeen samasta palvelimen ongelmasta syntyy täysin erilainen kokemus. Palvelin kaatuu. Kolme sekuntia myöhemmin sähköposti saapuu. Joku alkaa tutkia asiaa minuutin sisällä. Korjaus otetaan käyttöön ennen kuin useimmat käyttäjät huomaavat mitään olevan vialla. Näiden kahden skenaarion välinen ero ei ole onni tai henkilöstön määrä. Se on joko automaattisen järjestelmän läsnäolo tai puuttuminen, joka valvoo jatkuvasti ja puhelee heti, kun jotain menee pieleen.

Perinteinen lähestymistapa palvelimen valvontaan rakennettiin operaatioiden ryhmille, joilla on omat infrastruktuuribudjetit. Työkalut kuten Nagios, Zabbix ja Prometheus ovat tehokkaat, mutta vaativat merkittävää asiantuntemusta määrittämiseen ja ylläpitoon. Ne toimivat omilla palvelimillaan, mikä luo filosofisen ongelman: kuka valvoo valvojaa? Yksittäisille kehittäjille, pienille toimistoille ja bootstrap-startupeille itse isännöidyn valvontapinon kustannukset usein ylittävät satunnaisten havaitsemattomien käyttökatkojen kustannukset, joten valvonta lykkääntyy jatkuvasti "myöhemmäksi" eikä myöhempi koskaan saavu. Pilvipohjainen valvontamalli poistaa tuon kustannuksen kokonaan. Ei palvelimia ylläpidettäväksi. Ei konfiguraatiotiedostoja hallittavaksi. Ei valvontainfrastruktuuria vahtimassa. Lisää päätepiste, määritä hälytysasetukset, ja järjestelmä hoitaa loput siitä.

Mitä uptime.yeb.to tekee, on käsitteellisesti yksinkertaista ja huolellisesti toteutettua. Jokaista valvottavaa päätepistettä tarkistetaan säännöllisesti neljällä erillisellä tavalla: perusverkkovapaus ping-menetelmällä, täydellinen HTTPS-pyynnön valmistuminen, SSL-sertifikaatin kelpoisuus ja vanhentumisaikataulu sekä vasteajan mittaus. Jokainen mittaus havaitsee erilaisen vikatyyppiluokan, ja yhdessä ne antavat kattavan kuvan siitä, onko palvelu paitsi verkossa myös tosiasiallisesti terveenä ja toimiva hyvin. Palvelin, joka vastaa ping-pyyntöihin mutta epäonnistuu HTTPS-tarkistuksissa, on verkkopalvelimen ongelma. Palvelin, joka läpäisee kaikki tarkistukset mutta osoittaa tasaisesti kasvavia vasteaikoja, on matkalla kaatumaan. Palvelin, jolla on kelvollinen SSL-sertifikaatti, joka vanhenee kolmen päivän kuluttua, on lähellä käynnistää selainvaroituksia, jotka ajavat pois kävijöitä. Jokainen näistä skenaarioista vaatii erilaisen vasteen, ja jokainen on näkymätön ilman aktiivista valvontaa.

Mitä monitori todella tarkistaa ja miksi jokainen kerros on tärkeä

Ping-valvonta on perustavanlaatuisin kerros ja samalla yleisimmin väärinymmärretty. Onnistunut ping-vastaus tarkoittaa, että palvelimen käyttöjärjestelmä on käynnissä ja verkkorata mittauspisteeltä palvelimelle on vapaa. Se ei tarkoita, että verkkopalvelin on käynnissä. Se ei tarkoita, että sovellus toimii. Se ei tarkoita, että käyttäjät voivat tosiasiallisesti ladata sivua. Ping on perusta, pienin elonmerkki, ja kaikki muu rakentuu sen päälle. Kun ping-tarkistus epäonnistuu, ongelma on vakava: joko palvelin on kokonaan pois käytöstä, tai perusverkko-ongelma estää kaikelta liikenteeltä pääsyn laitteelle. Nämä ovat käyttökatkoja, jotka vaikuttavat kaikkeen, ei vain verkkokäyttöön vaan myös SSH-käyttöön, tietokantayhteyksiin, sähköpostin toimittamiseen ja jokaiseen muuhun palveluun, joka toimii kyseisellä koneella.

HTTPS-valvonta lisää kriittisen kerroksen, joka ping jää puuttumaan. HTTPS-tarkistus suorittaa täydellisen verkko-pyynnön, samanlaisesti kuin selain tekee, kun käyttäjä vierailee sivustolla. Tarkistus varmistaa, että verkkopalvelin hyväksyy yhteydet, SSL-kättelysopimus valmistuu onnistuneesti, palvelin palauttaa kelvollisen HTTP-vastauksen ja koko prosessi valmistuu kohtuullisessa ajassa. Tämä havaitsee laajan ongelmaryhmän, jota ping ei voi havaita: kaatuneet verkkopalvelimen prosessit, väärin määritellyt SSL-sertifikaatit, sovelluksen virheet, jotka palauttavat HTTP 500 -tilakodit, ja suorituskyvyn heikkeneminen, joka tekee sivustosta käytännössä käyttökelvottoman, vaikka se on teknisesti "verkossa". Ero palvelimen tavoitettavuuden ja verkkosivuston käytettävyyden välillä on juuri se kuilu, jonka HTTPS-valvonta täyttää.

SSL-sertifikaatin valvonta käsittelee ongelmaa, joka on purrut lähes jokaista verkkosivuston ylläpitäjää ainakin kerran. Sertifikaatit vanhenevat. Let's Encryptiltä peräisin olevat ilmaiset sertifikaatit kestävät 90 päivää. Maksetut sertifikaatit kestävät tyypillisesti yhden vuoden. Molemmissa tapauksissa vanhentumispäivämäärä saapuu väistämättä, ja silti sertifikaatin uusintaukset unohdetaan hämmästyttävällä taajuudella. Syy on yksinkertainen: sisäänrakennettua muistutusjärjestelmää ei ole. Sertifikaattiviranomaiset eivät aina lähetä uusintailmoituksia. Automatisoitujen uusintaskriptit toisinaan epäonnistuvat äänettömästi. Ja vanhentuneesta sertifikaatista johtuvat seuraukset ovat välittömiä ja jyrkkiä. Selaimet näyttävät koko sivun turvallisuusvaroituksia. Hakukoneet merkitsevät sivuston. Käyttäjät, jotka näkevät nämä varoitukset, harvoin jatkavat, ja he usein eivät palaa edes sertifikaatin uusimisen jälkeen. Sertifikaatin vanhentumispäivän valvonta ja hälytys hyvissä ajoin ennen määräaikaa poistaa tämän kokonaan väistettävien tapausten luokan.

Vasteajan valvonta on varhaisen varoitus järjestelmä ongelmille, jotka eivät ole vielä tulleet käyttökatkoiksi mutta ovat menossa siihen suuntaan. Terve verkkopalvelin vastaa 100-300 millisekunnissa. Kun vasteajat alkavat nousta 500:een, sitten 800:aan, sitten 1500 millisekuntiin, jotakin on pieleen. Tietokantakyselyt saattavat kulkea hitaasti kasvavien taulukoiden vuoksi. Muistia voivat kuluttaa prosessivuoto. Levyn I/O voi olla kyllästynyt lokituksesta tai varmuuskopioimisesta. Nämä ongelmat eivät käynnistä ping-virheitä tai HTTPS-virheitä, mutta ne heikentävät käyttäjäkokemusta tavoin, jotka suoraan vaikuttavat pomppimisprosentteihin, muuntoprosentteihin ja hakukoneiden rankingiin. Vasteaikojen seuraaminen päivien ja viikkojen yli tekee trendeistä näkyviä hyvissä ajoin, ennen kuin ne kiihtyvät täyteen käyttökatkoihin.

Hälytyksen järjestelmä ja miksi kolme sekuntia muuttaa kaiken

Havaitsemisnopeuden on oltava yksittäin tärkein muuttuja käyttökadon vaikutuksen minimoimiseksi. Matematiikka on suoraviivaista: kokonaisvahingot sama kuin vaikutus minuutissa kerrottuna minuuttien määrällä. Havaitsemisajan vähentäminen viidestä tunnista kolmeen sekuntiin ei muuta vaikutusta minuutissa, mutta vähentää dramaattisesti minuuttien määrää. Palvelin, joka kaatuu ja korjataan kymmenen minuutin sisällä, kokee noin 0,002% käyttökatkon päivälle. Sama palvelin, joka kaatuu ja löydetään viiden tunnin kuluttua, kokee 0,35% käyttökadon, vaikka korjaus ottaisi saman kymmenen minuuttia. Kuukauden aikana nämä numerot kumuloituvat eroksi "neljän yhdeksän" luotettavuuden ja noloon käytettävyysprosenttiin, jota mikään asiakas ei halua nähdä tilasivullaan.

Hälytyksen toimittomekanismi on yhtä tärkeä kuin havaitsemisnopeuskin. Hälytys, joka saapuu raporttiin, jota kukaan ei katso, vastaa siihen, ettei hälytystä ole ollenkaan. Sähköposti on edelleen luotettavin ilmoituskanava useimmille operaattoreille, koska sähköposti on aina päällä, aina käytettävissä mistä tahansa laitteesta, eikä vaadi vielä yhden sovelluksen asentamista tai vielä yhden liittymän tarkistamista. Kun uptime.yeb.to havaitsee virheen, sähköpostihälytys lähetetään välittömästi kaikella olennaisella kontekstilla: mihin päätepistee epäonnistui, millainen tarkistus havaitsi ongelman, tarkka aikaleima ja vastaus, joka vastaanotettiin (tai virhe, joka tapahtui). Tämä tarkoittaa, että vastaanottaja voi alkaa diagnosoida ongelmaa itse sähköpostista ilman tarvetta kirjautua valvontaraporttiin ensin.

Palautumisen ilmoitukset ovat yhtä tärkeitä ja usein unohdettuja. Tietämys siitä, milloin palvelin tulee takaisin verkossa, on yhtä arvokas kuin tieto siitä, milloin se menee alas. Palautumisen hälytykset sisältävät käyttökadon kokonaiskeston, joka syötetään suoraan jälkitapahtumaanalyyseille ja raportointiin. Ne myös estävät tarpeeton eskaloinnin, joka tapahtuu, kun hälytys vastaanotetaan mutta seurantaa ei lähetetä sen jälkeen, kun ongelma ratkesi itsestään. Ilman palautumisen ilmoituksia jokainen hälytys luo avoimen silmukan, joka vaatii manuaalisen varmistuksen ja kuluttaa aikaa ja huomiota, jota voitaisiin käyttää tuottavammassa työssä.

Päivittäiset yhteenvedot, viikottaiset raportit ja pitkän aikavälin näkymä

Reaaliaikaiset hälytykset käsittelevät kiireelliset ongelmat. Yhteenvedot käsittelevät kaiken muun. Päivittäinen yhteenveto sähköposti saapuu joka aamu, jossa on täydellinen yhteenveto edellisestä 24 tunnista: käytettävyysprosentit jokaiselle valvottavalle päätepisteelle, keskimääräiset ja huippuvasteajat, mahdolliset tapahtumat ja niiden kestot sekä SSL-sertifikaatin vanhentumisen tila kaikille HTTPS-päätepisteille. Tämä sähköposti vie noin 30 sekuntia skannata ja antaa välittömän vastauksen kysymykseen "onko kaikki terveenä?" ilman tarvetta kirjautua mihinkään raporttiin tai tehdä mitään manuaalista tarkistusta.

Viikottaiset yhteenvedot zoomaa pidemmälle, paljastaen trendejä, jotka ovat näkymättömiä päivittäisellä tasolla. Palvelin, joka ylläpiti 100% käytettävyyttä joka päivä viikolla mutta osoitti vasteaikoja nousevia 50 millisekuntia joka päivä, on kehittyvä ongelma, jonka päivittäinen yhteenveto ei ehkä tee ilmiselväksi mutta viikottainen trendigraafi tekee selväksi. Samoin palvelin, joka koki kaksi lyhyttä käyttökatoa eri viikonpäivinä, voi paljastaa mallia, kun sitä tarkastellaan yhdessä: molemmat käyttökatot tapahtuivat klo 3 yöllä automatisoitua varmuuskopion aikana, mikä viittaa siihen, että varmuuskopiointiprosessi kuluttaa liikaa resursseja ja se on optimoitava tai ajoitettava uudelleen. Nämä mallit ilmaantuvat vain silloin, kun tiedot kootaan ajan kuluessa, ja viikottainen yhteenveto on suunniteltu nostamaan esiin juuri nämä oivallukset.

Tapahtumahistoria tarjoaa yksityiskohtaisen forensic-tietueen, jonka yhteenvedot summeeraavat. Jokainen havaittu käyttökatko kirjataan alkamisajalla, päätymisajalla, kestolla, vaikuttuneilla tarkistuksilla ja vastausketkalla, joka osoitti vian. Tämä historia palvelee useita tarkoituksia. Se tarjoaa tiedot, joita tarvitaan jälkitapahtuman tarkisteluksi ja juurisyyn analyysiksi. Se luo vastuullisuuden palveluntarjoajien kanssa käsiteltäessä SLA-vaatimustenmukaisuutta. Se luo käytettävyystilastot, joita tarvitaan tilalähdösivuille ja asiakasraporteille. Ja se rakentaa pitkäaikaisen tietueen, joka voi ohjata infrastruktuuripäätöksiä, kuten sitä, täyttääkö tietty isännöintitarjoaja sen luotettavuuslupauksensa vai onko siirtymä erääntynyt.

Usean alueen mittauspisteet ja yksittäisen sijainnin valvonnan sokeat pisteet

Palvelin voi olla täysin tavoitettavissa Frankfurtista ja täysin tavoittamattomissa Tokiosta samaan aikaan. Verkkojen reititys ei ole yhtenäinen maailmanlaajuisesti. Internetpalveluntarjoajat tekevät reitityksen päätöksiä, jotka voivat luoda alueellisia yhteysongelmia, jotka vaikuttavat tiettyihin maantieteellisiin käytäviin samalla kun jättävät toiset täysin vaikuttamattomiksi. DNS-levittämisen viiveet voivat tarkoittaa, että palvelimen siirtyminen on valmis ja vahvistettu yhdeltä mantereelta sillä aikaa, kun käyttäjät toisella mantereella ohjataan edelleen vanhalle, mahdollisesti offline-palvelimelle. CDN-väärinkonfiguraatiot voivat toimittaa vanhentunutta tai virhesisältöä tietyille alueille samalla kun muut alueet saavat oikean, ajantasaisen sivun.

Yksittäisen sijainnin valvonta on sokea kaikille näille skenaarioille. Jos mittauspiste on samassa tietokeskuksen alueella palvelimen kanssa, se raportoi 100% käytettävyyden sillä aikaa, kun puolet globaalista käyttäjäkunnasta ei pääse sivustolle. Usean alueen valvonta kuudesta maantieteellisesti hajautetusta sijainnista havaitsee nämä erot suunnittelun mukaan. Kun tarkistus epäonnistuu yhdeltä alueelta mutta onnistuu toisista, hälytys sisältää maantieteellisen kontekstin, joka välittömästi kaventaa ongelman alueellisen reititysongelman sijaan palvelimen puolelle. Tämä ero on valtavan tärkeä diagnoosille ja vasteelle: palvelimen puolelle oleva ongelma vaatii palveluiden uudelleenkäynnistämistä tai palveluntarjoajaan ottamista yhteyttä, kun taas alueellinen reititysongelmaa vaatii DNS:n, CDN-konfiguraation tai ISP-tason ongelmien tutkimista.

Kuusi valvontasijaintia valitaan peittämään suuret väestö- ja liikenteen keskukset maailmanlaajuisesti. Tämä tarkoittaa, että sivusto, joka palvelee asiakkaita Pohjois-Amerikassa, Euroopassa ja Aasiassa, on mittauspisteet näillä alueilla tai niiden lähellä, mikä tarjoaa todellista kattavuutta eikä illuusiota valvonnasta, jonka yksittäinen mittauspiste luo. Yrityksille, jotka riippuvat globaalista saatavuudesta, tämä usean alueen lähestymistapa ei ole vapaaehtoinen parannus. Se on pienin elinkelpoisesti valvontakonfiguraatio, joka voi tarkasti edustaa maantieteellisesti hajautetun käyttäjäkunnan kokemusta. uptime.yeb.to rakentaminen usean alueen kyvyllä alusta alkaen varmistaa, että valvonta on yhtä kattava kuin liikenne, jonka se suojaa.