Monitorozás

A lap 2007. november 26., 23:37-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:

1 Architektúra

Ha adatokat gyűjtünk, az architekturálisan a következő módokon történhet:

1. 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.
   • Új monitorozott gép felvételekor a monitorozó géphez is hozzá kell nyúlni (meg kell neki mondani, hogy újabb gépet pollozzon).
2. A monitorozandó gépek tolják az adatokat egy szerverre.
   • Kitől fogadjon el adatokat a szerver?
     • Kézenfekvőnek látszik valamilyen PKI használata...
   • 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ását 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 elég kevés, és ez jó).

Arra is figyeljünk oda, hogy Ne Monitorozzuk Halálra a Gépet.

• Ha a monitorozás erőforrásigénye egy nagyságrend a hasznos funkciókéval, valamit elrontottunk...

• Időben minél egyenletesebben elosztva monitorozzunk;
  • ha 60000 webszerver reakcióidejét egyszerre próbáljuk megmérni, valószínűleg mást kapunk, mint ha egyenként próbálkoznánk...

1.2 Robusztusság, megbízhatóság, redundancia

Filozófia (nehéz lehet a gyakorlatba átültetni):

• 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. :)
• Megoldás pl.:
  • Van egy redundáns szerver-clusterünk, ami a "megvagyok" típusú heartbeat-üzeneteket fogadja a szolgáltatásoktól;
  • ha valamelyik szolgáltatástól hosszabb ideig nem érkezik szívdobbanás, akkor riaszt.

• Másik 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ó;
  • és még mindig kell valamilyen automatikus rendszer, ami figyeli, hogy megfelelő gyakorisággal jönnek-e ezek a levelek. (3000 gép mailspooljáról érkező értesítések feldolgozása nem embernek való feladat.)
• Jobb a monitorozó szervernek szólni, ha van vagy elfogyott a hely.
  • Ha elfogyott, egy idő után mindenképpen riasztani kell egy embert, viszont
  • 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).

• Annak eldöntése, hogy egy szolgáltatás megy-e, lehetőség szerint a szolgáltatás igénybevételével történjen.
  • Abból, hogy fut apache nevű processz, még nem következik, hogy működik a website...
• Minél absztraktabb a próba, annál könnyebben előfordulhat, hogy
  • akkor is sikeres, amikor a valódi felhasználók számára valójában nem működik a szolgáltatás,
  • vagy fordítva (hibát jelez, pedig a felhasználók nem vennének észre semmit).

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:

• Bizonyos szempontból egyszerűbb a "szerveroldali" megvalósítás:
  • nem kell megvalósítani a pollozást és a vele összefüggő párhuzamosságot/hibakezelést;
  • cserébe viszont fokozottan kell valamilyen biztonsági architektúra a kliensek hitelesítésére.
    • Hiszen azt szeretnénk, hogy a szerverhez ne kelljen nyúlni, ha új klienst állítunk csatarendbe; vagyis IP alapján csak akkor hitelesíthetjük a klienseket, ha minden jelenlegi és jövőbeli ugyanabban a hálózatban van.
• Automatikusan megtudjuk azt is, hogy a monitorozott gép még megy és hálózati kapcsolata is van;
  • ez arra az esetre is igaz, ha a monitorozó gép pollozza a többit, de akkor a mi feladatunk a hibakezelés; nem szabad blokkolódni, ha a "kliens" nem válaszol stb.
• Nem kell "szervert" rakni a monitorozott gépre.
• Ha a monitorozott gép lokálisan is tudja tárolni/pufferelni a monitorozás során kinyert adatokat, akkor hálózatkimaradás vagy a központi monitorozórendszer hibája esetén sem veszítünk adatot.
  • Persze kérdés, mennyire vigasztal minket, hogy ment a webszerver, csak nem látta senki, mert nem volt hálózat...
  • De az azért fontos lehet, hogy részleges hálózatkimaradás esetén is minden a normális kerékvágásban megy tovább, és nem dől össze semmi, aminek nem kéne.

Autonóm megy/nem megy típusú, teljesen testreszabott monitorozás egy lehetséges shellscript-szintű megoldása vázlatosan a következő:

1. Ötpercenként töröljük azokat a jelzőfile-okat, amik akkor jönnek létre, ha a szolgáltatások mennek.
2. 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?".
3. 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.
• Szintén nem akarjuk a végtelenségig növelni a /var kötetet.

• Minden autonóm/automatikus beavatkozást, riasztást rátalimitálni kell
  • pl. exponenciálisan egyre több időt várva a riasztások/beavatkozások között

1.4 Eszkaláció

Gyakori igény:

• ha egy óra után még mindig nem jó, szóljunk a főnöknek is;
• ha 5 webszerver-újraindítás után még mindig nem jó, rebootoljunk;
• stb.