A szerver él, de a szolgáltatás mégis halott: miért nem elég az uptime-figyelés?
A zöld állapotjelzés még nem jelenti azt, hogy minden működik
Egy szerverfelügyeleti rendszer legegyszerűbb ellenőrzése azt vizsgálja, hogy maga a gép elérhető-e. Válaszol a pingre, működik az SSH, nyitva van a 80-as vagy a 443-as port, esetleg érkezik HTTP-válasz is. Ezek fontos információk, de önmagukban még nem bizonyítják, hogy az ügyfelek által használt szolgáltatás valóban működik.
Egy webkiszolgáló például tökéletesen válaszolhat a 443-as porton úgy is, hogy az adatbázis már percek óta nem elérhető. A webszerver ilyenkor technikailag él, miközben a látogatók adatbázis-kapcsolati hibát, üres oldalt vagy általános szerverhibát kapnak. Egy egyszerű uptime-monitor ebből akár semmit sem vesz észre.
A port elérhetősége csak a kapcsolat elejét ellenőrzi
Gyakori monitoringmegoldás annak vizsgálata, hogy egy adott TCP-port elérhető-e. Ha a 443-as porton létrejön a kapcsolat, a rendszer zöld állapotot mutat. Ez azonban csak azt bizonyítja, hogy valamilyen szolgáltatás hallgat az adott porton, azt már nem, hogy helyes választ is ad.
Egy weboldal esetében ennél jóval többet érdemes ellenőrizni. Fontos lehet a HTTP-státuszkód, a válaszidő, az SSL/TLS-tanúsítvány érvényessége, egy meghatározott szöveg jelenléte az oldalon vagy akár az is, hogy egy konkrét alkalmazásfunkció működik-e.
Így már nemcsak azt látjuk, hogy van kapcsolat a szerverrel, hanem azt is, hogy a szolgáltatás ténylegesen azt adja vissza, amit a felhasználó elvár.
Az adatbázis hibája mellett a szerver még teljesen egészségesnek tűnhet
A modern webes rendszerek jelentős része több egymásra épülő komponensből áll. A webszerver mellett adatbázis, PHP vagy más alkalmazáskörnyezet, cache, háttérfolyamatok, fájlrendszer és külső szolgáltatások is részt vesznek egyetlen oldal kiszolgálásában.
Ha ezek közül csak egyetlen elem hibázik, a teljes szolgáltatás használhatatlanná válhat. Közben a processzor terhelése normális, a memória nincs elfogyva, a hálózat működik, és maga az operációs rendszer is hibátlanul fut.
Éppen ezért a szerver állapotának figyelése és az alkalmazás működésének figyelése két külön feladat.
A megtelt lemez az egyik klasszikus rejtett hiba
Különösen veszélyes helyzet, amikor a háttértár telik meg. A szerver ilyenkor még hosszú ideig válaszolhat a hálózati ellenőrzésekre, miközben bizonyos szolgáltatások már nem képesek új fájlokat létrehozni, logot írni, adatbázist módosítani vagy levelet fogadni.
Egy weboldal akár még meg is nyílhat, miközben az adminisztrációs felületen már nem lehet adatot menteni. Egy levelezőszerver fogadhat hálózati kapcsolatokat, miközben új levelet már nem tud lemezre írni. Egy mentési folyamat pedig úgy állhat le, hogy maga a mentőszerver továbbra is tökéletesen elérhető.
Ezért az infrastruktúra-felügyeletnek nemcsak azt kell figyelnie, hogy egy gép elérhető-e, hanem a szabad lemezterületet, az inode-használatot, a memóriát, a terhelést és az üzletileg fontos háttérfolyamatokat is.
A HTTP 200 sem mindig jelent valódi sikert
Elsőre logikusnak tűnik, hogy ha egy weboldal HTTP 200 választ ad, akkor minden rendben van. A gyakorlatban azonban sok alkalmazás hibás állapotban is 200-as választ küld.
Előfordulhat például, hogy a teljes oldal helyett egy hibaüzenet jelenik meg, de a HTTP-státuszkód változatlanul 200 marad. Egy egyszerű ellenőrzés ilyenkor zöld állapotot mutathat, miközben az oldal valójában használhatatlan.
A monitoring ezért képes lehet nemcsak a státuszkódot, hanem a válasz tartalmát is vizsgálni. Ellenőrizhető például egy olyan szöveg vagy HTML-elem, amelynek normál működés esetén biztosan szerepelnie kell az oldalon.
Ezzel már sokkal közelebb kerülünk ahhoz, amit a valódi felhasználó tapasztal.
A háttérfolyamatokat külön is figyelni kell
Számos üzleti rendszer működése nem kizárólag a weboldaltól függ. Lehetnek időzített feladatok, adatimportok, számlázási folyamatok, mentések, szinkronizációk, e-mail-küldő folyamatok vagy más háttérben futó szolgáltatások.
Egy ilyen folyamat leállása akár napokig észrevétlen maradhat, miközben maga a weboldal teljesen hibátlanul működik. A problémára sokszor csak akkor derül fény, amikor valaki észreveszi, hogy egy adat nem frissült, nem készült el a mentés vagy nem ment ki egy automatikus értesítés.
A jól kialakított monitoring ezért nemcsak szervereket és portokat ellenőriz, hanem azt is, hogy az üzletileg fontos feladatok valóban lefutottak-e az elvárt időben.
A monitoringnak a felhasználó szemszögéből is gondolkodnia kell
A legfontosabb kérdés végül nem az, hogy a szerver válaszol-e, hanem az, hogy a felhasználó el tudja-e végezni azt, amiért a szolgáltatást használja.
Egy webáruháznál például nem elég a főoldal elérhetőségét ellenőrizni, ha közben a kosár vagy a fizetési folyamat hibás. Egy ügyviteli rendszer esetében nem sokat ér a sikeres bejelentkezési oldal, ha az adatbázis lassúsága miatt utána minden művelet használhatatlan. Egy levelezőrendszer sem tekinthető egészségesnek pusztán azért, mert az IMAP-port nyitva van.
A szolgáltatásmonitoring ezért annál értékesebb, minél közelebb kerül a tényleges üzleti folyamathoz.
Nagios és Zabbix esetén sem az eszköz neve a lényeg
Nagios, Zabbix vagy más monitoringrendszer használatakor könnyű abba a hibába esni, hogy egyre több technikai adatot gyűjtünk, miközben nem határozzuk meg pontosan, melyik riasztás milyen valódi problémát jelez.
A jó monitoring nem attól jó, hogy több száz grafikon áll rendelkezésre. Attól válik igazán hasznossá, hogy egy riasztásból gyorsan kiderül, mi romlott el, mennyire kritikus a probléma, és melyik szolgáltatást érinti.
Az 1B Telecom rendszerüzemeltetési gyakorlatában ezért a szerverek, hálózatok és webes rendszerek felügyeletét nem különálló pontokként érdemes kezelni. A Nagios- és Zabbix-monitoring akkor ad valódi értéket, ha a teljes szolgáltatási láncot látja: a szervert, a hálózatot, a webkiszolgálót, az adatbázist, a háttérfolyamatokat, a mentéseket és a külső elérhetőséget együtt.
A cél nem több riasztás, hanem korábbi és pontosabb hibafelismerés
A túl sok rosszul beállított riasztás ugyanúgy problémát jelenthet, mint a monitoring teljes hiánya. Ha minden apró ingadozás értesítést generál, idővel a valóban fontos jelzések is elvesznek a zajban.
A cél ezért nem az, hogy minden mérhető adatból riasztás legyen. Azokat az állapotokat kell figyelni, amelyek valódi működési kockázatot jelentenek, és olyan küszöbértékeket kell meghatározni, amelyek még időben lehetőséget adnak a beavatkozásra.
Egy jól kialakított monitoringrendszer ideális esetben akkor jelez, amikor a felhasználók még semmit sem érzékelnek a problémából.
Nem azt kell figyelni, hogy él-e a gép, hanem hogy működik-e a szolgáltatás
Az uptime továbbra is fontos mérőszám, de önmagában kevés. Egy infrastruktúra akkor tekinthető valóban működőképesnek, ha nemcsak az egyes gépek érhetők el, hanem az általuk biztosított szolgáltatások is megfelelően működnek.
A valódi felügyelet ezért több rétegű. Figyeli a hardvert és az operációs rendszert, az erőforrásokat, a hálózatot, a szolgáltatásokat, az alkalmazást, a háttérfolyamatokat és ahol szükséges, magát a felhasználói működést is.
Az 1B Telecom rendszerüzemeltetési és monitoring megoldásainál ez a szemlélet a cél: látni a hibát még azelőtt, hogy abból üzleti probléma válna.