Mejl upozorenja tri sekunde nakon što sajt padne i nikad ponovo pet sati kvarenja
Postoji "pre" i "posle" u svakoj priči o praćenju, a delatvorna linija je uvek ista: prekid koji je trajao previše dugo jer niko nije bio budna. Pre praćenja, problemi sa serverom se otkrivaju slučajno. Kolega spominje da sajt izgleda sporo. Kupac šalje ljutu poruku. Razvijač pokušava da primeni ažuriranje i otkriva da je server bio nedostupan satima. Obrazac je depresivno konzistentan u organizacijama svake veličine. Posle praćenja, isti problem sa serverom proizvodi fundamentalno drugačije iskustvo. Server pada. Tri sekunde kasnije, mejl stiže. Neko počinje da istražuje u roku od minuta. Ispravka se primenjuje pre nego što većina korisnika čak i primeti da je nešto bilo loše. Razlika između ova dva scenarija nije sreća ili nivoi zaposlenja. To je prisustvo ili odsustvo automatizovanog sistema koji kontinuirano prati i govori čim nešto krene naopako.
Tradicionalni pristup praćenju servera je izgrađen za timove operacija sa namenskim budžetima infrastrukture. Alati kao što su Nagios, Zabbix i Prometheus su moćni ali zahtevaju značajnu stručnost za konfiguraciju i održavanje. Rade na sopstvenim serverima, što stvara filozofski problem: ko prati monitor? Za pojedinačne razvijače, male agencije i pokrenute startupe, overhead pokretanja samohostovanog steka za praćenje često premašuje overhead povremenog nedetektovanog prekida, što znači da se praćenje perpetualno odložilo na "kasnije" a kasnije nikad ne dolazi. Model praćenja baziran na oblaku eliminira taj overhead potpuno. Nema servera za održavanje. Nema datoteka konfiguracije za upravljanje. Nema infrastrukture za praćenje da se brinemo. Dodaj krajnju tačku, konfiguriši preferencije upozorenja, i sistem preuzima odavde.
Ono što uptime.yeb.to radi je jednostavno u konceptu i temeljno u izvršenju. Svaka praćena krajnja tačka se proverava u redovnim intervalima u četiri jasno definisane dimenzije: osnovna mrežna dostupnost kroz ping, kompletan HTTPS zahtev dovršetak, validnost SSL sertifikata i vremensku liniju isteka, i merenje vremena odgovora. Svaka dimenzija hvata drugačiju kategoriju kvarenja, i zajedno pružaju sveobuhvatan prikaz da li je usluga ne samo dostupna već zaista zdrava i dobro funkcioniše. Server koji odgovara na ping ali ne prođe HTTPS provere ima problem sa web serverom. Server koji prođe sve provere ali pokazuje neprekidno rastuće vreme odgovora je usmeren prema padu. Server sa validnim SSL sertifikatom koji isteka za tri dana je spreman da izazove upozorenja u pretraživaču koja će odagnati posećivače. Svaki od ovih scenarija zahteva drugačiji odgovor, i svaki je nevidljiv bez aktivnog praćenja.
Šta monitor zaista proverava i zašto je svaki sloj važan
Praćenje ping-a je najosnovniji sloj, i takođe najčešće pogrešno razumevani. Uspešan ping odgovor znači da je operativni sistem na serveru radi i da je mrežna putanja između sonde za praćenje i servera jasna. To ne znači da je web server radi. To ne znači da aplikacija funkcioniše. To ne znači da korisnici mogu zapravo učitati stranicu. Ping je osnova, minimalno održivi znak života, a sve ostalo se gradi na vrhu toga. Kada provera ping-a ne uspe, problem je ozbiljan: ili je server potpuno offline ili postoji fundamentalni mrežni problem koji sprečava bilo kakav saobraćaj da dosegne mašinu. Ovo su prekidi koji utiču na sve, ne samo web saobraćaj već i SSH pristup, konekcije baze podataka, isporuku e-pošte i svaku drugu uslugu koja radi na toj mašini.
Praćenje HTTPS-a dodaje kritični sloj koji ping propušta. HTTPS provera izvršava kompletan veb zahtev, istu vrstu zahteva koju pretraživač pravi kada korisnik poseti vebsajt. Provera potvrđuje da web server prihvata konekcije, da se SSL rukovanje završava uspešno, da server vraća validan HTTP odgovor, i da se ceo proces završava u razumnom vremenskom okviru. Ovo hvata široku kategoriju problema koje ping ne može detektovati: srušene procese web servera, pogrešno konfigurisane SSL sertifikate, greške aplikacije koje vraćaju HTTP 500 statusne kodove, i degradaciju performansi koja čini sajt efektivno neupotrebljiv čak i iako je tehnički "online". Razlika između servera koji je dostupan i vebsajta koji je upotrebljiv je upravo jaz koji HTTPS praćenje popunjava.
Praćenje SSL sertifikata rešava problem koji je ubo skoro svakog operatora vebsajta bar jednom. Sertifikati ističu. Besplatni sertifikati od Let's Encrypt-a traju 90 dana. Plaćeni sertifikati tipično traju jednu godinu. U oba slučaja, datum isteka stiže sa apsolutnom sigurnošću, i ipak obnove sertifikata i dalje budu propuštene sa iznenađujućom frekvencijom. Razlog je jednostavan: nema ugrađenog sistema podsetnika. Autoriteti za sertifikate ne šalju uvek obavesti o obnovi. Automatizovani skripti za obnovu ponekad ne uspeju tiho. I posledice isteka sertifikata su trenutne i stroge. Pretraživači prikazuju upozorenja sa punom stranicom. Motori za pretraživanje označavaju sajt. Korisnici koji vide ta upozorenja retko nastavljaju, a često se ne vraćaju čak i posle što je sertifikat obnovljen. Praćenje datuma isteka sertifikata i upozorenje dobro pre roka eliminuje ovu celu kategoriju sprečljivih incidenata.
Praćenje vremena odgovora je sistem ranog upozorenja za probleme koji još nisu postali prekidi ali se kreću u tom smeru. Zdrav veb server odgovara u 100 do 300 milisekundi. Kada vreme odgovora počne da se penja na 500, zatim 800, zatim 1500 milisekundi, nešto je pogrešno. Upiti baze podataka mogu biti spora zbog rastućih veličina tabela. Memorija može biti konzumirana propustom u procesu. I/O diska može biti zasićen logom ili operacijama sigurnosnog kopiranja. Ovi problemi ne izazivaju greške ping-a ili HTTPS, ali degradiraju korisničko iskustvo na načine koji direktno utiču na stope napuštanja, stope konverzije i rangiranja motora za pretraživanje. Praćenjem vremena odgovora tokom dana i nedalja, trendovi postaju vidljivi dugo pre nego što eskaliraju u pune prekide.
Sistem upozorenja i zašto tri sekunde menjaju sve
Brzina detekcije je jedina važnija promenljiva u minimiziranju uticaja prekida. Matematika je direktna: ukupna šteta je jednaka uticaju po minuti pomnoženoj sa brojem minuta. Smanjenje vremena detekcije sa pet sati na tri sekunde ne menja uticaj po minuti, ali dramatično smanjuje broj minuta. Server koji pada i se ispravlja u roku od deset minuta doživljava otprilike 0,002% kvarenja za dan. Isti server koji pada i se otkriva pet sati kasnije doživljava 0,35% kvarenje čak i ako ispravka traje iste deset minuta. Tokom meseca, ti brojevi se sabuju u razliku između pouzdanosti od "četiri devetke" i sramne procente aktivnosti koju nijedan klijent ne želi da vidi na stranici statusa.
Mehanizam isporuke upozorenja je bitan koliko i brzina detekcije. Upozorenje koje stiže na tablu koju niko ne gleda je ekvivalentno bez upozorenja. E-pošta ostaje najpouzdaniji kanal obaveštavanja za većinu operatora jer e-pošta je uvek dostupna, uvek dostupna sa bilo kog uređaja, i ne zahteva instaliranje još jedne aplikacije ili proveru još jednog interfejsa. Kada uptime.yeb.to otkrije grešku, obaveštenje e-poštom je odmah poslato sa svim relevantnim kontekstom: koja krajnja tačka je propala, koja vrsta provere je otkrila problem, tačna vremenska oznaka, i odgovor koji je primljen (ili greška koja se dogodila). Ovo znači da primalac može početi dijagnozu problema samo iz e-poruke, bez potrebe da prvo prijavi na tablu praćenja.
Obaveštenja o oporavku su jednako važna i često se zanemaruju. Znanje kada se server vraća online je tako vredna kao i znanje kada pada. Obaveštenja o oporavku uključuju ukupno trajanje prekida, što ide direktno u analizu incidenata nakon incidenta i izveštavanje. Oni takođe sprečavaju nepotrebnu eskalaciju koja se dešava kada je upozorenje primljeno ali nema praćenja nakon što se problem reši. Bez obaveštenja o oporavku, svako upozorenje kreira otvorenu petlju koja zahteva ručnu verifikaciju, što konzumira vreme i pažnju koja mogu biti potrošena na produktivniji rad.
Dnevne sažetke, sedmični izveštaji i dugi pogled
Obavešenja u stvarnom vremenu rešavaju hiteće probleme. Sažetci rešavaju sve ostalo. Mejl sa dnevnim sažetkom stiže svakog jutra sa kompletnim sažetkom prethodnih 24 sata: procenti aktivnosti za svaku praćenu krajnju tačku, prosečno i vrhunsko vreme odgovora, bilo koji incidenti koji su se dogodili i njihova trajanja, i status isteka SSL sertifikata za sve HTTPS krajnje tačke. Ovaj mejl traje otprilike 30 sekundi za pregled i daje trenutni odgovor na pitanje "da li je sve zdravo?" bez zahteva za prijavu na bilo koju tablu ili ručnu proveru bilo čega.
Sedmični sažetci gledaju dalje, otkrivajući trendove koji su nevidljivi na dnevnom nivou. Server koji je održavao 100% aktivnost svakog dana sedmice ali je pokazao vremena odgovora koja se povećavaju za 50 milisekundi svaki dan ima razvojni problem koji dnevni sažetak možda ne bi jasno pokazao ali sedmični grafikon trendova ga čini besmislenim. Slično tome, server koji je doživeo dva kratka prekida na različitim danima sedmice može biti otkrio obrazac kada je vidan zajedno: oba prekida su se dogodila u 3 AM tokom automatizovanog prozora za sigurnosne kopije, što sugeriše da proces sigurnosnog kopiranja konzumira previše resursa i trebalo bi da bude optimizovan ili reuređen. Ovi obrasci se pojavljuju samo kada su podaci agregirani tokom vremena, i sedmični sažetak je namenjen da odsuda upravo te uvide.
Istorija incidenata pruža detaljnu sudsku evidenciju koju sažetci rezimiraju. Svaki detektovani prekid je evidentiran sa njegovim vremenom početka, vremenom kraja, trajanjem, pogođenim provama i podacima odgovora koji su ukazali na neuspeh. Ova istorija služi višestruke svrhe. Pruža podatke potrebne za preglede nakon incidenata i analizu osnovnih uzroka. Stvara odgovornost pri radu sa provajderima hostinga oko usaglašenosti SLA. Generiše statističke podatke aktivnosti potrebne za stranice statusa i izveštaje klijentima. I gradi dugoročnu evidenciju koja može informisati odluke infrastrukture kao što je da li određeni provajder hostinga ispunjava svoje obećane pouzdanosti ili da li je migracija dostigla dospeće.
Sonde sa više regiona i slepe tačke praćenja sa jednom lokacijom
Server može biti savršeno dostupan iz Frankfurta a potpuno nedostupan iz Tokija istovremeno. Mrežna rutiranja nisu ujednačena širom sveta. Provajderi interneta čine odluke o rutiranju koja mogu stvoriti regionalne probleme konekcije koji utiču na specifične geografske koridore dok ostale ostaju potpuno netrošni. Kašnjenja propagacije DNS-a mogu značiti da je migracija servera završena i proverena iz jednog kontinenta dok korisnici na drugom kontinentu još uvek budu usmeravani na stari, moguće offline, server. Pogrešne konfiguracije CDN-a mogu poslužiti zastarelo ili sadržaj greške specifičnim regionima dok drugi regioni primaju ispravnu, ažurnu stranicu.
Praćenje sa jednom lokacijom je slijepo za sve ove scenarije. Ako je sonda za praćenje u istom regijonu data centra kao server, prijaviće 100% aktivnost dok polovinu globalne baze korisnika ne može pristupiti sajtu. Praćenje sa više regiona iz šest geografski raspoređenih lokacija hvata ove neslaganja по дизајну. Kada provera propada iz jedne regije ali prođe iz ostalih, upozorenje uključuje geografski kontekst, koji odmah sužava problem na problemski problem rutiranja regije umesto greškom na strani servera. Ova razlika je ogromno važna za dijagnozu i odgovor: problem na strani servera zahteva restartovanje usluga ili kontaktiranje provajdera hostinga, dok problem rutiranja regije zahteva istraživanje DNS-a, konfiguracije CDN-a ili problema na nivou ISP-a.
Šest lokacija za praćenje je odabrano da pokrije glavne centre populacije i saobraćaja globalno. Ovo znači da vebsajt koji služi kupce izvan Severne Amerike, Evrope i Azije ima sonde u ili blizu svakog od tih regiona, pružajući pravo pokrivanje umesto iluzije praćenja koju jedna sonda stvara. Za biznise koji zavise od globalne dostupnosti, ovaj pristup sa više regiona nije opciono poboljšanje. To je minimalno održiva konfiguracija za praćenje koja može tačno predstavljati iskustvo geografski raspodeljene baze korisnika. Izgradnja uptime.yeb.to sa mogućnošću više regiona od početka osigurava da je praćenje tako sveobuhvatno kao i saobraćaj koji štiti.
Često postavljana pitanja
Koliko brzo monitor aktivnosti šalje upozorenje nakon detekcije kvarenja
Mejl sa upozorenjem se šalje u roku od nekoliko sekundi nakon potvrđene greške. Tačno vreme zavisi od intervala provere konfiguriranog za krajnju tačku, ali čim se detektuje propala provera, obaveštenje se šalje odmah. Ovo znači da je ukupno vreme od detekcije do obaveštenja mereno u sekundama, što omogućava operaterima da počnu sa istragom pre nego što većina korisnika čak i primeti prekid.
Koje vrste praćenja alat vrši
Četiri tipa se proveravaju za svaku praćenu krajnju tačku. Praćenje ping-a potvrđuje osnovnu mrežnu dostupnost. Praćenje HTTPS vrši kompletan veb zahtev da potvrdi da sajt pravilno služi stranice. Praćenje SSL sertifikata proverava validnost i datume isteka. Praćenje vremena odgovora prati koliko dugo zahtevima treba da se završe i označava degradaciju pre nego što postane puni prekid. Zajedno, ova četiri provere pokrivaju puni spektar uobičajenih grešaka servera i vebsajta.
Postoji li besplatan monitor aktivnosti koji zaista funkcioniše
Mnogi besplatni alati za praćenje postoje ali obično nameću stroga ograničenja na frekvenciju provere, broj praćenih krajnjih tačaka ili metode isporuke upozorenja. uptime.yeb.to je namenjen da pruži smisleno praćenje bez potrebe za bilansom preduzeća, sa planovima koji se skaliraju na osnovu toga koliko krajnjih tačaka trebalo pokrivanje umesto zaključavanja bitnih funkcija iza primijenjenih nivoa.
Šta je uključeno u mejl sa dnevnim sažetkom
Dnevni sažetak rezimira prethodnih 24 sata na svim praćenim krajnjim tačkama. Uključuje procente aktivnosti, prosečno i vrhunsko vreme odgovora, bilo koje incidenate koji su se dogodili sa njihovim trajanjem, i upozorenja o isteku SSL sertifikata. Mejl je namenjen da bude pregledan u manje od minuta i daje trenutni odgovor na to da li trebalo bilo kakve infrastrukturne probleme pažnje tog dana.
Može li monitor da proverava vebsajte iz više lokacija širom sveta
Da. Praćenje sa više regiona šalje provere iz šest geografski raspodeljenih lokacija, pokrivajući glavne centre saobraćaja globalno. Ovo hvata regionalne probleme konekcije, kašnjenja propagacije DNS-a i pogrešne konfiguracije CDN-a koje bi praćenje sa jednom lokacijom potpuno propustilo. Kada se greška detektuje iz jedne regije ali ne iz ostalih, upozorenje uključuje geografski kontekst da bi pomoglo dijagnozi da li je problem na strani servera ili na strani mreže.
Da li monitor prati datume isteka SSL sertifikata
Praćenje SSL sertifikata je ugrađena funkcija koja se pokreće sa svakim ciklušem provere. Potvrđuje da je sertifikat trenutno validan i izračunava broj dana do isteka. Upozorenja se šalju dobro pre datuma isteka, dajući dovoljno vremena za obnovu bez rizika od upozorenja o sigurnosti u pretraživaču ili penala motora za pretraživanje. Ovo sprečava iznenađujuće uobičajeni scenarij gde automatizovana obnova ne uspe tiho i sertifikat istekne bez da neko primeti dok posjetiloci ne počnu da vide stranice sa upozorenjem.