Monitorozás
(→SMI (Structure of Management Information - felügyeleti adatok struktúrája)) |
(→Felügyeleti protokoll) |
||
168. sor: | 168. sor: | ||
[[Kép:Snmp.gif]] |
[[Kép:Snmp.gif]] |
||
+ | |||
+ | ====SNMP verziók==== |
||
+ | *Mivel a felügyeleti állomásnak lehetősége van arra, hogy a felügyelt csomópontokról adatokat gyűjtsön, sőt le is képes őket állítani, fontos a hitelességvizsgálat. Az SNMP-nek jelenleg három verziója létezik. |
||
+ | **SNMPv1: Az SNMP első implementációja. Ebben a megvalósításban a felügyeleti állomás azzal bizonyítja kilétét, hogy minden üzenetbe behelyez egy kódolatlan "jelszót" (community name). Ez a megoldás nem bizonyult túl megbízhatónak autentikáció szempontjából, ezért ezt tovább kellett fejleszteni. A "megbízhatatlansága" ellenére még mindig ez a legjobban elterjedt változat. |
||
+ | **SNMPv2: Ebben a verzióban már használnak kódolást. Az egész csomag kódolt formában érkezik, kivéve a célcímet. A kódolt csomagban benne van maga a közlendő információ, a jelszó (common name), és a forrás címe. Az ügynökök kikódolják az üzenetetet, a cím illetve a jelszó alapján azonosítják a feladót és végrehajtják (vagy sikertelen azonosítás esetén nem hajtják végre) a kapott utasítást. |
||
+ | ***Az SNMPv2 DES (Data Encryption Standard) kódolást használ a titkosításhoz. |
||
+ | **SNMPv3: A jelenleg legbiztonságosabb SNMP verzió. Az SNMP környezeti azonosítóját (Context Engine ID) használja fel a kódoláshoz. (Definiálunk egy kontextust, ehhez hozzárendeljük az objektumokat. Ebből következően minden objektum meghatározza melyik kontextushoz tartozik.) |
||
+ | Ebben a verzióban három biztonsági szintet lehet megkülönböztetni: |
||
+ | 1. hitelesítés és titkosítás |
||
+ | 2. hitelesítés, titkosítás nélkül |
||
+ | 3. hitelesítés és titkosítás nélkül |
||
===SMI (Structure of Management Information - felügyeleti adatok struktúrája)=== |
===SMI (Structure of Management Information - felügyeleti adatok struktúrája)=== |
A lap 2008. január 3., 20:36-kori változata
Kétféle monitorozást szoktunk akarni:
- 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.
- Ebből aztán kiszámolható, megvolt-e a sokkilences rendelkezésreállás.
- 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.
- Kaphatunk riasztást a küszöbérték fölötti/alatti értékekről.
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:
- 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).
- 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?
- Kitől fogadjon el adatokat a szerver?
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ő:
- Ö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.
- 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. Az ügynökököket egyszerű felépítésük nem teszi alkalmassá a teljes jelentés elküldésére.
- 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ó átírása.
- Az SNMP hét üzenettipust definiál: Az első hat üzenettípus a kezdeményező által küldött
- Get-request (változók értékét kérdezi le)
- Get-next-request (az ezt követő változó értékére kíváncsi)
- Get-bulk-request (egy táblázatot kérdez le)
- 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)
- SnmpV2-trap
- Az ezekre(1-6.) adható válasz
3.1.5 SNMP verziók
- Mivel a felügyeleti állomásnak lehetősége van arra, hogy a felügyelt csomópontokról adatokat gyűjtsön, sőt le is képes őket állítani, fontos a hitelességvizsgálat. Az SNMP-nek jelenleg három verziója létezik.
- SNMPv1: Az SNMP első implementációja. Ebben a megvalósításban a felügyeleti állomás azzal bizonyítja kilétét, hogy minden üzenetbe behelyez egy kódolatlan "jelszót" (community name). Ez a megoldás nem bizonyult túl megbízhatónak autentikáció szempontjából, ezért ezt tovább kellett fejleszteni. A "megbízhatatlansága" ellenére még mindig ez a legjobban elterjedt változat.
- SNMPv2: Ebben a verzióban már használnak kódolást. Az egész csomag kódolt formában érkezik, kivéve a célcímet. A kódolt csomagban benne van maga a közlendő információ, a jelszó (common name), és a forrás címe. Az ügynökök kikódolják az üzenetetet, a cím illetve a jelszó alapján azonosítják a feladót és végrehajtják (vagy sikertelen azonosítás esetén nem hajtják végre) a kapott utasítást.
- Az SNMPv2 DES (Data Encryption Standard) kódolást használ a titkosításhoz.
- SNMPv3: A jelenleg legbiztonságosabb SNMP verzió. Az SNMP környezeti azonosítóját (Context Engine ID) használja fel a kódoláshoz. (Definiálunk egy kontextust, ehhez hozzárendeljük az objektumokat. Ebből következően minden objektum meghatározza melyik kontextushoz tartozik.)
Ebben a verzióban három biztonsági szintet lehet megkülönböztetni: 1. hitelesítés és titkosítás 2. hitelesítés, titkosítás nélkül 3. hitelesítés és titkosítás nélkül
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.
- felépítése hierarchikus:
- objektumok
- csoportok
- modulok
- Az objektumokat csoportokba lehet sorolni, ha valamilyen hasonlóságot mutatnak (például UDP-, TCP csoport) és a csoportokat modulokba lehet rendezni.
- Egy nagyobb router támogathatja az UDP- és a TCP csoportot is, egy kisebb routernek ezt nem feltétlenül kell tudnia. A cél az, hogyha egy eszköz egy csoportot támogat, akkor a csoportban lévő összes objektumot támogassa. A modulra ezt a követelényt már nehéz lenne előírni, ugyanis nem biztos, hogy egy készülékben minden csoport megvalósítható.
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)
- INTEGER(egész szám-bármilyen egész lehet, de az SNMP szabályrendszere ezt korlátozza),
- BIT STRING(bitfüzér),
- OCTET STRING(előjel nélküli bitfüzér),
- NULL(helyfoglaló),
- 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ó.
Gellén Áron (BME-VIK)