E-mail riasztás három másodperc után az oldal leállásakor, és soha ne legyen öt órás leállás

Minden monitorozási történetnek van egy előtte és egy után, és az osztóvonal mindig ugyanaz: a túl hosszú kimaradás, mert senki sem figyelt. A monitorozás előtt a szerver problémáit véletlen fedezik fel. Egy kolléga megemlíti, hogy az oldal lassúnak tűnik. Egy ügyfél dühös e-mailt küld. Egy fejlesztő megpróbál telepíteni egy frissítést, és felfedezi, hogy a szerver órák óta nem elérhető. A minta szomorúan konzisztens minden szervezetben. A monitorozás után az ugyanez a szerver probléma teljesen más tapasztalatot hoz. A szerver leáll. Három másodperc múlva egy e-mail érkezik. Valaki egy percen belül vizsgálódni kezd. A javítást telepítik, mielőtt a legtöbb felhasználó egyáltalán észrevenne valamit. A két forgatókönyv közötti különbség nem szerencse vagy személyzeti szint. Ez egy automatizált rendszer jelenléte vagy hiánya, amely folyamatosan figyel, és szót ejt abban a pillanatban, amikor valami rosszul megy.

A szerver monitorozáshoz tradicionális megközelítést az operatív csapatoknak szerveztek dedikált infrastruktúra költségvetéssel. Az olyan eszközök, mint a Nagios, Zabbix és Prometheus erőteljesek, de jelentős szakértelmet igényelnek a konfiguráláshoz és a karbantartáshoz. Saját szervereken futnak, amely filozófiai problémát hoz létre: ki figyeli a monitort? Az egyéni fejlesztők, a kis ügynökségek és a bootstrap startupok számára az önállóan üzemeltetett monitorozási stack terhelése gyakran meghaladja az alkalmi fel nem ismert kimaradás terhelését, ami azt jelenti, hogy a monitorozás örökre "később" halasztódik, és később soha nem érkezik el. A felhőalapú monitorozási modell teljesen kiküszöböli ezt a terhelést. Nincs szerver karbantartásához. Nincs konfigurációs fájl kezeléséhez. Nincs monitorozási infrastruktúra gondozásához. Adjon meg egy végpontot, konfigurálja a riasztási beállításokat, és a rendszer onnantól átveszi az irányítást.

Az, amit az uptime.yeb.to tesz, egyenes a fogalomban és alapos a végrehajtásban. Minden felügyelt végpont rendszeres időközönként négy különálló dimenzió szerint kerül ellenőrzésre: alapvető hálózati elérhetőség ping-gel, teljes HTTPS kérelem befejezése, SSL tanúsítvány érvényességi és lejárati ütemterv, valamint válaszidő mérés. Minden dimenzió más típusú hibát kap el, és együtt átfogó képet adnak arról, hogy egy szolgáltatás nem csak online, hanem ténylegesen egészséges és jól teljesít. Egy olyan szerver, amely válaszol a ping-re, de nem teljesíti az HTTPS ellenőrzéseket, webszerver problémája van. Egy olyan szerver, amely minden ellenőrzést végigmegy, de fokozatosan növekvő válaszidőket mutat, összeomlás felé halad. Az egy SSL tanúsítvánnyal rendelkező szerver, amely három nap múlva lejár, az böngészőfigyelmeztetéseket fog aktiválni, amely elűzi a látogatókat. Minden egyes forgatókönyv eltérő választ igényel, és mind láthatatlan az aktív monitorozás nélkül.

Mit ellenőriz valójában a monitor és miért fontos minden réteg

A ping monitorozás a legalapvetőbb réteg, és a leggyakrabban félreértett. A sikeres ping válasz azt jelenti, hogy a szerver operációs rendszere fut, és a monitorozási szonda és a szerver közötti hálózati elérési út tiszta. Ez nem azt jelenti, hogy a webszerver fut. Ez nem azt jelenti, hogy az alkalmazás működik. Ez nem azt jelenti, hogy a felhasználók ténylegesen betölthetnek egy oldalt. A ping az alapja, a minimális életjel, és minden más erre építkezik. Amikor egy ping ellenőrzés meghiúsul, a probléma súlyos: vagy a szerver teljesen offline, vagy egy alapvető hálózati probléma van, amely megakadályozza, hogy az összes forgalom eléri a gépet. Ezek a kimaradások, amelyek mindent érintenek, nem csak a webes forgalmat, hanem az SSH hozzáférést, az adatbázis kapcsolatokat, az e-mail szállítást és a szerveren futó minden más szolgáltatást.

Az HTTPS monitorozás hozzáadja a kritikus réteget, amely a ping hiányzik. Egy HTTPS ellenőrzés teljes webes kérelmet végez, ugyanolyan típusú kérelmet, amelyet egy böngésző végez, amikor a felhasználó webes oldalt látogat. Az ellenőrzés ellenőrzi, hogy a webszerver elfogad e a kapcsolatokat, hogy az SSL kézfogás sikeresen befejeződött, hogy a szerver érvényes HTTP válaszadást ad vissza, és hogy az egész folyamat ésszerű időkereten belül befejeződik. Ez egy széles körű problémakategóriát kap el, amelyet a ping nem tud felismerni: összeomlott webszerver folyamatokat, rosszul konfigurált SSL tanúsítványokat, alkalmazás hibákat, amelyek HTTP 500 státusza kódokat adnak vissza, és teljesítmény lebomlást, amely az oldalt gyakorlatilag használhatatlanná teszi még ha az technikai értelemben "online". Az a különbség, hogy egy szerver elérhető és egy weboldalas használható az HTTPS monitorozás rése.

Az SSL tanúsítvány monitorozás egy olyan problémát kezeli, amely szinte minden weboldalas operátor legalább egyszer megérint. A tanúsítványok lejáratnak. A Let's Encrypt-ből származó ingyenes tanúsítványok 90 napig tartanak. A kifizetett tanúsítványok általában egy évig tartanak. Mindkét esetben a lejárati dátum abszolút bizonyosságal érkezik, és mégis a tanúsítvány megújítások még mindig figyelemre méltó gyakorisággal elmaradnak. Az ok egyszerű: nincs beépített emlékeztetõ rendszer. A tanúsítványhatóságok nem mindig küldenek megújítási értesítéseket. Az automatizált megújítási parancsfájlok néha csendesesen meghibásodnak. Az lejárt tanúsítvány következménye pedig azonnali és kemény. A böngészők teljes lapos biztonsági figyelmeztetéseket jelenítik meg. A keresőmotorok megjelölik az oldalt. A felhasználók, akik ezeket a figyelmeztetéseket látják, ritkán haladnak tovább, és gyakran nem térnek vissza még azután sem, hogy a tanúsítvány megújul. A tanúsítvány lejárati dátumának monitorozása és az értesítések a határidő előtt elmúlik az ezt a preventív incidens teljes kategóriáját.

A válaszidő monitorozás a korai figyelmeztetõ rendszer az olyan problémákra, amelyek még nem váltak kimaradássá, de abban az irányban haladnak. Az egészséges webszerver 100-300 ezredmásodperc alatt reagál. Amikor a válaszidõk 500-ig, majd 800-ig, majd 1500 ezredmásodpercig kezdenek emelkedni, valami rosszul van. Az adatbázis lekérdezések lassan futhatnak a növekvõ táblaméretek miatt. A memória egy folyamat szivárgás által fogyasztható. A lemezátvitel telített lehet a naplózás vagy biztonsági mentési operációk által. Ezek a problémák nem aktiválják a ping meghibásodást vagy az HTTPS hibákat, de csökkentik a felhasználói élményt olyan módon, amely közvetlenül befolyásolja a visszapattanási arányokat, az átalakítási arányokat és a keresõmotor rangsorolásait. A válaszidõk nyomon követésével napok és hetek alatt a tendenciák sokkal előbb láthatóvá válnak, mielõtt azok teljes kimaradássá válnának.

A riasztási rendszer és miért három másodperc mindent megváltoztat

Az észlelés sebessége az egyetlen legfontosabb változó az állásidõ hatásának minimalizálásában. A matematika egyenes: a teljes kár egyenlő a percenkénti hatás szorozva a percek számával. A észlelési idõ csökkentése öt óráról három másodpercre nem változtatja meg a percenkénti hatást, de drámaian csökkenti az percek számát. Egy olyan szerver, amely leáll, és tíz percen belül megjavítják, körülbelül 0,002% állásidõt tapasztal a naphoz. Ugyanez a szerver, amely leáll, és öt óra múlva fedezik fel, 0,35% állásidõt tapasztal még akkor is, ha a javítás ugyanannyi időt vesz igénybe. Egy hónap alatt ezek a számok összeadódnak a "négy kilences" megbízhatóság és egy kínos felperésidõ százalék közötti különbségbe, amely egyetlen ügyfél sem akar látni az állapotozáson.

A riasztás szállítási mechanizmus olyan fontos, mint az észlelési sebesség. Egy olyan riasztás, amely egy olyan irányítópulton érkezik, amelyet senki sem figyel, egyenértékû az egyáltalán nem riasztással. Az e-mail továbbra is a legmegbízhatóbb értesítési csatorna a legtöbb operátor számára, mert az e-mail mindig van, mindig elérhető bármilyen eszközről, és nem igényli az egy másik alkalmazás telepítését vagy egy másik felület ellenõrzését. Amikor az uptime.yeb.to felismeri a hibát, az e-mail értesítés azonnal elküldõdik az összes releváns környezettel: melyik végpont hiúsult meg, milyen típusú ellenõrzés észlelte a problémát, a pontos időbélyeg és a kapott válasz (vagy az előfordult hiba). Ez azt jelenti, hogy a címzett az e-mailből is megkezdheti a probléma diagnosztizálását anélkül, hogy elõször be kellene jelentkeznie az irányítópult figyelembe vételéhez.

A helyreállítási értesítések egyaránt fontosak és gyakran figyelmen kívül hagyottak. Annak ismerete, hogy a szerver ismét online kerül, csakúgy fontos, mint annak ismerete, hogy leáll. A helyreállítási riasztások a kimaradás teljes időtartamát tartalmazzák, amely közvetlenül az incidens utáni elemzésbe és jelentésbe kerül. Megakadályozzák a szükségtelen eszkalációt, amely akkor történik meg, amikor egy riasztás érkezik, de nincs követõ után, hogy a probléma önmagában megoldódik. A helyreállítási értesítések nélkül minden riasztás egy nyitott hurkot hoz létre, amely kézi ellenõrzést igényel, amely olyan idõt és figyelmet fogyaszt, amely termelõbb munkára fordítható.

Napi kivonatolt, heti jelentések és a hosszú nézet

A valósidejû riasztások az azonnali problémákat kezelik. A kivonatoltok mindent mást. Egy napi kivonatolt e-mail minden reggel érkezik az elmúlt 24 óra teljes összefoglalójával: az uptime százalékos aránya minden felügyelt végpontnak, az átlagos és csúcsértékû válaszidõk, az előfordult incidens és azok időtartama, valamint az SSL tanúsítvány lejárati státusza az összes HTTPS végpontnak. Ez az e-mail körülbelül 30 másodpercet vesz igénybe, hogy beszkenneljeljen, és azonnali választ ad az "minden egészséges?" kérdésre anélkül, hogy bejelentkezésre lenne szükség az irányítópultra vagy bármilyen kézi ellenõrzésre.

A heti kivonatolt tovább távolabb nagyítottak, feltárva a tendenciákat, amelyek a napi szinten láthatatlanok. Egy olyan szerver, amely fenntartotta a 100% felperési arányt a hét minden napján, de az válaszidõk naponta 50 milliszekundum növekedését mutattak, egy fejlõdõ problémája van, amelyet a napi kivonatolt nem tehetett nyilvánvalóvá, de a heti trend gráf nyilvánvalóvá teszi. Hasonlóan egy olyan szerver, amely két rövid kimaradást tapasztalt a hét különbözõ napjain, felfedezheti a mintát, ha együtt megtekintik: mindkét kimaradás 3 órakor következett be az automatizált biztonsági mentési ablakban, amely azt sugallja, hogy a biztonsági mentési folyamat túl sok erõforrást fogyaszt, és optimálizálásra vagy átütemezésre van szükség. Ezek a minták csak akkor merülnek fel, amikor az adatok idõ alatt összesítõdnek, és a heti kivonatolt ezeknek az elemzéseknek a felszínre hozásához lett kialakítva.

Az incidens történet biztosítja a részletes nyomozati rekordot, amelyet a kivonatoltok összefoglalnak. Minden felismert kimaradás annak kezdeti idejével, végidejével, időtartamával, az érintett ellenõrzésekbõl és az adatokkal van naplózva, amely a hibát jelölte. Ez a történet több célt szolgál. Ez biztosítja az incidens után történõ értékelésekhez és alapvető ok elemzéseihez szükséges adatokat. Ez szerzõdést hoz létre az üzemeltetõket biztosító szolgáltatóknál az SLA megfelelõségérõl. Ez az állapotoldalakon és az ügyféli jelentéseken szükséges felperésidõ statisztikákat hozza létre. És egy hosszú távú rekordot épít fel, amely az infrastruktúra döntéseket tájékoztathatja, mint például egy bizonyos üzemeltetõ szolgáltatót megbízhatóság ígéreteit teljesít-e, vagy egy migráció esedékes-e.

Multi-régió szondák és az egyedüli hely monitorozásának vak foltjai

A szerver tökéletesen elérhető lehet Frankfurtból és teljesen elérhetetlen Tokyóból egyszerre. A hálózati útválasztás nem egységes a globális szinteken. Az internetes szolgáltatók útválasztási döntéseket hoznak, amelyek regionális csatlakoztatási problémákat hozhatnak létre, amely meghatározott földrajzi folyosókat érint, miközben másokat teljesen érintetlenül hagy. A DNS terjedési késések azt jelentik, hogy a szerver migráció teljes és ellenõrzött az egyik kontinensrõl, miközben a másik kontinenst felhasználók még mindig az õs, lehetõleg offline szerverekhez irányíthatók. A CDN rosszul konfigurációja elavult vagy hibás tartalmat kiszolgálhat bizonyos régióknak, miközben más régiók a helyes, naprakész oldalakat kapják.

Az egyedüli helyû monitorozás vak az összes ezeknek a forgatókönyveknek. Ha a monitorozási szonda az ugyanaz az adatközpont régióban helyezik, mint a szerver, akkor 100% felperésidõt fog jelenteni, miközben a globális felhasználói bázis fele az oldalt nem tudja elérni. A multi-régió monitorozás hat földrajzilag elosztott helyekrõl elõírja ezeket az eltéréseket. Ha egy ellenõrzés az egyik régióból meghiúsul, de másokból továbbadódik, a riasztás tartalmazza a földrajzi kontextust, amely azonnal leszûkíti a problémát a regionális útválasztási problémához, nem pedig egy szerver oldali hibához. Ez az eltérés óriási dolog a diagnosztizálásban és a reagálásban: a szerver oldali probléma az olyan szervezetek újraindítása vagy az üzemeltetõ felhívása, amely egy regionális útválasztási probléma a DNS, a CDN konfiguráció vagy az ISP szintû problémák vizsgálatát igényli.

A hat monitorozási helyet az olyan helyekre választották, hogy lefedjenek a nagyobb népesség és forgalom központokat világszerte. Ez azt jelenti, hogy az olyan weboldalak, amelyek az ügyfeleket az Észak-Amerika, Európa és Ázsia között szolgáltatják, szondákkal rendelkeznek vagy ezekben a régiókban vannak, amely valódi lefedettséget biztosít, nem pedig az a monitorozási illúzió, amelyet az egyedüli szonda hoz létre. A vállalatok számára, amelyek a globális elérhetõségtõl függenek, ez a multi-régió megközelítés nem egy választható fejlesztés. Ez az minimális életképes monitorozási konfiguráció, amely pontosan tudja képviselni a geográfiailag elosztott felhasználói bázis tapasztalatát. Az uptime.yeb.to összeépítése a multi-régió képességgel az elején biztosítja, hogy a monitorozás olyan átfogó, mint az az forgalom, amely azt védi.