Monitorozás
(v0.1) |
(→Robusztusság, megbízhatóság, redundancia: új példa) |
||
45. sor: | 45. sor: | ||
Ha a monitorozott szolgáltatás meggyőz minket arról, hogy de, megy, akkor ezt higgyük el egy időre - mondjuk öt percre. |
Ha a monitorozott szolgáltatás meggyőz minket arról, hogy de, megy, akkor ezt higgyük el egy időre - mondjuk öt percre. |
||
Utána újabb bizonyíték kell, nem ígéret. :) |
Utána újabb bizonyíték kell, nem ígéret. :) |
||
+ | |||
+ | * Példa: ha a szabad hely mennyiségét monitorozzuk, nem jó ötlet megpróbálni levelet küldeni arról az eseményről, hogy a mailspool könyvtár alól elfogyott a hely. |
||
+ | * Ha mindig arról küldünk levelet, hogy "még van hely", az működő megoldás, csak kicsit pazarló. |
||
+ | * Jobb a monitorozó szervernek szólni, de |
||
+ | * egy idő után mindenképpen riasztani kell egy embert, és |
||
+ | * a monitorozó szerveren is elfogyhat a hely, márpedig hely nélkül esetleg nem tudunk riasztani. |
||
+ | * Elvi megoldás: pl. fenntartunk a riasztások kézbesítéséhez szükséges mennyiségű helyet erre a célra ''(van erre konkrét megvalósítás?)'' |
||
+ | * Gyakorlati megoldás: a monitorozó szerver lemezterületének fogyásáról már olyan hamar riasztást küldünk, hogy a riasztás kézbesítése előtt a lehető legrosszabb esetben se tudjon a hely elfogyni. (Ebből a valóságban kénytelenek leszünk engedni, mert a lehető legrosszabb eset az, hogy nem tudjuk kézbesíteni a riasztást, mert nem működik az a rendszer, amely átvenné...) |
||
Ha kiesik a monitorozásért felelős gép, vagy a monitorozott gép és a monitorozó gép közötti hálózat, a hiba elhárításáig nem gyűlnek az adatok. |
Ha kiesik a monitorozásért felelős gép, vagy a monitorozott gép és a monitorozó gép közötti hálózat, a hiba elhárításáig nem gyűlnek az adatok. |
A lap 2007. augusztus 6., 15:46-kori változata
Kétféle monitorozást szoktunk akarni:
- megy/nem megy
- mennyi?
Az előbbire egy lehetéges megoldás a Nagios, az utóbbira a munin.
Mielőtt ezekbe belemegyünk, nézzünk néhány általános tervezési szempontot:
Tartalomjegyzék |
1 Architektúra
Ha adatokat gyűjtünk, az architekturálisan a következő módokon történhet:
- A monitorozó gép kérdezgeti a monitorozott gépeket.
- Minden monitorozott gép "szerver".
- A lekérdezőgépnek valahogyan hitelesítenie kell magát.
- A monitorozandó gépek tolják az adatokat egy szerverre.
- Kitől fogadjon el adatokat a szerver?
- Milyen és mennyi adatot fogadjon el?
A gyűjtendő adatok körének meghatározása is többféle lehet:
- A monitorozott gép dönti el, milyen adatokat küld.
- Nehéz központilag módosítani sok gépen egyszerre.
- Megbízhatunk a monitorozószerverben, mert nem tudja befolyásolni, mit futtatunk (bár azt esetleg igen, hogy milyen gyakran).
- Ha polling van, akkor a "szervernek" valahogyan meg kell tudnia, milyen adatokat fog kapni vagy mit kell lekérdeznie.
- A lekérdező gép dönti el, mire kíváncsi.
- Könnyű központilag módosítani.
- Nehéz implementálni: a lekérdező gép küldjön kódot, amit futtatni kell? Mitől lesz hordozható? A bizalmi kérdésről nem is szólva.
- Hibrid: pl. SNMP; számos teljesítményadat rendelkezésre áll, ezeket és csak ezeket lehet lekérdezni, de a lekérdező dönti el, mit kérdez le.
- SNMP-vel itt nem foglalkozunk (max. házi feladatként), mert szervereket másképp is lehet monitorozni, az SNMP inkább hálózati dobozokhoz való.
1.1 Skálázhatóság
Ha sok gépet akarunk monitorozni, előnyös, ha a monitorozással kapcsolatos feladatok megoszlanak; minél több feladatot bízzunk magukra a monitorozott gépekre. Nekik ez remélhetőleg csekély többletterhelés, a szerverpark monitorozást végző gépnek viszont nem mindegy, mennyi teendője van egy-egy géppel.
Pl. ha rrdtoolt használunk, az egyes gépek csinálhatják a saját rrd-iket, aztán időnként rsync-kel felmásolhatják a szerverre.
Szintén fontos kérdés, hogy mennyi munka egy új monitorozandó gép beállítása (a munin esetében nagyon kevés, és ez jó).
1.2 Robusztusság, megbízhatóság, redundancia
Főleg megy/nem megy típusú monitorozásnál mindig az legyen az alapfeltevés, hogy nem megy. Ha a monitorozott szolgáltatás meggyőz minket arról, hogy de, megy, akkor ezt higgyük el egy időre - mondjuk öt percre. Utána újabb bizonyíték kell, nem ígéret. :)
* Példa: ha a szabad hely mennyiségét monitorozzuk, nem jó ötlet megpróbálni levelet küldeni arról az eseményről, hogy a mailspool könyvtár alól elfogyott a hely. * Ha mindig arról küldünk levelet, hogy "még van hely", az működő megoldás, csak kicsit pazarló. * Jobb a monitorozó szervernek szólni, de * egy idő után mindenképpen riasztani kell egy embert, és * a monitorozó szerveren is elfogyhat a hely, márpedig hely nélkül esetleg nem tudunk riasztani. * Elvi megoldás: pl. fenntartunk a riasztások kézbesítéséhez szükséges mennyiségű helyet erre a célra (van erre konkrét megvalósítás?) * Gyakorlati megoldás: a monitorozó szerver lemezterületének fogyásáról már olyan hamar riasztást küldünk, hogy a riasztás kézbesítése előtt a lehető legrosszabb esetben se tudjon a hely elfogyni. (Ebből a valóságban kénytelenek leszünk engedni, mert a lehető legrosszabb eset az, hogy nem tudjuk kézbesíteni a riasztást, mert nem működik az a rendszer, amely átvenné...)
Ha kiesik a monitorozásért felelős gép, vagy a monitorozott gép és a monitorozó gép közötti hálózat, a hiba elhárításáig nem gyűlnek az adatok. Ha ez baj, akkor nyilván több gépen is gyűjteni kell az adatokat. Ahol ennek értelme van és megvalósítható, maga a monitorozott gép is monitorozhatja magát (a saját hálózati elérhetőségét mondjuk nehezen tudja monitorozni).
1.3 Autonómia
Hasznos, ha a monitorozott gép maga tolja fel a monitorozó gépre a státuszát, és nem annak kell őt kérdezgetnie. Ennek több előnye van:
- Egyszerűbb a "szerveroldali" megvalósítás.
- Automatikusan megtudjuk azt is, hogy a monitorozott gép még megy és hálózati kapcsolata is van (ez mondjuk arra az esetre is igaz, ha a monitorozó gép pollozza a többit).
- Nem kell "szervert" rakni a monitorozott gépre.
Autonóm megy/nem megy típusú, teljesen testreszabott monitorozás egy lehetséges megoldása vázlatosan a következő:
- Ötpercenként töröljük azokat a jelzőfile-okat, amik akkor jönnek létre, ha a szolgáltatások mennek.
- Van sok kis programunk, ami egy-egy szolgáltatás elérhetőségéről győződik meg, és rendszeresen lefut. Ha a szolgáltatás megy, létrehozza a hozzá tartozó jelzőfile-t. Itt persze nemcsak azt lehet nézni, hogy elérhető-e a webszerver, hanem akár olyasmit is, hogy "igaz-e, hogy még legalább 1G szabad hely van a /var filerendszerben?".
- A következő törlés előtt egy program megnézi, hogy minden teszt sikeres volt-e ebben a periódusban; ha nem, akkor pl. riasztást küld, vagy lefuttathat egy az adott szolgáltatáshoz tartozó vészprogramot (ami mondjuk megpróbálja újraindítani a webszervert, vagy megnövelni a /var-t).
Az autonómiával és a riasztásokkal csak óvatosan: nem akarunk 1000 levelet vagy pláne sms-t kapni, ha valami baj van, és nem akarjuk percenként újraindítani a webszervert, ha elrontottunk valamit a tesztelőprogramban.