Monitorozás

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(cacti-link)
(Példa: autonóm önmonitorozás shellben (vázlatosan): overhaul)
 
(2 szerkesztő 36 közbeeső változata nincs mutatva)
11. sor: 11. sor:
 
#*** A kérdés azért ennél bonyolultabban is kezelhető: idősorok, trendek, szezonalitás... Komolyabb rendszerben már így kell.
 
#*** 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 [[A Nagios működése|Nagios]], az utóbbira a [[A munin működése|munin]] és a [http://cacti.net/ cacti] (házi feladat). A [http://www.zabbix.com/ Zabbix] valahol a kettő között van, egy kicsit mindkettőt tudja (és lehetséges házi feladat).
+
Az előbbire egy klasszikus megoldás a [http://sourceforge.net/projects/mon/ mon], a [[A Nagios működése|Nagios]] (vagy az [https://www.icinga.org/ Icinga] nevű forkja), az utóbbira a [[A munin működése|munin]], a [http://cricket.sourceforge.net/ cricket], az [http://oss.oetiker.ch/mrtg/ mrtg], a [http://www.netmrg.net/ NetMRG] és a [http://cacti.net/ cacti] (házi feladat). A [http://oss.sgi.com/projects/pcp/ Performace Co-Pilot] és a [http://www.zabbix.com/ Zabbix] valahol a kettő között van, egy kicsit mindkettőt tudja (és lehetséges házi feladat).
  +
  +
Az utóbbi években a monitorozás terén rohamos volt a fejlődés. A teljesség igénye nélkül álljon itt néhány újabb csomag neve: [http://graphite.wikidot.com/ graphite], [http://riemann.io/ riemann], [http://collectd.org/ collectd], [http://ganglia.sourceforge.net/ ganglia], [http://mailping.sourceforge.net/ mailping], [http://www.shinken-monitoring.org/ Shinken], [https://labs.omniti.com/labs/reconnoiter/wiki reconnoiter], [https://github.com/etsy/skyline Skyline]. Természetesen mindegyikről írható házi feladat. :)
   
 
Mielőtt ezekbe belemegyünk, nézzünk néhány általános tervezési szempontot:
 
Mielőtt ezekbe belemegyünk, nézzünk néhány általános tervezési szempontot:
17. sor: 17. sor:
 
== Architektúra ==
 
== Architektúra ==
   
Ha adatokat gyűjtünk, az architekturálisan a következő módokon történhet:
+
A következő architekturális kérdések merülnek fel a monitorozással kapcsolatban:
   
# A monitorozó gép kérdezgeti a monitorozott gépeket.
+
# "pull" vs. "push"?
#* Minden monitorozott gép "szerver".
+
#* Pull esetén az adatgyűjtő gép kérdezgeti a monitorozandókat, push esetén maguktól küldözgetnek időnként adatokat.
#* A lekérdezőgépnek valahogyan hitelesítenie kell magát.
+
#* Az SNMP-ben lényegében mindkettő van: a trap "push", a polling pedig "pull".
#* Ú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 monitorozott adatok körét az adatgyűjtő vagy a monitorozandó gép határozza meg?
# A monitorozandó gépek tolják az adatokat egy szerverre.
+
# Állandó kapcsolat (pl. TCP) van-e az adatgyűjtő és a monitorozandó gépek között?
#* Kitől fogadjon el adatokat a szerver?
+
# Az adatgyűjtő gép kapcsolódik a monitorozandókhoz, vagy fordítva?
#** Kézenfekvőnek látszik valamilyen PKI használata...
+
#* Ez ortogonális a pull vs. push kérdésre: lehet, hogy az adatgyűjtő gép építi fel a hálózati kapcsolatot, de aztán a megfigyelt gép dönti el, mikor mit küldjön; és az is lehet, hogy a megfigyelt gép kapcsolódik az adatgyűjtőre, de a kapcsolat felépülte után az adatgyűjtő pollozza őt.
#* Milyen és mennyi adatot fogadjon el?
+
# Hierarchiába szerveződnek-e a rendszer komponensei?
  +
# Elvileg lehetséges lenne multicasting-alapú monitorozás is, bár nem tudok konkrét elterjedt megvalósításról; ekkor
  +
#* vagy az adatgyűjtő gép küld időnként multicasttal polling-üzeneteket,
  +
#* vagy a monitorozott gépek küldenek multicasttal adatokat magukról.
  +
#* A lekérdezésekre adott válasz is lehet unicast vagy multicast.
  +
#* Ugyanez elvileg akár broadcast-alapon is működhetne.
   
A gyűjtendő adatok körének meghatározása is többféle lehet:
+
=== Pull vs. push ===
   
* A monitorozott gép dönti el, milyen adatokat küld.
+
Pull esetén az adatgyűjtő dönti el, milyen gyakran vesz mintát a megfigyelt adatokból.
** Nehéz központilag módosítani sok gépen egyszerre.
+
* Egyszerű központilag változtatni rajta, adaptívvá tenni stb.
** Megbízhatunk a monitorozószerverben, mert nem tudja befolyásolni, mit futtatunk (bár azt esetleg igen, hogy milyen gyakran).
+
* Egyszerű időben egyenletesen elosztani több megfigyelt gép lekérdezését.
** Ha polling van, akkor a "szervernek" valahogyan meg kell tudnia, milyen adatokat fog kapni vagy mit kell lekérdeznie.
+
* Főként akkor , ha grafikont akarunk rajzolni valamilyen teljesítményjellemző időbeli alakulásáról.
* 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ó.
 
   
=== Skálázhatóság ===
+
Push esetén a megfigyelt gép dönti el, mikor van mondanivalója.
  +
* Lehet sürgős mondanivalója olyankor is, amikor az adatgyűjtő magától éppen nem kérdezne tőle semmit.
  +
* Terheléstüskéket okozhat az adatgyűjtőn.
  +
* Nehéz lehet központilag módosítani a mintavétel gyakoriságát.
  +
* Cserébe az adatgyűjtőben nem kell megvalósítani a pollozás ütemezését, a párhuzamos pollozás hibakezelését.
  +
* Főként akkor jó, ha események bekövetkeztére várunk, pl. valamilyen küszöbérték elérésére.
  +
  +
=== A megfigyelt adatok köre ===
  +
  +
Ha 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).
  +
* Az adatgyűjtőnek valahogyan meg kell tudnia, milyen adatokat fog kapni vagy mit kell lekérdeznie (metaadatokkal kell kiegészíteni az adatokat).
  +
** Ez történhet in-band, mint a [[A munin működése|munin]]nál, vagy legalább részben out-of-band, mint az SNMP-nél (ahol a MIB a priori ismert).
  +
* Rosszul beállított vagy rosszindulatú kliens túl gyakran és/vagy túl sok adatot küldhet a szervernek, tehát erre szerveroldalon fel kell készülni.
  +
* 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.
  +
  +
Ha az adatgyűjtő 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.
  +
* Szervereket SNMP nélkül általában rugalmasabban lehet monitorozni, az SNMP inkább hálózati dobozokhoz való.
  +
  +
=== Van-e állandó hálózati kapcsolat? ===
  +
  +
Ha van:
  +
  +
* Keep-alive üzenetek segítségével figyelhetjük, él-e még a túloldali gép.
  +
* Megspóroljuk a lekérdezéshez szükséges kapcsolat felépítéséhez szükséges időt.
  +
* Cserébe foglalkozni kell a kapcsolatok fenntartásával (memória, sávszélesség, processzoridő).
  +
* Főként akkor jó, ha nagyon gyakran (pl. néhány másodpercenként) kérdezünk le valamit és/vagy hamar szeretnénk értesülni a megfigyelt gép elérhetetlenné válásáról.
  +
* A hosszú életű, kevés adatot forgalmazó kapcsolatba egy támadó számára viszonylag könnyű csomagokat injektálni (persze kérdés, mekkora baj ez).
  +
  +
Ha nincs:
  +
  +
* Minden lekérdezésnél külön kell kapcsolódni egymáshoz.
  +
** Ez TCP esetén három körülfordulási idő és három plusz csomag a kapcsolat elején; ha a kérés és a válasz is elfér egy-egy csomagban, akkor elég nagy pazarlás (és jobb választás lehet az UDP).
  +
* Érzéketlenek vagyunk arra, ha két lekérdezés között megszűnik a hálózati kapcsolat a két gép között.
  +
* Ha hitelesíteni akarja egymást a két gép, az további overhead.
  +
* Főként akkor jó, ha
  +
** egy menetben viszonylag sok adatot küldünk,
  +
** viszonylag ritkán küldünk adatot,
  +
** nem használunk költséges hitelesítést.
  +
  +
=== Ki a hálózati értelemben vett szerver? ===
  +
  +
Ha az adatgyűjtő:
  +
  +
* Kitől fogadjon el adatokat?
  +
** Kézenfekvőnek látszik valamilyen PKI használata...
  +
* Ha megváltozik a monitorozó gép elérhetősége, vagy újabb monitorozó gépet állítunk csatasorba, rossz esetben minden monitorozott gépen el kell végezni a módosítást.
  +
* Előny: új monitorozott gép beállítása esetén az adatgyűjtőhöz nem kell nyúlni.
  +
** Feltéve, hogy PKI-t használunk, vagy ugyanabban az alhálózatban van az összes kliens; különben a hitelesítés miatt a szerverhez is hozzá kellhet nyúlni.
  +
* Előny: nem kell "szervert" rakni a monitorozott gépre. Ez egyszerűsítheti a tűzfalkonfigurációt.
  +
  +
Ha a megfigyelt gépek:
  +
  +
* Minden monitorozott gép "szerver" (hálózati kapcsolatokat fogad, kérésekre válaszol).
  +
* A lekérdezőgépnek valahogyan hitelesítenie kell magát (akár csak az IP-címével).
  +
* Új monitorozott gép felvételekor a monitorozó géphez is hozzá kell nyúlni (meg kell neki mondani, hogy újabb gépet pollozzon).
  +
** Ez DNS-trükközéssel és tucatnyi egyéb módon megkerülhető lehet, de végeredményben akkor is igaz marad, hogy nem elegendő csak az új monitorozott gépet piszkálni.
  +
* Az adatgyűjtőt fel kell készíteni arra, hogy értelmesen kezelje a kapcsolódási hibákat (pl. az egyik megfigyelt gép elérhetetlensége ne okozzon fennakadást a több monitorozásában).
  +
  +
=== Hierarchikus monitorozás ===
  +
  +
Javíthatja a skálázhatóságot és átláthatóságot: nem kell, hogy egyetlen monitorozó állomás gyűjtse közvetlenül az összes monitorozandó állomás adatait stb.
  +
  +
A hierarchia magasabb szintjein lehet, hogy elegendő, ha az alacsonyabb szintek adatai aggregált formában jelennek meg; nagyon nagy hálózatoknál emberi operátorok számára kezelhetetlen lenne minden egyes alacsony szintű adatsor összessége. Pl. (általában) nem kell tudni, melyik konkrét végpont mennyi forgalmat bonyolít le, csak azt, hogy mondjuk az intézmény egyik épületéből mennyi forgalom jön ki. Ha gyanúsan sok, természetesen meg lehet nézni, miért, de felesleges eleve minden mérési adatot az operátor elé tenni.
  +
  +
Az adatok aggregálása a skálázhatóság szempontjából is előnyös: a legfelső szintű adatgyűjtőhöz nagyságrendekkel kevesebb adat kell, hogy befusson, ha az alárendelt csomópontok az őhozzájuk tartozó adatokat maguk aggregálják.
  +
  +
A hierarchikus elrendezés nyilvánvaló hátránya a nagyobb bonyolultság és emiatt több hibalehetőség.
  +
  +
== 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.
 
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.
 
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.
+
Pl. ha [[RRDTool]]t 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ó).
+
Szintén fontos kérdés, hogy mennyi munka egy új monitorozandó gép beállítása (a munin esetében pl. elég kevés, és ez jó).
   
 
Arra is figyeljünk oda, hogy Ne Monitorozzuk Halálra a Gépet.
 
Arra is figyeljünk oda, hogy Ne Monitorozzuk Halálra a Gépet.
49. sor: 49. sor:
   
 
* Időben minél egyenletesebben elosztva monitorozzunk;
 
* 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...
+
** ha 60000 webszerver reakcióidejét egyszerre próbáljuk megmérni 100 megabites hálózaton, valószínűleg mást kapunk, mint ha egyenként próbálkoznánk...
   
=== Robusztusság, megbízhatóság, redundancia ===
+
== Robusztusság, megbízhatóság, redundancia ==
   
Filozófia (nehéz lehet a gyakorlatba átültetni):
+
* 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 <tt>apache</tt> 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).
  +
  +
* 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).
   
* Főleg megy/nem megy típusú monitorozásnál mindig az legyen az alapfeltevés, hogy ''nem megy''.
+
=== Példa: szabad hely mennyisége ===
** 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 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ó;
 
* 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.)
 
** é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.
+
** A monitorozórendszer nyilván nem SMTP-alapú levelekből fog értesülni arról, hogy elfogyott a hely; a kérdés itt az, hogyan és mikor értesítsük a rendszergazdát?
  +
* A monitorozó-szervernek mindenképpen szólhatunk: akkor is, ha még sok hely van, akkor is, ha már fogytán van, és akkor is, ha már elfogyott.
 
** Ha elfogyott, egy idő után mindenképpen riasztani kell egy embert, viszont
 
** 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.
 
** 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?)''
 
* 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é...)
 
* 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é...)
  +
* Vegyük észre, hogy még ebben a rendkívül egyszerű esetben is nehéz elvi garanciát nyújtani arra, hogy a riasztás időben elér valaki olyat, aki képes beavatkozni.
   
* 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.
+
=== Példa: nem deface-elték az oldalunkat? ===
* 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.
+
* "Igazi" megy/nemmegy típusú feladat mondjuk annak eldöntése, hogy egy weboldalon a várt tartalom van-e.
** Abból, hogy fut <tt>apache</tt> nevű processz, még nem következik, hogy működik a website...
+
** Hogyan ellenőrizzük ezt?
* Minél absztraktabb a próba, annál könnyebben előfordulhat, hogy
+
*** Néhány percenként letöltjük az oldalt, és mondjuk binárisan összehasonlítjuk a referenciával.
** akkor is sikeres, amikor a valódi felhasználók számára valójában nem működik a szolgáltatás,
+
*** Gond akkor van, ha az oldal bizonyos részei változhatnak (pl. rá van írva, milyen nap vagy milyen névnap van); annak az automatikus eldöntése, hogy ezt leszámítva megfelelő-e a tartalom, már nem olyan egyszerű.
** vagy fordítva (hibát jelez, pedig a felhasználók nem vennének észre semmit).
+
*** És ha a gonosz támadók éppen a névnapok helyére írnak obszcén üzenetet?
  +
*** Vagy csak simán minden napot Gandalf-napnak hazudnak?
  +
** Elő kellene tudni állítani a referenciát is, teljes dinamikus tartalommal, hogy aztán összehasonlíthassuk az élő oldallal.
  +
*** Csakhogy: ha nagyon gyorsan változó dinamikus tartalom van az oldalon (mondjuk részvényárfolyam), vagy véletlenszerű részek is (pl. szindikált hírek), akkor nem tudunk használható referenciát előállítani.
  +
* Még bonyolultabb feladat: a gyerekeknek szóló portálunkra kerülő szindikált reklámcsíkok nem reklámoznak pornószájtot?
   
=== Autonómia ===
+
=== Példa: működik a weboldal? ===
   
Hasznos, ha a monitorozott gép maga tolja fel a monitorozó gépre a státuszát, és nem annak kell őt kérdezgetnie.
+
* Mondjuk: lehet vásárolni a webshopban?
Ennek több előnye van:
+
** Ha szintetikus HTTP-kérésekkel próbáljuk ki, nem biztos, hogy érvényes az eredmény;
  +
** Pl. ha a "buy now" feliratú gomb helyén véletlenül a webdesigner tapírospornó-gyűjteményének egyik különösen jól sikerült darabja látható (vagy reálisabban: meg sem jelenik a gomb), akkor technikailag ugyan lehet vásárolni, gyakorlatilag azonban mégsem sokan fognak.
  +
** Erre jó automatikus megoldás valószínűleg nincs; azzal járunk a legjobban, ha felveszünk néhány egyetemistát, hogy fűzzék le a bejövő faxokat és közben negyedóránként adjanak le egy-egy próbamegrendelést.
   
* Bizonyos szempontból egyszerűbb a "szerveroldali" megvalósítás:
+
=== Csináld-magad monitorozás ===
** nem kell megvalósítani a pollozást és a vele összefüggő párhuzamosságot/hibakezelést;
+
** cse8rébe viszont fokozottan kell valamilyen biztonsági architektúra a kliensek hitelesítésére.
+
Alapszintű monitorozást nagyon könnyen megvalósíthatunk magunk is. Nyilván nem lesz hozzá szép webes felület, nem fog integrálódni semmibe, nem lesz hosszú távon költséghatékony stb., cserébe csekély kezdeti befektetést igényel.
*** 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ő:
+
Egy lehetséges megközelítés az alábbi:
   
 
# Ötpercenként töröljük azokat a jelzőfile-okat, amik akkor jönnek létre, ha a szolgáltatások mennek.
 
# Ö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?".
 
# 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).
 
# 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).
  +
#* Csak nehogy az legyen a baj, hogy mondjuk a jelzőfile létrehozása a szolgáltatással össze nem függő ok miatt kicsit késik...
  +
  +
Természetesen a jelzőfile-okat akár ki is lehet hagyni; lehet minden egyes monitorozó alfeladat egy-egy [[A runit működése|runit]]-service, amelyeknek a futását így a runit ütemezi (a scriptben elhelyezett <tt>sleep</tt> paranccsal "finomhangolható" a futás gyakorisága). Ha a script hibát észlel, riaszthat vagy beavatkozhat (például kritikus hibára utaló üzenetek logbeli megjelenése esetén újraindíthat egy másik szolgáltatást).
  +
  +
Fontos megjegyezni, hogy ezek a megoldások általában nem ''jók'' abban az értelemben, hogy hajlamosak törékenyek, esetlegesek és aluldokumentáltak lenni; az utódunk nem biztos, hogy áldani fogja a nevünket, amikor megpróbál rájönni, miért indul újra ez vagy az látszólag minden ok nélkül... Másfelől viszont, ha nem akarunk nagy és összetett monitorozórendszert, vagy valamelyik konkrét részfeladatot a monitorozórendszerünk nem tudja értelmesen megoldani, ne feledjük, hogy shellscriptekkel így vagy úgy szinte bármi megoldható. :)
  +
  +
== Buktatók ==
   
 
Az autonómiával és a riasztásokkal csak óvatosan:
 
Az autonómiával és a riasztásokkal csak óvatosan:
105. sor: 113. sor:
 
* ha 5 webszerver-újraindítás után még mindig nem jó, rebootoljunk;
 
* ha 5 webszerver-újraindítás után még mindig nem jó, rebootoljunk;
 
* stb.
 
* stb.
  +
  +
==SNMP==
  +
  +
Írta: Gellén Áron
  +
  +
===Az SNMP(Simple Network Management Protocol) modell alkotóelemei===
  +
  +
====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.
  +
  +
====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.
  +
  +
====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.''
  +
  +
====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
  +
  +
[[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:
  +
**#hitelesítés és titkosítás;
  +
**#hitelesítés, titkosítás nélkül;
  +
**#hitelesítés és titkosítás nélkül
  +
  +
===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ó.
  +
  +
===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ó.
  +
[[Kép:Mib_struct.gif]]
  +
  +
==Az SNMP agent beállítása (példa)==
  +
*SNMP telepítés ''(pl. apt-get install snmpd)''
  +
*SNMP beállítás ''(/etc/snmp/snmpd.conf szerkesztése)''
  +
**Az SNMP agent alapbeállítása "paranoid" így nem lehet az adatokhoz hozzáférni. Ezt át kell állítanunk:
  +
#sec.name source community
  +
com2sec paranoid default public
  +
#com2sec readonly default public
  +
#com2sec readwrite default private
  +
:sorok átírása:
  +
#sec.name source community
  +
#com2sec paranoid default public
  +
com2sec readonly default public
  +
#com2sec readwrite default private
  +
  +
:Megadhatjuk az(oka)t a címe(ke)t is, ahonnan az adatokat el kívánjuk érni (pl. localhost, cím, címcsoport):
  +
com2sec local localhost public
  +
com2sec localNet 192.168.0.0 /24 public
  +
**"security name" csoportokba rendezése (az SNMP Group megadása kötelező minden olyan rendszerben, ami SNMP protokollt használ.)
  +
#sec.model sec.name
  +
group MyROSystem v1 paranoid
  +
group MyROSystem v2c paranoid
  +
group MyROGroup v1 readonly
  +
group MyROGroup v2c readonly
  +
group MyRWGroup v1 readwrite
  +
group MyRWGroup v2c readwrite
  +
:sorok átírása:
  +
group MyROSystem v1 local
  +
group MyROSystem v2c local
  +
group MyROGroup v1 localnet
  +
group MyROGroup v2c localnet
  +
group MyRWGroup v1 local
  +
group MyRWGroup v2c local
  +
**nézet megadása a csoportokhoz (itt az alapbeállítás megfelelő)
  +
#incl/excl subtree mask
  +
view all included .1 80
  +
view system included .iso.org.dod.internet.mgmt.mib-2.system
  +
**a csoportok és a nézet egymáshoz rendelése (itt az alapbeállítás megfelelő)
  +
#context sec.model sec.level match read write notif
  +
access MyROSystem "" any noauth exact system none none
  +
access MyROGroup "" any noauth exact all none none
  +
access MyRWGroup "" any noauth exact all all none
  +
**System Contact (rendszergazda elérhetőségei, stb.) - ''nem kötelező beállítani''
  +
#System contact information
  +
syslocation Unknown (configure /etc/snmp/snmpd.local.conf)
  +
syscontact Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)
  +
*SNMP daemon újraindítása (új konfigurációval)
  +
#/etc/init.d/snmpd restart
  +
''Gellén Áron (BME-VIK)''

A lap jelenlegi, 2013. október 19., 22:47-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 klasszikus megoldás a mon, a Nagios (vagy az Icinga nevű forkja), az utóbbira a munin, a cricket, az mrtg, a NetMRG és a cacti (házi feladat). A Performace Co-Pilot és a Zabbix valahol a kettő között van, egy kicsit mindkettőt tudja (és lehetséges házi feladat).

Az utóbbi években a monitorozás terén rohamos volt a fejlődés. A teljesség igénye nélkül álljon itt néhány újabb csomag neve: graphite, riemann, collectd, ganglia, mailping, Shinken, reconnoiter, Skyline. Természetesen mindegyikről írható házi feladat. :)

Mielőtt ezekbe belemegyünk, nézzünk néhány általános tervezési szempontot:

Tartalomjegyzék

[szerkesztés] 1 Architektúra

A következő architekturális kérdések merülnek fel a monitorozással kapcsolatban:

  1. "pull" vs. "push"?
    • Pull esetén az adatgyűjtő gép kérdezgeti a monitorozandókat, push esetén maguktól küldözgetnek időnként adatokat.
    • Az SNMP-ben lényegében mindkettő van: a trap "push", a polling pedig "pull".
  2. A monitorozott adatok körét az adatgyűjtő vagy a monitorozandó gép határozza meg?
  3. Állandó kapcsolat (pl. TCP) van-e az adatgyűjtő és a monitorozandó gépek között?
  4. Az adatgyűjtő gép kapcsolódik a monitorozandókhoz, vagy fordítva?
    • Ez ortogonális a pull vs. push kérdésre: lehet, hogy az adatgyűjtő gép építi fel a hálózati kapcsolatot, de aztán a megfigyelt gép dönti el, mikor mit küldjön; és az is lehet, hogy a megfigyelt gép kapcsolódik az adatgyűjtőre, de a kapcsolat felépülte után az adatgyűjtő pollozza őt.
  5. Hierarchiába szerveződnek-e a rendszer komponensei?
  6. Elvileg lehetséges lenne multicasting-alapú monitorozás is, bár nem tudok konkrét elterjedt megvalósításról; ekkor
    • vagy az adatgyűjtő gép küld időnként multicasttal polling-üzeneteket,
    • vagy a monitorozott gépek küldenek multicasttal adatokat magukról.
    • A lekérdezésekre adott válasz is lehet unicast vagy multicast.
    • Ugyanez elvileg akár broadcast-alapon is működhetne.

[szerkesztés] 1.1 Pull vs. push

Pull esetén az adatgyűjtő dönti el, milyen gyakran vesz mintát a megfigyelt adatokból.

  • Egyszerű központilag változtatni rajta, adaptívvá tenni stb.
  • Egyszerű időben egyenletesen elosztani több megfigyelt gép lekérdezését.
  • Főként akkor jó, ha grafikont akarunk rajzolni valamilyen teljesítményjellemző időbeli alakulásáról.

Push esetén a megfigyelt gép dönti el, mikor van mondanivalója.

  • Lehet sürgős mondanivalója olyankor is, amikor az adatgyűjtő magától éppen nem kérdezne tőle semmit.
  • Terheléstüskéket okozhat az adatgyűjtőn.
  • Nehéz lehet központilag módosítani a mintavétel gyakoriságát.
  • Cserébe az adatgyűjtőben nem kell megvalósítani a pollozás ütemezését, a párhuzamos pollozás hibakezelését.
  • Főként akkor jó, ha események bekövetkeztére várunk, pl. valamilyen küszöbérték elérésére.

[szerkesztés] 1.2 A megfigyelt adatok köre

Ha 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).
  • Az adatgyűjtőnek valahogyan meg kell tudnia, milyen adatokat fog kapni vagy mit kell lekérdeznie (metaadatokkal kell kiegészíteni az adatokat).
    • Ez történhet in-band, mint a muninnál, vagy legalább részben out-of-band, mint az SNMP-nél (ahol a MIB a priori ismert).
  • Rosszul beállított vagy rosszindulatú kliens túl gyakran és/vagy túl sok adatot küldhet a szervernek, tehát erre szerveroldalon fel kell készülni.
  • 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.

Ha az adatgyűjtő 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.

  • Szervereket SNMP nélkül általában rugalmasabban lehet monitorozni, az SNMP inkább hálózati dobozokhoz való.

[szerkesztés] 1.3 Van-e állandó hálózati kapcsolat?

Ha van:

  • Keep-alive üzenetek segítségével figyelhetjük, él-e még a túloldali gép.
  • Megspóroljuk a lekérdezéshez szükséges kapcsolat felépítéséhez szükséges időt.
  • Cserébe foglalkozni kell a kapcsolatok fenntartásával (memória, sávszélesség, processzoridő).
  • Főként akkor jó, ha nagyon gyakran (pl. néhány másodpercenként) kérdezünk le valamit és/vagy hamar szeretnénk értesülni a megfigyelt gép elérhetetlenné válásáról.
  • A hosszú életű, kevés adatot forgalmazó kapcsolatba egy támadó számára viszonylag könnyű csomagokat injektálni (persze kérdés, mekkora baj ez).

Ha nincs:

  • Minden lekérdezésnél külön kell kapcsolódni egymáshoz.
    • Ez TCP esetén három körülfordulási idő és három plusz csomag a kapcsolat elején; ha a kérés és a válasz is elfér egy-egy csomagban, akkor elég nagy pazarlás (és jobb választás lehet az UDP).
  • Érzéketlenek vagyunk arra, ha két lekérdezés között megszűnik a hálózati kapcsolat a két gép között.
  • Ha hitelesíteni akarja egymást a két gép, az további overhead.
  • Főként akkor jó, ha
    • egy menetben viszonylag sok adatot küldünk,
    • viszonylag ritkán küldünk adatot,
    • nem használunk költséges hitelesítést.

[szerkesztés] 1.4 Ki a hálózati értelemben vett szerver?

Ha az adatgyűjtő:

  • Kitől fogadjon el adatokat?
    • Kézenfekvőnek látszik valamilyen PKI használata...
  • Ha megváltozik a monitorozó gép elérhetősége, vagy újabb monitorozó gépet állítunk csatasorba, rossz esetben minden monitorozott gépen el kell végezni a módosítást.
  • Előny: új monitorozott gép beállítása esetén az adatgyűjtőhöz nem kell nyúlni.
    • Feltéve, hogy PKI-t használunk, vagy ugyanabban az alhálózatban van az összes kliens; különben a hitelesítés miatt a szerverhez is hozzá kellhet nyúlni.
  • Előny: nem kell "szervert" rakni a monitorozott gépre. Ez egyszerűsítheti a tűzfalkonfigurációt.

Ha a megfigyelt gépek:

  • Minden monitorozott gép "szerver" (hálózati kapcsolatokat fogad, kérésekre válaszol).
  • A lekérdezőgépnek valahogyan hitelesítenie kell magát (akár csak az IP-címével).
  • Új monitorozott gép felvételekor a monitorozó géphez is hozzá kell nyúlni (meg kell neki mondani, hogy újabb gépet pollozzon).
    • Ez DNS-trükközéssel és tucatnyi egyéb módon megkerülhető lehet, de végeredményben akkor is igaz marad, hogy nem elegendő csak az új monitorozott gépet piszkálni.
  • Az adatgyűjtőt fel kell készíteni arra, hogy értelmesen kezelje a kapcsolódási hibákat (pl. az egyik megfigyelt gép elérhetetlensége ne okozzon fennakadást a több monitorozásában).

[szerkesztés] 1.5 Hierarchikus monitorozás

Javíthatja a skálázhatóságot és átláthatóságot: nem kell, hogy egyetlen monitorozó állomás gyűjtse közvetlenül az összes monitorozandó állomás adatait stb.

A hierarchia magasabb szintjein lehet, hogy elegendő, ha az alacsonyabb szintek adatai aggregált formában jelennek meg; nagyon nagy hálózatoknál emberi operátorok számára kezelhetetlen lenne minden egyes alacsony szintű adatsor összessége. Pl. (általában) nem kell tudni, melyik konkrét végpont mennyi forgalmat bonyolít le, csak azt, hogy mondjuk az intézmény egyik épületéből mennyi forgalom jön ki. Ha gyanúsan sok, természetesen meg lehet nézni, miért, de felesleges eleve minden mérési adatot az operátor elé tenni.

Az adatok aggregálása a skálázhatóság szempontjából is előnyös: a legfelső szintű adatgyűjtőhöz nagyságrendekkel kevesebb adat kell, hogy befusson, ha az alárendelt csomópontok az őhozzájuk tartozó adatokat maguk aggregálják.

A hierarchikus elrendezés nyilvánvaló hátránya a nagyobb bonyolultság és emiatt több hibalehetőség.

[szerkesztés] 2 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 pl. 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 100 megabites hálózaton, valószínűleg mást kapunk, mint ha egyenként próbálkoznánk...

[szerkesztés] 3 Robusztusság, megbízhatóság, redundancia

  • 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).
  • 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).

[szerkesztés] 3.1 Példa: szabad hely mennyisége

  • 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.)
    • A monitorozórendszer nyilván nem SMTP-alapú levelekből fog értesülni arról, hogy elfogyott a hely; a kérdés itt az, hogyan és mikor értesítsük a rendszergazdát?
  • A monitorozó-szervernek mindenképpen szólhatunk: akkor is, ha még sok hely van, akkor is, ha már fogytán van, és akkor is, ha már elfogyott.
    • 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é...)
  • Vegyük észre, hogy még ebben a rendkívül egyszerű esetben is nehéz elvi garanciát nyújtani arra, hogy a riasztás időben elér valaki olyat, aki képes beavatkozni.

[szerkesztés] 3.2 Példa: nem deface-elték az oldalunkat?

  • "Igazi" megy/nemmegy típusú feladat mondjuk annak eldöntése, hogy egy weboldalon a várt tartalom van-e.
    • Hogyan ellenőrizzük ezt?
      • Néhány percenként letöltjük az oldalt, és mondjuk binárisan összehasonlítjuk a referenciával.
      • Gond akkor van, ha az oldal bizonyos részei változhatnak (pl. rá van írva, milyen nap vagy milyen névnap van); annak az automatikus eldöntése, hogy ezt leszámítva megfelelő-e a tartalom, már nem olyan egyszerű.
      • És ha a gonosz támadók éppen a névnapok helyére írnak obszcén üzenetet?
      • Vagy csak simán minden napot Gandalf-napnak hazudnak?
    • Elő kellene tudni állítani a referenciát is, teljes dinamikus tartalommal, hogy aztán összehasonlíthassuk az élő oldallal.
      • Csakhogy: ha nagyon gyorsan változó dinamikus tartalom van az oldalon (mondjuk részvényárfolyam), vagy véletlenszerű részek is (pl. szindikált hírek), akkor nem tudunk használható referenciát előállítani.
  • Még bonyolultabb feladat: a gyerekeknek szóló portálunkra kerülő szindikált reklámcsíkok nem reklámoznak pornószájtot?

[szerkesztés] 3.3 Példa: működik a weboldal?

  • Mondjuk: lehet vásárolni a webshopban?
    • Ha szintetikus HTTP-kérésekkel próbáljuk ki, nem biztos, hogy érvényes az eredmény;
    • Pl. ha a "buy now" feliratú gomb helyén véletlenül a webdesigner tapírospornó-gyűjteményének egyik különösen jól sikerült darabja látható (vagy reálisabban: meg sem jelenik a gomb), akkor technikailag ugyan lehet vásárolni, gyakorlatilag azonban mégsem sokan fognak.
    • Erre jó automatikus megoldás valószínűleg nincs; azzal járunk a legjobban, ha felveszünk néhány egyetemistát, hogy fűzzék le a bejövő faxokat és közben negyedóránként adjanak le egy-egy próbamegrendelést.

[szerkesztés] 3.4 Csináld-magad monitorozás

Alapszintű monitorozást nagyon könnyen megvalósíthatunk magunk is. Nyilván nem lesz hozzá szép webes felület, nem fog integrálódni semmibe, nem lesz hosszú távon költséghatékony stb., cserébe csekély kezdeti befektetést igényel.

Egy lehetséges megközelítés az alábbi:

  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).
    • Csak nehogy az legyen a baj, hogy mondjuk a jelzőfile létrehozása a szolgáltatással össze nem függő ok miatt kicsit késik...

Természetesen a jelzőfile-okat akár ki is lehet hagyni; lehet minden egyes monitorozó alfeladat egy-egy runit-service, amelyeknek a futását így a runit ütemezi (a scriptben elhelyezett sleep paranccsal "finomhangolható" a futás gyakorisága). Ha a script hibát észlel, riaszthat vagy beavatkozhat (például kritikus hibára utaló üzenetek logbeli megjelenése esetén újraindíthat egy másik szolgáltatást).

Fontos megjegyezni, hogy ezek a megoldások általában nem jók abban az értelemben, hogy hajlamosak törékenyek, esetlegesek és aluldokumentáltak lenni; az utódunk nem biztos, hogy áldani fogja a nevünket, amikor megpróbál rájönni, miért indul újra ez vagy az látszólag minden ok nélkül... Másfelől viszont, ha nem akarunk nagy és összetett monitorozórendszert, vagy valamelyik konkrét részfeladatot a monitorozórendszerünk nem tudja értelmesen megoldani, ne feledjük, hogy shellscriptekkel így vagy úgy szinte bármi megoldható. :)

[szerkesztés] 4 Buktatók

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

[szerkesztés] 5 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.

[szerkesztés] 6 SNMP

Írta: Gellén Áron

[szerkesztés] 6.1 Az SNMP(Simple Network Management Protocol) modell alkotóelemei

[szerkesztés] 6.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.

[szerkesztés] 6.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.

[szerkesztés] 6.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.

[szerkesztés] 6.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
  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 kívá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

[szerkesztés] 6.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

[szerkesztés] 6.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ó.

[szerkesztés] 6.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

[szerkesztés] 7 Az SNMP agent beállítása (példa)

  • SNMP telepítés (pl. apt-get install snmpd)
  • SNMP beállítás (/etc/snmp/snmpd.conf szerkesztése)
    • Az SNMP agent alapbeállítása "paranoid" így nem lehet az adatokhoz hozzáférni. Ezt át kell állítanunk:
#sec.name source community
com2sec paranoid default public
#com2sec readonly default public
#com2sec readwrite default private
sorok átírása:
#sec.name source community
#com2sec paranoid default public
com2sec readonly default public
#com2sec readwrite default private
Megadhatjuk az(oka)t a címe(ke)t is, ahonnan az adatokat el kívánjuk érni (pl. localhost, cím, címcsoport):
com2sec local   localhost public
com2sec localNet 192.168.0.0 /24 public
    • "security name" csoportokba rendezése (az SNMP Group megadása kötelező minden olyan rendszerben, ami SNMP protokollt használ.)
#sec.model sec.name
group MyROSystem v1 paranoid
group MyROSystem v2c paranoid
group MyROGroup v1 readonly
group MyROGroup v2c readonly
group MyRWGroup v1 readwrite
group MyRWGroup v2c readwrite
sorok átírása:
group MyROSystem v1 local
group MyROSystem v2c local
group MyROGroup v1 localnet
group MyROGroup v2c localnet
group MyRWGroup v1 local
group MyRWGroup v2c local
    • nézet megadása a csoportokhoz (itt az alapbeállítás megfelelő)
#incl/excl subtree mask
view all included .1 80
view system included .iso.org.dod.internet.mgmt.mib-2.system
    • a csoportok és a nézet egymáshoz rendelése (itt az alapbeállítás megfelelő)
#context sec.model sec.level match read write notif
access MyROSystem "" any noauth exact system none none
access MyROGroup "" any noauth exact all none none
access MyRWGroup "" any noauth exact all all none
    • System Contact (rendszergazda elérhetőségei, stb.) - nem kötelező beállítani
#System contact information
syslocation Unknown (configure /etc/snmp/snmpd.local.conf)
syscontact Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)
  • SNMP daemon újraindítása (új konfigurációval)
#/etc/init.d/snmpd restart

Gellén Áron (BME-VIK)

Személyes eszközök