Apró HTTPS hibák komoly üzleti következményekkel
HTTPS monitoring: miért lehet pár perces kiesésből komoly üzleti probléma?
Egy weboldal vagy online szolgáltatás üzemeltetésénél könnyű abba a hibába esni, hogy az elérhetőséget csak akkor tekintjük problémának, ha az oldal hosszabb időre teljesen leáll. A valóságban azonban már néhány perces, időszakosan jelentkező HTTPS-kiesés is komoly következményekkel járhat.
Különösen kellemetlenek azok a hibák, amelyek mire valaki manuálisan megnyitja az oldalt, már megszűntek. Ilyenkor kívülről minden rendben lévőnek tűnik, miközben a háttérben néhány perccel korábban valódi szolgáltatáskiesés történt.
Pontosan ezért van szükség folyamatos szerver- és szolgáltatásmonitoringra.
Attól, hogy most működik, még lehetett hiba
Egy tipikus eset úgy kezdődik, hogy a monitoring rendszer HTTPS hibát jelez. Az üzemeltető néhány perccel később megnyitja a weboldalt, amely azonnal betöltődik.
Első ránézésre könnyű azt gondolni, hogy téves riasztás történt.
Pedig egy megfelelően beállított monitoring rendszer nem azt vizsgálja, hogy az oldal „általában működik-e”, hanem meghatározott időközönként tényleges HTTPS-kérést indít. Ha egy ilyen kérés nem kap időben választ, a rendszer ezt eseményként rögzíti.
Ha például három egymást követő ellenőrzés is időtúllépéssel végződik, miközben néhány perccel később már ismét 200 OK választ kapunk, akkor jó eséllyel nem a monitoring tévedett. Egyszerűen egy rövid ideig fennálló hibát sikerült elkapnia.
Ez az egyik legfontosabb különbség a kézi ellenőrzés és az automatikus monitoring között.
Mit jelent a Socket timeout?
HTTPS ellenőrzésnél gyakran találkozhatunk a Socket timeout üzenettel.
Ez önmagában még nem mondja meg pontosan, hogy hol volt a probléma. Azt jelenti, hogy a monitoring rendszer meghatározott időn belül nem tudta sikeresen végrehajtani a hálózati kommunikációt.
Ennek számos oka lehet.
Előfordulhat pillanatnyi hálózati probléma, csomagvesztés, túlterhelt webszerver, elfogyó worker folyamat, hibás tűzfalszabály, túlterhelt reverse proxy vagy akár az is, hogy maga a gép ugyan elérhető, de a 443-as porton futó szolgáltatás átmenetileg nem képes megfelelően válaszolni.
Ezért önmagában egyetlen timeout még nem feltétlenül jelent komoly incidenst. Több egymást követő sikertelen mérés azonban már egészen más helyzet.
Miért nem riasztunk az első hibánál?
Egy jól konfigurált Nagios vagy Zabbix rendszer általában nem küld azonnal riasztást minden egyes sikertelen lekérdezés után.
Ennek egyszerű oka van: az interneten időnként előfordulhatnak rövid, egyetlen mérés erejéig tartó zavarok.
Nagios környezetben ezért találkozunk például a SOFT és HARD állapotok fogalmával.
Az első sikertelen ellenőrzés még lehet SOFT CRITICAL. A rendszer néhány percen belül újra megvizsgálja a szolgáltatást. Ha a második ellenőrzés is sikertelen, továbbra is problémás állapotot látunk, de még mindig történhet újrapróbálkozás.
Amennyiben az előre meghatározott számú ellenőrzés egymás után hibával végződik, a szolgáltatás HARD CRITICAL állapotba kerül.
Ekkor már indokolt lehet az e-mailes, Telegram vagy más riasztás kiküldése.
Így egyszerre kerülhető el a felesleges riasztási zaj és az, hogy egy tényleges kiesés észrevétlen maradjon.
A HTTP 200 OK önmagában még nem minden
Egy HTTPS monitorozás természetesen vizsgálhatja azt, hogy a szerver visszaadja-e a 200 OK választ.
Ez azonban csak az egyik szint.
Egy komolyabb ellenőrzés figyelembe veheti a HTTPS kapcsolat létrejöttét, az SSL/TLS működését, a domainnevet, az SNI kezelését, a válaszidőt, az átirányításokat és akár az oldal tartalmát is.
Az SNI különösen fontos több weboldalt kiszolgáló szervereknél.
Egyetlen IP-cím mögött több HTTPS weboldal is működhet, ezért a webszervernek tudnia kell, hogy a kliens pontosan melyik domainhez szeretne kapcsolódni. Ha a monitoring ellenőrzés nincs megfelelően konfigurálva SNI használatára, akkor teljesen más virtuális hostot vagy hibás választ kaphat.
Ezért monitoring rendszer kialakításakor nem elegendő annyit ellenőrizni, hogy a 443-as TCP port nyitva van.
Azt kell ellenőrizni, amit a valódi látogató is használ.
Nem mindegy, hogy csak egy oldal vagy az egész infrastruktúra hibázik
Egy riasztás kivizsgálásánál az egyik első kérdés az, hogy ugyanabban az időszakban más szolgáltatásoknál is történt-e hiba.
Ha egyszerre tíz vagy húsz, egymástól független szerver HTTPS ellenőrzése is timeoutol, akkor felmerülhet a monitoring szerver hálózati problémája, egy közös szolgáltatói hiba vagy valamilyen routing probléma.
Ha azonban ugyanabban az időpontban csak egyetlen szerver egyetlen szolgáltatása mutat hibát, miközben minden más ellenőrzés rendben működik, akkor sokkal valószínűbb, hogy a problémát az érintett szerveren vagy annak hálózati útvonalán kell keresni.
Ezért különösen értékes a monitoring rendszerek eseménynaplója.
Nemcsak azt mutatja meg, hogy mi hibázott, hanem azt is, hogy mi nem hibázott.
Az időbélyegek nélkül csak találgatnánk
Egy néhány perces kiesést gyakran már lehetetlen rekonstruálni akkor, amikor az üzemeltető később belép a szerverre.
A processzor terhelése addigra visszaállhat normális értékre. A webszerver ismét válaszol. A memóriahasználat megfelelő. A hálózat működik.
A monitoring naplója viszont pontosan megmondhatja, hogy mikor kezdődött a probléma, hány ellenőrzés bukott el, mikor vált HARD állapotúvá, mikor történt a riasztás és mikor állt helyre a szolgáltatás.
Ezeket az időpontokat már össze lehet vetni más naplókkal.
Megnézhetjük ugyanazt az időszakot a webszerver access és error logjaiban, a systemd naplókban, a kernel események között, a tűzfal naplójában vagy akár a hálózati eszközök logjaiban.
Így egy egyszerű „nem működött az oldal” jelzésből már valódi incidensvizsgálat lesz.
Miért veszélyes a néhány perces kiesés?
Egy kisebb céges bemutatkozó oldal esetében néhány perc elsőre jelentéktelennek tűnhet.
Egy webáruháznál, foglalási rendszernél, ügyfélportálnál vagy API-nál azonban már egészen más a helyzet.
A látogató nem tudja, hogy az oldal öt perc múlva újra működni fog. Ő csak azt látja, hogy most nem érhető el.
Bezárja az oldalt, máshol vásárol, nem küldi el az ajánlatkérést vagy sikertelennek lát egy tranzakciót.
Automatizált rendszereknél még ennél is komolyabb probléma keletkezhet. Egy API-kérés sikertelensége további folyamatokat állíthat meg, külső rendszerekkel történő szinkronizáció maradhat el, vagy hibás állapot alakulhat ki két rendszer között.
Ezért az üzleti szempontból fontos szolgáltatásoknál nem csak a többórás leállás számít kiesésnek.
A monitoring feladata nem csak a riasztás
A monitoringot sokan egyszerű riasztórendszerként képzelik el.
Pedig ennél jóval többre használható.
Egy megfelelő Nagios vagy Zabbix rendszer hosszabb időn keresztül képet adhat a szerverek és szolgáltatások állapotáról. Megfigyelhető a processzorterhelés, memóriahasználat, tárhely, hálózat, szolgáltatások működése, HTTPS elérhetőség, tanúsítványok lejárata és számos más paraméter.
A cél nem az, hogy minél több értesítést kapjunk.
Éppen ellenkezőleg.
A jó monitoring csak akkor szól, amikor annak valóban jelentősége van, viszont ilyenkor elegendő információt biztosít ahhoz, hogy az üzemeltető gyorsan elkezdhesse a hiba behatárolását.
A pár perces hibákat is érdemes kivizsgálni
Ha egy szolgáltatás három egymást követő ellenőrzésen timeoutol, majd néhány perccel később ismét hibátlanul működik, attól az esemény még nem válik érdektelenné.
Lehet egyszeri hálózati zavar.
Lehet túlterhelés első jele.
Lehet egy rosszul viselkedő szolgáltatás.
Lehet olyan probléma is, amely később egyre gyakrabban jelentkezik majd.
Az ilyen eseményeket ezért érdemes megőrizni és visszanézni. Ha ugyanaz a szerver egy héten belül többször produkál hasonló rövid HTTPS timeoutot, már kirajzolódhat egy olyan tendencia, amelyet manuális ellenőrzéssel szinte lehetetlen lenne észrevenni.
A szerverüzemeltetésben sokszor nem az a legfontosabb kérdés, hogy egy weboldal ebben a pillanatban működik-e.
Hanem az, hogy megbízhatóan működik-e akkor is, amikor éppen senki nem nézi.