Monitorozás

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(Felügyelt csomópontok)
(Felügyeleti protokoll)
165. sor: 165. sor:
 
#Set-request (változókat frissít)
 
#Set-request (változókat frissít)
 
#Inform-request (helyi MIB-t leíró felügyelő-felügyelő üzenet - ezzel felügyelők informálhatják egymást a számontartott változókról)
 
#Inform-request (helyi MIB-t leíró felügyelő-felügyelő üzenet - ezzel felügyelők informálhatják egymást a számontartott változókról)
#SnmpV2-trap (Ügynök-felügyelő csapda jelentés)
+
#SnmpV2-trap
 
#Az ezekre(1-6.) adható válasz
 
#Az ezekre(1-6.) adható válasz
   

A lap 2008. január 3., 17:28-kori változata

Kétféle monitorozást szoktunk akarni:

  1. megy/nem megy
    • Ebből aztán kiszámolható, megvolt-e a sokkilences rendelkezésreállás.
      • Érdekesség: 99% rendelkezésreállás, az évi 87,6 óra (több, mint három nap) állásidő; 99,9% már csak 8,76 óra; 99,99% pedig 52 és fél perc egy évben.
      • A nem hozzáértő már a 99%-tól is hanyattesik, és nem fogja megérteni, miért kerül a 99,9% ötször-, a 99,99% pedig tízszerannyiba.
  2. mennyi?
    • Ebből pedig lehet szép menedzserbarát grafikonokat rajzolni, és rögtön látszik, hogy Kell A Nagyobb Vas.
    • Persze az is látszhat, mi a szűk keresztmetszet, vagy hogy Valami Elszabadult, és nem ártana ránézni.
      • Kaphatunk riasztást a küszöbérték fölötti/alatti értékekről.
        • A kérdés azért ennél bonyolultabban is kezelhető: idősorok, trendek, szezonalitás... Komolyabb rendszerben már így kell.

Az előbbire egy lehetéges megoldás a Nagios, az utóbbira a munin és a cacti (házi feladat). A Zabbix valahol a kettő között van, egy kicsit mindkettőt tudja (és lehetséges házi feladat).

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:

  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.
    • Esetleg magukon a monitorozott gépeken.
    • => 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

2 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.

3 SNMP

3.1 Az SNMP(Simple Network Management Protocol) modell alkotóelemei

3.1.1 Felügyeleti állomások(Management Stations)

  • A hálózat felügyelete ezeken az állomásokon történik, egy ezeken futó folyamat által, amely az általa felügyelt csomópontokkal kommunikál
    • (a kommunikáció igazából nem a felügyelt csomópontokkal tartja a kapcsolatot, hanem a csomópontokon futó "ügynökökkel" lásd következő pont)
  • Hogy az állomás kommunikálni tudjon a csomópontokkal, az itt tárolt információk formátumát meg kell határozni.
  • Az SNMP ezen kívül azt is előírja, hogy milyen információkat kell az adott felügyelt csomópontnak megjegyeznie.

3.1.2 Felügyelt csomópontok

  • Olyan készülékek, amik képesek a külvilág számára (Felügyeleti Állomásoknak) állapotinformációkat küldeni.
  • Ha egy ilyen csomópontot SNMP-vel szeretnénk felügyelni, egy SNMP ügynököt (akár felügyeleti folyamatoknak is nevezhetjük ezeket a programokat) kell rajta futtatnunk.
    Az ügynököket meglehetősen egyszerűre tervezik, hogy ne jelentsenek megterhelést a futtató készüléknek.
  • A modell feltételezi, hogy ezek a csomópontok képesek egy ügynök futtatására.
    • Ha olyan csomópontot is meg akarunk figyelni, amik erre képtelenek, akkor úgynevezett helyettesítő ügynököt (proxi agent) kell alkalmaznunk.
    • Egy helyettesítő ügynök álalában több nem SNMP kompatibilis csomópontot figyel, és helyettük nyilatkozik a felügyeleti állomásnak.

3.1.3 Felügyeleti információ

  • Ha egy ügynök észleli, hogy valamilyen esemény történt (és a felügyeleti állomás előírja neki, hogy az adott eseményt megfigyelje) azonnal jelenti azt a konfigurációs listájában bejegyzett felügyeleti állomás(ok)nak.
  • A jelentési formát SNMP csapdának nevezik.
    Ez csak arról informálja a felügyeleti állomást, hogy esemény történt, és a felügyeleti állomás feladata kideríteni a pontos részleteket.
    Ez az ügynökök egyszerűbb felépítése miatt alakult ki, mivel nem tudnak nyugtázni és így nem megbízható a kommunikáció.
  • A felügyeleti információhoz a hitelesítés is hozzátartozik, mivel a felügyeleti állomások sok információt megtudhatnak a felügyeleti állomásokról, és a működésüket is befolyásolhatják.
    Az SNMPv1-ben a felügyeleti állomás úgy hitelesíti magát a csomópontok előtt, hogy minden üzenetébe egy jelszót kódol.
    • Ezt a nem túl megbízható megoldást megpróbálták feljavítani a v2-ben, de széles körben bonyolultsága miatt nem terjedt el.

3.1.4 Felügyeleti protokoll

  • Általában a felügyeleti állomás kérdést, vagy kérést intéz egy ügynökhöz.
    • A kérdés a csomópont által birtokolt, valamilyen állapotváltzóra vonatkozik,
    • a kérés pedig egy állapotvátozó frissítésére.
  • Az SNMP hét üzenettipust definiál:Az első hat üzenettípus a kezdeményezőáltal küldött
  1. Get-request (változók értékét kérdezi le)
  2. Get-next-request (az ezt követő változó értékére kiváncsi)
  3. Get-bulk-request (egy táblázatot kérdez le)
  4. Set-request (változókat frissít)
  5. Inform-request (helyi MIB-t leíró felügyelő-felügyelő üzenet - ezzel felügyelők informálhatják egymást a számontartott változókról)
  6. SnmpV2-trap
  7. Az ezekre(1-6.) adható válasz

Snmp.gif

3.2 SMI (Structure of Management Information - felügyeleti adatok struktúrája)

  • Az ASN-nek (lásd lent) egy bővített része, ami az SNMP adatszerkezetek leírását szolgálja.
  • Az válozókat egyéni objektumokként határozták meg.
  • Az objektumokat csoportokba lehet sorolni, ha valamilyen hasonlóságot mutatnak (például UDP csoport).
  • A csoportokat modulokba lehet rendezni.
    Nyilván az objektum az SNMP legalsó szintjén helyezkedik el, a csoport és a modul pedig egyel-egyel följebb.
  • Meghívásuk:
  1. Minden modul meghívása a MODULE-IDENTITY makró meghívással kezdődik,
  2. ezt követi az OBJECT-IDENTIFIER,
  3. majd az OBJECT-TYPE meghívás.
  • Az első az implementáció nevét (és még néhány adatot), a második a modul nevét, a harmadik a változók nevét és tulajdonságait adja meg.
  • OBJECT-TYPE
    • Négy kötelező paramétere van
  1. SYNTAX (megadja a változó típusát),
  2. MAX-ACCESS (a váltzón végrehajtható műveleteket határozza meg, például olvasható, vagy írható is),
  3. STATUS (a változó aktualitásáról ad információt, értékei lehetnek: érvényes, kifogásolható és elavult),
  4. DESCRIPTION (egy rövid leírás a változó értelmezéséről)
  • Példa az OBJECT-TYPE-ra (rfc1213-ban keresgélve)
sysObjectID OBJECT-TYPE
             SYNTAX  OBJECT IDENTIFIER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The vendor's authoritative identification of the
                     network management subsystem contained in the
                     entity.  This value is allocated within the SMI
                     enterprises subtree (1.3.6.1.4.1) and provides an
                     easy and unambiguous means for determining `what
                     kind of box' is being managed.  For example, if
                     vendor `Flintstones, Inc.' was assigned the
                     subtree 1.3.6.1.4.1.4242, it could assign the
                     identifier 1.3.6.1.4.1.4242.1.1 to its `Fred
                     Router'."
             ::= { system 2 }

3.3 ASN.1 (Abstract Syntax Notation One - absztrakt szintaxis jelölés)

  • Az ASN.1 adatszerkezetek definícióját adja meg (ez egy primitív adatdeklarációs nyelv).
  • Az SNMP adatszerkezeteinek alapját képezi.
    Az ASN bővített változatát, az SMI-t használják (lásd fent).
  • Az ASN.1 által használt beépített adattípusok (nagybetűsök)
  1. INTEGER(egész szám-bármilyen egész lehet, de az SNMP szabályrendszere ezt korlátozza),
  2. BIT STRING(bitfüzér),
  3. OCTET STRING(előjel nélküli bitfüzér),
  4. NULL(helyfoglaló),
  5. OBJECT IDENTIFER(az objektumra való hivatkozást teszi lehetővé)
  • OBJECT IDENTIFER
    • definiálja az SNMP által felügyelt változók gyűjteményét,
    nemcsak ebben (mármint at SNMP-ben) definiál egy objektumot, hanem minden hivatalos szabványban.
  • Ezt a leírót egy faként szokták ábrázolni, melynek legfelsőbb szintje a szabványokkal foglakozó szervezeteket tartalmazza.
  • Egy SNMP MIB objektum a csomópontok felsorolásával írható le. Pédául: {1 3 6 1 2 1 11 ...}
    Ezzel bármilyen szabvánnyal leírt objektum definiálható.

Mib struct.gif

Gellén Áron (BME-VIK)

Személyes eszközök