Mi a Nagios?
A Nagios az egyik legelterjedtebb informatikai infrastruktúra monitorozó alkalmazás. Mivel szélesebb körben használják, mint a hozzá hasonló megoldásokat (Zabbix, Groundwork, Zenoss, Icinga, Hyperic, OpenNMS, stb), ezért a fejlesztése sem áll meg. Széles körű felhasználásának köszönhetően az általános igényekre már van kész megoldás, nem jellemző, hogy kiegészítéseket kelljen készíteni hozzá.
A feladata egyszerűen megfogalmazva az, hogy a beállított szolgáltatásokat ellenőrizze, az ellenőrzés során az adott szolgáltatás ellenőrizni kívánt jellemzőjét számszerűsíteni kell és a kapott értéket a megadott szintekhez viszonyítva megkapjuk a szolgáltatás aktuális állapotát.
Ha az ellenőrizett jellemző értéke eltér a megadott szintektől, akkor a beállított feladatot végzi. Ez a feladat lehet értesítés küldése a megfelelő személynek vagy egy program futtatása.
A Nagios két részből áll. Az alsó réteg a Nagios Core, amely a konfiguráció alapján az ellenőrzéseket, értesítéseket, log fájl készítést és rotálást végzi. Ennek működéséhez egy Linux vagy Unix operációs rendszerre van szükség.
A Nagios Core- hoz tartoznak cgi szkriptek, amelyek a webes felület működtetéséért felelősek, ez a második szintje a programnak. Ezek a szkriptek generálják a weboldalakat, ahol az aktuális állapot és az eddigi események követhetők, továbbá ellenőrzések futtathatók. A webes megjelenítéshez az ajánlott webszerver az Apache, de nginx és lighthttpd webszerverrel is működésre bírható.
A webes megjelenítést a Nagios Core-hoz „kapott” felülettől függetlenül más megjelenítők is elláthatják. Az exchange.nagios.org weboldalon több megjelenítő közül választhatunk.
A Nagios Windows-on való futtatására a Nagwin ad lehetőséget, amely a NagiosCore mellett webszervert és egyéb a program futtatásához szükséges kiegészítőket tartalmaz.
Mért van rá szükség?
Azért van létjogosultsága egy ilyen szoftvernek, mert több száz, több ezer gép több tízezer jellemzőjét tudja rendszeres időközönként figyelni. Ezt más módon is meg lehet oldani. Lehetőség van arra, hogy egy arra kijelölt személy ezen szolgáltatásokat az adott gépre bejelentkezve kézzel ellenőrizze, meg lehet oldani, hogy a gép önállóan futtasson saját magán ellenőrzéseket és valamilyen úton jelezze, ha rendellenességet talál. Ezek a megoldások is működnek, de kevésbé hatékonyak, mint az automatizált, előre beállított limit értékekkel futtatott ellenőrzések.
Működési elv
A Nagios felépítése nem túl egyszerű, így eleinte nehéz megérteni a működését, ugyanakkor logikus és kellően rugalmas, hogy a felmerülő igényeket teljesíteni tudja. Működését tekintve a központban a Nagios processz áll. Körülötte a host- ok, ezek olyan, számítógép hálózatra kapcsolt gépek, amelyekhez szolgáltatásokat (service) lehet hozzárendelni. A hostokat célszerű a valós hálózati topológia alapján elrendezni. Ha a valós topológiát követjük a beállításoknál akkor probléma esetén annak okának feltárása és elhárítása is gyorsabb lehet. Például ha egy router megy tönkre, amire több más gép kapcsolódik és a Nagios is ennek megfelelően lett beállítva, akkor ha a hálózati eszköz elérhetetlenné válik, akkor a rá kapcsolt további gépek és azok szolgáltatásai is elérhetetlen (Unreachable) állapotba kerülnek. Így hálózati térképet megnézve rögtön látható, hogy nem a kiszolgálókkal és azok szolgáltatásaival van probléma, hanem a hálózati struktúrában előttük álló eszközzel.
Erre ad lehetőséget, a parent host beállítás, amivel megadható, hogy melyik gép a hálózatban milyen más eszköztől függ.
A szolgáltatások host- hoz vannak rendelve, a host- ok nem csak számítógépek, vagy szerverek lehetnek, hanem szinte bármi, ami IP kommunikációra képes – hálózati nyomtatótól szünetmentes tápegységig.
A szolgáltatások hozzárendelése némely esetben magától értetődő (levelező szerver esetén levelező szolgáltatások figyelése), más esetekben logikai hozzárendelés. (Pl.: annak ellenére, hogy egy webszerver SSL kulcsának lejárati idejét figyeljük, az ellenőrzést nem kötelező a levelező szerverről futtatni.)
A szolgáltatások sem feltétlenül egy kiszolgáló egy bizonyos hálózati szolgáltatását foglalják magukban. Bármi lehet Nagios service, ami számokkal kifejezhető, akár az elmúlt 5 percben a szerverszoba hőmérsékletének változása. Service tehát lehet valamilyen szoftveres állapotváltozás, vagy valamilyen fizikai, a hardvert érintő változás.
A szolgáltatások ellenőrzését plugin-ok végzik. A Nagios mellé az általánosan felhasznált plugin-ok települnek, de speciális ellenőrzésekhez a Nagios társoldalain fellelhetők jól megírt és dokumentált kiegészítések.
Szükség esetén saját plugin is készíthető, mivel a plugin- nal szembeni követelmények elérhetők a Nagios weboldalán.
Állapotok
A host- ok és a service- k az ellenőrzések eredményeként különböző állapotokat vehetnek fel. Gépek esetén a lehetőségek Up, Down, Unreackable. Az első kettő egyértelmű, a harmadik pedig a fenti példánál maradva, akkor következik be, ha a parent host sem elérhető.
Szolgáltatások tekintetében hasonló a helyzet. Állapotukat tekintve a szolgáltatások OK, Warning, Critical és Unknown állapotban lehetnek. Az ismeretlen állapotot akkor veszik fel a szolgáltatások, amikor valami okból kifolyólag az ellenőrző programok a Nagios számára nem értelmezhető értéket adnak vissza.
Minden szolgáltatáshoz beállíthatók különböző paraméterek. A legfontosabb opciók azok, amelyek meghatározzák az adott szolgáltatás aktuális állapotát. Ezeket Warning és Critical limit-nek is nevezik.
Beállítások
Szolgáltatás opciók
További beállítások megadásával lehet szabályozni, hogy milyen időszakban (check period) (Pl. 00:00 és 1:00 között) ellenőrizze az adott szolgáltatást, továbbá a megadott időszakban milyen rendszerességgel (check interval). Abban az esetben, ha a Nagios az ellenőrzés során azt tapasztalja, hogy annak állapota az előzőhöz képest változik (Pl. Valamilyen adatbázisban az aktuálisan futó lekérdezések száma 10-ről 50-re emelkedett), akkor a beállított értékek alapján bizonyos idő elteltével (retry interval) újra ellenőrzi azt a megadott alkalommal (max check attempts). Ha az összes ellenőrzés alkalmával eltérést tapasztal, akkor változtatja a szolgáltatás állapotát. Ez a működés igaz a szolgáltatás „elromlása” és „helyreállása” esetén is.
További beállítások is rendelhetők még egy szolgáltatáshoz, amik az értesítésekkel kapcsolatosak. A szolgáltatás ellenőrzésének időszakától függetlenül lehet beállítani az értesítés időszakát (notification period). Az sem mindegy, hogy kiknek és milyen formában küld értesítést. Ezt a Contactgroup szolgáltatáshoz való rendelésével lehet beállítani. Arra külön figyelmet kell szentelni, hogy milyen állapotokról küldjön értesítést. Egy körültekintően kialakított rendszernél érdemes különválasztani a Warning állapotot a Critical- tól. Például ügyeleti időben elég a felelőst a kritikus állapotról tájékoztatni, amely azonnali beavatkozást igényel, míg a figyelmeztetési szint (warning) olyan állapotot feltételez, amely mellett a szolgáltatás működése nem igényel azonnali beavatkozást. Ilyen eseteknél szükségtelen a szolgáltatás OK állapotról tájékoztatni a felelős személyt, hiszen ő maga tesz intézkedéseket, hogy ezt elérje.
A fent említett ellenőrzési és figyelmeztetési időszakokat Timeperiods néven illeti a szakirodalom. A Timeperiods lehetőségnél megadott időszakok közül lehet választani. Itt heti bontásban lehet megadni időszakokat, egy napra akár többet is.
Contactgroup
A fent említett Contactgroup nagy segítség abban, hogy a megfelelő értesítés a megfelelő személynek jusson el. Szolgáltatáshoz és géphez Contactgroup- ot célszerű hozzárendelni, Contact -ot (kapcsolattartó személyt) közvetlenül nem. Még egy személyt tartalmazó csoportot is célszerű létrehozni, így ha személyi változás történik, akkor a megfelelő személyt a megfelelő csoportba kell elhelyezni, nem kell semmi mást állítani. Egy szolgáltatáshoz vagy géphez több Contactgroup is megadható, továbbá igaz, hogy egy személy több Contactgroup tagja is lehet.
Contacts
Személyenként meg lehet adni, hogy az illetőt milyen, az egész gépet érintő változásról milyen időszakban és milyen módon tájékoztassa a Nagios, ehhez hasonlóan megadható, hogy milyen szolgáltatást állapotváltozásról milyen módon és milyen időszakban adjon jelentést.
Természetesen a felhasználó nevét, email címét és szükség esetén telefonszámát is meg lehet adni.
Meg lehet választani, hogy milyen értesítést küldjön a rendszer. Alapértelmezetten email útján kap jelentést a felhasználó, de igény esetén sms értesítés is beállítható. Ugyan értesítésnek hívják, de beállítható, hogy probléma esetén milyen programot, milyen paraméterekkel futtassa. Beállítható, hogy az állapot változásokról log fájlt készítsen, vagy akár egy programot indítson, argumentumként a gép IP címével vagy gépnevével.
Konfigurációs megoldások
Látható, hogy a Nagios konfigurálása elégé összetett is lehet. A beállításokat fájlokban tárolja és a megadott formázási feltételeknek meg kell felelniük. A könnyebb és átláthatóbb Nagios konfiguráció készítésére sorra készülnek a karakteres és webes felületek. Jó tapasztalataim vannak az Nconf nevű eszközzel, ami egy webes felület, amely adatbázisban tárolja a beállításokat és igény esetén a Nagios számára értelmezhető konfigurációt generál. A logikáját megértve nagyon megkönnyíti a beállítások módosítását, továbbá lehetőséget ad egy kiválasztott gép minden beállításának klónozására, így nagyon gyorsan bővíthető a Nagios- szal felügyelt hálózat.
Nconf
Az Nconf egy webes felületű, PHP-ban íródott alkalmazás. Működéséhez PHP Perl és MySQL szükséges. Linux operációs rendszerre való telepítése ajánlott, de feltehetőleg a szükséges programok telepítését követően Microsoft szoftvereken is használható.
A gyors működés érdekében a felületen található beállítások adatbázisban vannak eltárolva, viszont a Nagios számára a konfigurációt fájlokban adja át, mivel a Nagios csak fájlokból tudja kiolvasni a konfigurációját. Az aktuális állapotot is egyetlen fájlban írja le a Nagios. Ennek köszönhető, hogy a sajátján kívül más webes felület hozzáillesztése is viszonylag egyszerű.
Adatforrások
Közvetlen port ellenőrzés
Attól függően, hogy milyen szolgáltatást szeretnénk ellenőrizni, meg kell választani a legmegfelelőbb módot arra, hogy az ellenőrzést futtassuk. A legegyszerűbb eset, amikor a Nagios-t futtató számítógép egy alhálózatban van az ellenőrizni kívánt gépekkel és annak IP porton történő szolgáltatásait szeretnénk ellenőrizni. Ilyen esetben nem nehéz a feladat, a Nagios-szal kapot pluginok közül a megfelelőt kell futtatni a szükésges paraméterekkel (távoli gép IP címe, warning és critical level). Ilyen ellenőrzésre tipikus eset egy publikus szolgáltatás működésének az ellenőrzése, például SMTP, http szolgáltatások.
SNMP
Egy kicsit összetettebb az ellenőrzés elvégzése, ha nem publikus szolgáltatást, hanem valamilyen aktuális állapotot, például egy switch optikai portjának kimenő forgalmát, annak is az elmúlt 5 perces átlagát szeretnénk monitorozni. Ilyen esetekben az SNMP protokoll segítségére támaszkodhatunk.
Távoli gépek ellenőrzése
Az eddigiek segítségével csak „kívülről” láttunk bele az ellenőrizni kívánt gépbe, de sok esetben ez nem elég, hiszen egy szolgáltatás működésének leállása általában előre jelezhető, ha van lehetőség a kiszolgáló egyéb paramétereit is figyelni (memória, CPU, diszk kihasználtság). Erre több lehetőség kínálkozik. Az elterjedtebb megoldás szerint a Nagios kiszolgáló igény esetén kéri a távoli gépen a szolgáltatás ellenőrzését. Erre a feladatra Linux / Unix esetén az NRPE (Nagios Remote Plugin Executor) alkalmazható, míg Windows esetén az NSClient++ használható. Működésük megegyezik, a Nagios-hoz teljesen hasonló módon, ugyanazon plugin-ok futtatására használható. Egyszerűen megfogalmazva a Nagios szerver és a monitorozandó gép közötti hálózati kommunikációt biztosítja biztonságos körülmények között.
Erre a feladatra egy másik, kevésbé eltredt megoldás is létezik, amikor a monitorozott gép rendszeres időközönként futtaja az ellenőrző pluginokat majd azok eredményéről tájékoztatja a Nagios szerver. Ennek a neve: NSCA (Nagios Service Check Acceptor). Ennek a használatához a Nagios szerverre is telepíteni kell NSCA klienst. Hátránya az előzőekhez képest, hogy váratlan leállás esetén több időbe telik, amíg a Nagios – így annak felhasználói – értesül a problémáról.
Milyen legyen az ellenőrzés eredménye?
Az alábbi kép jól szemlélteti, hogy miként érdemes kialakítani az ellenőrzéseket. Ahogy látható fent azt ellenőrizzük, hogy egy szolgáltatás a kiszolgálón hány példányban fut. Sajnos egy példányban fut, ami biztosan nem jó, hiszen a limit értéket meghaladja. Rövid tájékoztatást kapunk, ami informatiív.
Az alatta lévő probléma már közel sem ennyire nyilvánvaló. Az kiderül, hogy egy Windows eseménynaplóját figyeljük, de a pontos problémát nem látjuk.
Az ilyen esetekben érdemes több részre osztani a szolgáltatást. Probléma esetén legyen egyértelmű, hogy mivel van probléma.
Egy ellenőrzés eredménye három részből áll. Egy állapotjelzőből, ami 0-2 értéket vehet fel (0- Ok, 1- Warning, 2 - Critical). A következő része a Status Information. Ez rövid, de egyértelmű leírása problémának. A harmadik rész a Performance Data. Ez nem jelenik meg az összesítő táblázatban, így lehet bőbeszédű. Érdemes a plugin-t úgy kialakítani, hogy a Status Information ne leyen több, mint 100 karakter. A részleteket a Performance Data szakaszban érdemes megadni, ami akár 1000 karakter is lehet.
Mit és hogyan érdemes ellenőrizni?
A fenti kérdés megválaszolása egyáltalán nem egyszerű. Nincs egyértelmű szabályozás arra vonatkozólag, hogy egy kiszolgáló milyen paramétereit kell figyelni. A Nagios üzemeltetése a hosszú telepítés és beüzemelés után még hosszabb finomhangolásról híres.
Érdemes monitorozni a szerverek létfontosságú szolgáltatásait, továbbá olyan paramétereit, amelyek közvetve hatással lehetnek a szolgáltatás működésére. Ilyen például a gép hardver elemeinek állapotát figyelő ellenőrzések, a hálózati kapcsolat meglétét és minőségét figyelő ellenőrzések. Gyakran előfordul, hogy olyan hibával találkozunk, amit előre nem láttunk. Ilyenkor a probléma elhárítását követően tanácsos megtalálni a módját, hogy az ehhez hasonló hibákról először a Nagios küldjön értesítést, ezzel lényegesen felgyorsítható a probléma elhárítása.
Hálózatbiztonsági szempontból hasznos az elérhető és telepítésre váró frissítések számának és meglétének figyelése. Deb csomagokkal működő Linux disztribúciók esetén a check_apt hasznos lehet, míg Windows esetén a check_windows_updates lehet az üzemeltetők segítségére.
Van lehetőség arra, hogy a DHCP szerver mellett futtatott daemon a log fájl alapján összegyűjtse a hálózatban működő gépek MAC címeit, esetleg gépnévvel és IP címmel. Ha ritkán változik a hálózatba kötött gépek száma, akkor a Nagios által lehetőség van új gép megjelenéséről értesülni.
Szintén a hálózatbiztonságot szem előtt alkalmas bármilyen log fájl feldolgozására. Szükség esetén külső programot, szkriptet futtathat, amelynek az eredményét feldolgozva szinte bármit nyomon lehet követni általa.
Összességében elmondható, hogy legyen szó Windows vagy Linux rendszerről, bármilyen programnyelven elkészített külső szkript adhat a Nagios számára értelmezhető választ egy ellenőrzésre. Három értéket célszerű a Nagios-nak eljuttatni:
1. Az ellenőrzés eredményét: OK, Warning, Critical
2. Az állapotot leíró rövid, szöveges, lényegre törő értesítés (Status Information)
3. Nem kötelező, inkább tájékoztató jellegű hosszabb, szintén szöveges leírás, ami további információt ad az ellenőrzésről.
Megfigyelendő paraméterek
A következőkben felsorolt paramétereket érdemes figyelni. Nem bontom szét a listát külön Windows és Linux kiszolgálókra.
Általános paraméterek:• Processzor(ok) terhelési adatai
• Memeória kihasználtság
• Swap, pagefájl kihasználtság
• Háttértár szabad kapacitás – minden tárolót külön service-ként érdemes figyelni
• Folyamatos ping a hálózati kapcsolat állapotának megfigyelésére
• Hálózati sávszélesség figyelése – ahol érdekes
Hardverrel kapcsolatos ellenőrzések:
• Hőmérő szenzorok értékének monitorozása (processzor, alaplap, merevlemezek)
• Hűtőventillátorok működésének ellenőrzése
• Merevlemezek SMART adatainak figyelése
• RAID tömbök állapotának ellenőrzése
• Hálózat minőségének monitorozása (csomagveszteség)
Szoftverrel kapcsolatos ellenőrzések:
• A kiszolgáló szolgáltatásainak monitorozása legalább „kívülről”
• Fontos daemonok, szervizek futásának ellenőrzése.
• Elérhető frissítésekről valamilyen információ gyűjtése
• Összes futó processz száma
• Bejelentkezett felhasználók száma
Néhány példa log fájlok feldolgozására Linux rendszerek estén:Az alábbi felsorolt próbálkozásokat indító távoli gépeket jól konfigurált fail2ban szoftver automatikusan képes tetszőleges időre kitiltani tűzfal szabályokkal. Akár az általa generált tűzfal szabályok száma is mérhető.
• auth.log – sikeres/sikertelen bejelentkezések száma – általában szótárak alapján különböző feljhasználónevekkel próbálkoznak. Ha sikerült kideríteni, hogy milyen felhasználók vannak akkokr jöhetnek a jelszavak szótárból
• mail.err – Ip címenként az elmúlt órában hány levelet küldtek olyan felhasználónak, aki nem létezik? – Szótáras próbálkozással megpróbálják kitalálni a létező email címeket, hogy spam listában eladják azokat
• apache2/error.log – IP címenként hány kérést utasított el a kiszolgáló 404 hibával? – Jellemzően gyakran használt webes programok exploitjait próbálják kihasználni, első próbálkozásként ki kell deríteniük, hogy melyikek vannak telepítve a gépre. (/webmail, /phpmyadmin, stb)
• syslog – tűzfal által eldobott csomagok száma.
Lehetőségek Windows szerverek vagy munkaállomások esetén:A Windows eseménynaplóban a bejegyzések különböző Event ID –val vannak ellátva. A Windows naplóbejegyzések általában három csoportra vannak szétosztva: System, Security, Application Ezek a kiszolgálóra telepített szolgáltatásoktól függően továbbiakkal egészülnek ki.
Vannak különböző alkalmazások, amelyek képesek a Windows Event Log- ját csv formátumba exportálni. Így összetettebb ellenőrzésre is lehetőség van.
A Windows eseménynapló monitorozása Nagioson keresztül több lehetőség kínálkozik. A fent említett NSClient++ szolgáltatás telepítése után lehetőség nyílik a CheckEventLog kiegészítést használni, amivel célirányosan kereshető a keresett bejegyzés.
Egy másik lehetőség a Nagios EventLog agent for Windows nevű alkalmazás kell telepítése a megfigyelni kívánt Windows- ra, ahol felhasználóbarát módon lehet létrehozni a szűrési feltételeket.
A Nagios- hoz ez NSCA-n keresztül kapcsolódik, tehát az ellenőrzött gép küld üzeneteket a Nagios szerver felé, nem pedig fordítva. Mivel ez egy Windows szolgáltatás, ha a szűrési feltételeknek megfelelő eseményt talál a naplóban, azonnal értesítést küld a Nagios- nak.
A fent leírt megoldások bármelyikével lehetőség van a Windows események összesítését a Nagios- ba irányítani. Ha speciális igények (nyomtatás, USB használat, napi mentés befejezésének jelzés stb) merülnek fel, akkor a Windows- on be kell állítani, hogy az esemény az EventLog- ba kerüljön egyedi EventId- val. A szűrést hozzáigazítva szinte bármilyen esemény továbbítható a Nagios- ba. Természetesen mindkét esetben megoldható, hogy milyen időszakra visszamenőleg keressen a Logban és mekkora számú előrefordulás esetén milyen állapotot jelezzen (Pl CheckEventLog futtatásakor a következő limitek adhatók meg: MinWarn, MinCrit, MaxWarn, MaxCrit).
Ha sok eseményről szeretnénk a Nagios- on keresztül értesülni, akkor megfontolandó egy Powershell, .NET vagy más program elkészítése, ami a beállított eseményeket figyeli és valamilyen úton a Nagios felől jövő kérdésre a részletes ellenőrzés eredményét átadja.
Tehát, ha szeretnénk a napi sikertelen helyi és távoli bejelentkezéseket, valamilyen művelet lefutását (pl. mentés), új fájl létrejöttének, változásának megtörténtét, stb. figyelni, akkor vagy mindegyikhez külön ellenőrzést hozunk létre, vagy a Windows-on elvégzett ellenőrzések eredményét adjuk át áttekinthető formában! a Nagios számára. Ilyen esetben fontos megtalálni az egyensúlyt. Mert a fenti képen látható nem egyértelmű hibajelentés lehet a vége.
Példák:Az elmúlt 30 napban ki és mikor állította le a gépet?check_nrpe -H 192.168.9.85 -p 5666 -c CheckEventLog -a filter=new file=system MaxWarn=5 MaxCrit=10 filter-generated=\>30d filter+eventID==1073 "syntax=%strings% %generated%" SIMONTEST, SIMONTEST\Administrator, Tuesday, August 16, 2011 14:55:11|'eventlog'=1;5;10
Az elmúlt fél évben mikor állították le szabálytalanul a gépet?check_nrpe -H 192.168.9.85 -p 5666 -c CheckEventLog -a filter=new file=system MaxWarn=5 MaxCrit=10 filter-generated=\>180d filter+eventID==6008 "syntax=%generated%"
Thursday, April 21, 2011 11:13:48|'eventlog'=1;5;10
Az elmúlt két napból azok a bejegyzések, amelyek hibára utalnak:./check_nrpe -H 192.168.9.85 -p 5666 -c CheckEventLog -a file=system descriptions MaxWarn=5 MaxCrit=10 "filter=generated gt -2d AND severity NOT IN ('success', 'informational')" "syntax=%message%"
The system uptime is 183536 seconds., The system uptime is 269921 seconds., The NSClientpp (Nagios) 0.3.9.322 2011-07-04 x64 service terminated unexpectedly. It has done this 1 time(s).|'eventlog'=3;5;10
Az elmúlt egy napban a sikertelen bejelentkezések ideje:file=security descriptions MaxWarn=5 MaxCrit=10 "filter=generated gt -1d AND message LIKE 'failed to log on'" "syntax=%generated%,"
Al elmúlt két napban bizonyos tartalommal és EventIDval hány bejegyzés volt(mentést végző szkript figyelésére):
file=application descriptions unique MinWarn=1 MinCrit=0 "filter=id = 2 AND source='EventCreate' AND generated gt -2d " "syntax=%message%"
Példák adatbázisok állapotának, kihasználtságának figyelésére.A legegyszerűbb ellenőrzés az adatbázis szolgáltatás működésének ellenőrzése egy egyszerű, minden adatbázistól független lekérdezés futtatása, például ha select 1+2 lekérdezés nem 3-at ad eredményül, akkor probléma van.
A Mysql 5-ös verziójától kezdve lehetőség van arra, hogy a slow query log magába az adatbázisba kerüljön. A korábbi verziók esetén ez szöveges log fájlba került. Mindkét esetben lehetőség van arra, hogy figyeljük, hogy az elmúlt időszakban volt-e olyan lekérdezés, ami bizonyos rekordszámnál többet adott vissza, vagy egy meghatározott időnél tovább futott. Lehetőség van az összes adatbázis művelet monitorozására, így egy csak olvasásra rendeltetett adatbázis táblába való beszúrás biztosan rendkívüli jelenség.
Hasznos adatokkal szolgálnak a SHOW kezdetű lekérdezések eredménye, ami többek között a kapcsolatok számáról, átmeneti tárolók kihasználtságáról, tábla és rekord -zárolásokról, nyitott fájlokról, adatbázis táblákról, stb. add információt.
A fenti példák MySQL- re értendőek, de valószínűleg más adatbázis-kezelőkhöz is elérhetőek hasonló állapotjelző lehetőségek.
SSL kulcsok lejárati idejének figyelése.Fontos, hogy a lejárat napján legkésőbb meg legyenek újítva a kulcsok, mivel a szolgáltatás fennakadását okozhatja.
A Nagios-hoz több ilyen tevékenységet végző plugin érhető el, viszont ezek jellemzően valamilyen SSL réteggel kiegészített hálózati szolgáltatás kulcsát ellenőrzik. OpenVPN esetén is fontos a kulcsok kezelése, így ennél is meg kell oldani valahogy a figyelést. Az összes kulcs csak a szerver oldalon érhető el, így ezen az oldalon érdemes az ellenőrzést futtatni. Sajnos nem találtam olyan plugin-t, ami pontosan megfelelne az igényeknek, viszont a következő parancs jó kiindulása lehet egy saját plugin készítésének:
for i in `find /etc/openvpn/ -name *.crt`; do openssl x509 -in $i -noout -enddate | awk '{gsub("notAfter=","");print $4" "$1" "$2}'; done
Ezzel a paranccsal a meghatározott könyvtár certificat fájljainak lejárati idejét OpenSSL segítségével kiíratjuk és feldolgozzuk.
Elosztott ellenőrzésű rendszerek
Egy bizonyos méretű infrastruktúra ellenőrzése után érdemes megfontolni azt, hogy az ellenőrzéseket és azok kiértékelését nem egyetlen Nagios szolgáltatásra bízzuk. Szerencsére léteznek ingyenesen elérhető alkalmazások, amik segítségével az ellenőrzések futtatása elosztott módon történhet, azok eredménye mégis egyetlen felületről ellenőrizhető.
Ezek működése eltér egymástól. A legegyszerűbb az, amikor a távoli Nagios állapotát egyetlen, a központi Nagios-on futó szolgáltatás mutatja. Ez összesített információt gyűjt a távoli Nagios állapotáról és számokban összesíti azt. Egy másik megoldás a Nagios Core és a szolgáltatások közé beépült modul használata. Ebben az esetben a központi Nagios végez minden ellenőrzést, ám nem közvetlenül, hanem a telepített modulnak adja át a feladatot.
A fent leírt megoldások megpróbálják valamilyen módon megoldani a nagy infrastruktúra ellenőrzésekor jelentkező problémákat, de nem oldják meg azokat.
A tényleges megoldásra, amikor több gép végzi az ellenőrzéseket több lehetőség is kínálkozik ingyenes szoftverek használatával:
•
DNX (Distributed Nagios eXecutor) A probléma egyszerű megközelítése. A Nagios szerverek Master- Slave hierarchiában állnak, a konfiguráció és az ellenőrzések időzítése a Master feladata, az ellenőrzéseket pedig a saját konfigurációval nem rendelkező Slave szerverek végzik. Csak az elvégzett ellenőrzés eredményét közlik a Master kiszolgálóval.
•
MNTOS (Multi-Nagios Tactical Overview System) Sok tekintetben az előző ellentéte. A nem központi szerepben álló Nagios- ok a teljes infrastruktúrának csak egy bizonyos részét ellenőrzik és a központi gépen áttekintést, adnak az általuk ellenőrzött részletről.
•
Nagios Fusion: A Nagios fizetős szoftvere, amely központi képet ad az ellenőrzött hálózatról. A konfiguráció és az ellenőrzések az elosztott szervereken vannak elhelyezve, ez lényegében egy központi felület kibővített lehetőségekkel (több felhasználó, eltérő felület, felhasználók között elosztott infrastruktúra, stb.)
