Network monitoring progik, mik a tapasztalatok?

Linux-haladó

UPDATE: átraktam a Linux-haladóba a topicot, mert nem csak CentOSra érvényes.

Azokhoz szólna a kérdésem, akik használnak aktív vagy passzív network monitoring progikat. Mik a tapasztalatok?

A Munint ismerem és használom is, de az főleg passzív monitorozásra és időbeli nyomonkövetésre jó, nekem valami aktívabb megoldás kéne.

Amik érdekelnének:
- Nagios
- Zenoss Core
- Icinga
- Pacemaker (cluster esetén)
- bármi, ami eszetekbe jut

Amik ezekkel kapcsolatban érdekesek nekem:
- mennyire bonyolult telepíteni és karbantartani őket?
- mennyire sok erőforrást vesz el a működésük?
- mi a minimum beállítható ellenőrzési intervallum host és service availabilityre? (pl. van-e olyan, ami tud 1 percnél kisebb felbontást)
- vagy: mennyire azonnaliak a riasztások?
- vannak-e bennük triggerek és mennyire szabadon állíthatóak? (vagyis pl. egy adott hálózati esemény bekövetkeztekor csak értesíteni tud, vagy esetleg el tud-e indítani scripteket, stb)
- van-e olyan köztük, amelyik agenteket is használ a megfigyelt gépeken, hogy még instantabb riasztások is elérhetőek legyenek (pl. gépen belül figyel vmilyen processzt, vagy figyeli, hogy shutdown/reboot állapotba kerül a gép)

Köszi!

  • 10021 megtekintés

( GCS v | 2014. 05. 23., p – 11:29 )

Vedd észre hogy egymással össze nem illő dolgokat írtál össze. Nagios teljesen más funkciót lát el mint a Cacti.
Icinga meg kimaradt, pedig érdemes beletenni a kalapba.

Nagios és Zenoss is pénzes szoftverek, az alap funkciók ingyenesek és nyilt forráskódúak. Idő és energia beletanulni a helyes beállításaikba. Egyik sem skálázódik valami jól. Minél több gépet monitorozol, annál lassabban fogsz észrevenni egy-egy beálló változást.
Nagios kiegészítő projectjeinek olvass utána: nconf és nagvis.

Nálunk a Nagios-t használtuk először és meg is maradt. Egyéb megoldások már nem adtak annyival többet hogy érdemes legyen a teljes rendszert cserélni. Ne értsd félre, ettől még nem teljesen kiforrott, stabil rendszerről van szó. :(

Dolgoztam olyan Nagiossal amiben ~1200 figyelés futott, számos node-on szétszórva az agentekkel.
"Egyik sem skálázódik valami jól. Minél több gépet monitorozol, annál lassabban fogsz észrevenni egy-egy beálló változást."
Erről tudsz még valamit mondani? Csak érdekel..

--
arch,xubuntu,debian,windows,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Megnéztem, nekem csak hatszázharmichárom figyelés megy (max valamivel több, ha azokat nem vettem észre).

Nekem úgy tűnt és talán olvastam is valahol, hogy a szerver egyesével, sorrendben kérdezgeti le a monitoring klienseket. Ha pl lassú a hálózat vagy sok (legyen ötezer+) figyelésed van, akkor idő amíg elér a végére és újból elkezdi nézni a klienseket. Rákeresek.

ahogy én tudom, mind host-okra, mind service-ekre meg lehet adni a teljes "kör" idejét.
ha van 60 host-od és 300 sec az idő, akkor 5sec-enként fogja indítani a lekérdezést (ha még van szabad slot rá). De a 300sec-t leveheted 120-ra is.

vagy rosszul tudom?
MAXIMUM SERVICE CHECK SPREAD
# This variable determines the timeframe (in minutes) from the
# program start time that an initial check of all services should
# be completed. Default is 30 minutes.

# MAXIMUM HOST CHECK SPREAD
# This variable determines the timeframe (in minutes) from the
# program start time that an initial check of all hosts should
# be completed. Default is 30 minutes.

Mindkettő azt jelenti az olvasatomban hogy ennyi időnként fogja újrakezdeni a szolgáltatások / gépek újbóli ellenőrzését. Viszont ahogy írod is, "ha még van szabad slot rá" - azaz semmi nem garantálja hogy be is fejezi azokat ezen időn belül. Amennyiben igen, akkor persze kivárja a hátralévő időt (alapban harminc percből ami még maradt). Ha meg nem, akkor rögtön újra kell kezdenie az ellenőrzéseket. Ebből adódhat a folyamatos magas load és memória használat.
Azaz sok gép és/vagy lassú hálózat kitolhatja a szolgáltatás / gép ellenőrzés köridejét ezen értékeken túl, folyamatos ellenőrző működésre kényszeríve a Nagios-t.

Másik skálázódási probléma hogy nem tudok olyanról hogy kettő/több Nagios szervered lehetne és párhuzamosan mennének. Ha az egyik elhal, akkor a másik átvenné annak ellenőrzési feladatait is.

A végeredmény szempontjából teljesen mindegy, milyen politika alapján csinálja: minél több a csekk, annál több a cpu wait ideje, ami a sok rövid válaszra várásból jön össze.

Más kérdés, hogy ebből is következik valami: aki azt feltételezi, hogy akármilyen redundánsra és forkbombásra összegányolt szkriptek jók lesznek majd csekkernek, mert "lám lefut, és jó státuszt ad", az egy idő után megissza a levét.

Skálázódásról két leírást találtam.
Első rögtön azzal kezd, hogy vegyél egy erőteljes szervert mielőtt nekiállsz: http://www.rundeconsult.no/?p=28&lang=en
Második arról ír hogy két gépe van, 400 - 400 figyeléssel. Load állandóan 1.5-ön, memória használata változó, de eszi rendesen: http://www.devco.net/archives/2013/01/01/scaling-nagios-nrpe-checks.php

nrpe, nsca, aktív-, passzív check
Összegzett, nagytömegű státuszt kaphatsz (nsca), kérhetsz (nrpe) egyben. Akár tűzfal mögé is benézhetsz 1-1 port lyukasztással és a mérés cpu terhét elosztod, a háló overheadjét csökkented. Fába szervezheted, a dependencia beállításával pedig a felesleges méréseket elkerülheted. Azt gondolom több módon is csökkenthető a terhelés.

Nekem most kb. 800 figyelés van egy nagiosba. Egy freebsd-n fut, ami egy virtuális gép 1 osztott maggal és 512 rammal. Az össz memóriahasználatot 100MB fölé menni még nem láttam, és soha semmilyen lassulást vagy késleltetést nem tapasztaltam...
--
The Community ENTerprise Operating System

maga a check_mk eleg hulyen mukodik, leginkabb a konfiguracioja hanyadek.
Ugy mukodik, hogy van minden szerverhez egy darab elore forditott python script, amit az icinga/nagios hivogat, mint active check. A script pedig beszelget az adott szerverrel, ahol lefutnak a checkek, es az eredmenyt a python script betolja az icingaba mint egy passive checket. Tehat 1000 szerver eseten 1000 aktiv checked van, hiaba a figyelt servicek szama 50k.
Persze meg lehet csinalni, hogy a node-ok maguk futtassak a checkeket cronbol, es a python script csak az eredmenyeket kerje el.
De csak pelda volt, hogy az icinga is lehet skalazhatobb mint 100 gep. Magat a check_mk-t nem javaslom jo szivvel.

Szerintem ez speciel a skálázódáson sokat nem segít. Az első doboz határait tolja esetleg kintebb (alarm karakterisztikától függően). Ugye a beérkező alarmot is fel kell dolgozni. Ez esetleg kevésbé költséges, illetve ritkábban kell csinálni ált.

Cserébe imho életveszély a passive check / snmp trap. Van, ahol van értelme, meg fel lehet készülni rá, hogy jó legyen, de alapvetően nem jó, ha a megfigyelttől várjuk, hogy szóljon ha baj van. Mi csak akkor használunk ilyet, ha nagyon muszáj.

Nem feltétlenül a megfigyelttől várjuk. A megfigyelések nem mindig olyan egyszerűek hogy pingre válaszol-e egy adott host. Pl. ha van egy több komponensű sw-rendszered, amiknek a moduljai több gépre vannak szétszórva, akkor az "él és funkcionál" fajta figyeléshez valamilyen intelligensebb progit kell irni, ami bedobja a golyót az egyik végén és megnézi hogy kiesik-e a másikon (érintve az összes hostot és modult). Ehhez szokott kevés lenni a nagios. A passziv checknél én ilyesmire gondoltam, pl. irsz erre egy javas kliens progit ami ha megállapitja a státuszt akkor bekiabálja a nagiosnak.

--
arch,xubuntu,debian,windows,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Ez nem passzív check, ez bonyolult check :)Mellékszál, de amire egyébként tökéletesen alkalmas a nagios, ha írsz javas progit, akkor a rettenetesen bonyolult APIt a nagios fele még nyugodtan beleírhatod (ezt passzív esteben is jobb így, mint wrapperrel), kb egy status kódod kell visszaböfögni stdouton, opcionálisan perfdatát key=value párokban. Aztán nyugodtan megtanítatod a nagiosnak, hogy ezt futtatgassa szépen aktív checkként. Ha kell, akkor nrpe-vel akár magán a figyelt tobozon is.

Az aktív és a passzív check között az a különbség, hogy a nagios az elsőt ütemezetten és biztosan leellenőrzi, a másiknál meg várja, hogy majd az agent szól, ha valami státusz változás van, addig meg úgy tekinti, hogy jó. Ez nem függ a futtatott ellenőrzés bonyolultságától...

Ráadásul te is írtad, hogy "A passziv checknél én ilyesmire gondoltam, pl. irsz erre egy javas kliens progit ami ha megállapitja a státuszt akkor bekiabálja a nagiosnak." ilyenkor a megfigyelttől várjuk (értem én, hogy nem ugyanaz a processz, de a nagios szempontjából az ugyanaz, absztahálj kicsit). És pontosan ez a baj vele: azért zöld, mert áll a szolgáltatás, vagy azért, mert a javas progi ráfutott valami bugra, amitől már két napja elcoredumpolt. Esetleg amikor lehalt a cucc, akkor épp nem volt hálózat, uh nem kaptál alarmot. Akár épp azért döglött meg, mert elment a háló, aztán az visszajött, de a szervíz nem tudott öngyógyulni. Szóval veszélyes terület ez. Körbe lehet bástyázni (lehet figyelni az ellenőrző processzt, lehet okos dependenciákat csinálni, stb), de azzal egy idő után az ember oda jut, hogy újra kell írni a fél nagiost.

Ettől persze még van, amikor bőven jó, de ha hűbele balázs módjára csinálja ezt az ember, hogy "van check, pipa", akkor előbb utóbb az lesz, hogy felhasználó fog szólni a monitoring helyett, az tuti.

Bár szerintem a nagiossal is sokáig el lehet skálázódni, mi op5-ot használunk, ami nagios csak összerakva egy rendes guiban rrdtoolal meg ilyesmivel, ill pár vidám extrasággal, pl rest api, ill tudnak elosztott működést, vannak pollernek nevezett dobozaik, akik egy-egy host group monitorozását átveszik, az eredményeket meg feltolják a masterre. Múltkor nekikszegeztük a kérdést, hogy ha az új renszerben sokszázas nagyságrendben telepítenénk pollereket, akkor mennyire fosná össze magát, és pre sales engineertől meglepően keretelés nélküli "menni fog" választ kaptunk. De jelenleg is fut nálunk szerintem 300 feletti host és 5000 feletti service check, és közelében nem vagyunk limitnek.

Egyébként fizetős, de 20 hosting ingyen van most azt hiszem. Illetve értelmes opensource cégként működnek, a nagios4ben már saját bevallásuk szerint igencsak benne van a kezük, ill pl a az elosztott cucc is elérhető náluk valami os licensze alatt.

( Fisher v | 2014. 05. 23., p – 12:17 )

Írd hozzá a zabbixszot.
A válaszok:
- nem nagyon (relatív)
- attól függ
- 1 másodperc (de persze a timeout általában ennél nagyobb)
- attól függ hogy email, sms vagy jabber (vagy mi)
- igen, vannak, lehet alert scriptet indítani
- van agentje és tudsz "kézzel" is küldeni adatokat a szervernek (pl. ha elkezd leállni, akkor kiált egyet)

+1 a Zabbixnak

A valaszokhoz egy kis kiegeszites.

Ha a legegyszerűbbet keresed akar HW szinten is megveheted, előretelepítve akkor csak az kabelezes marad rad, ha ennél egyel batrabb vagy akkor van OS szinten is amikor click click es kesz az egesz ott a webes felulet, ha ennél is bátrabb vagy akkor telepithed csomagbol na akkor egy par confighoz kezzel kell majd hozzanulyni meg a db backend is rad marad, ha meg hardcore vagy akkor újraforgatod magadnak ugy ahogy eppen neked tetszik.

HW igeny az van, de tudok neked eleg konkret peldakat mondani. Nekem pl most egy medium aws cucc futt es most 86 szerveren 24482 kulonbozo erteket gyujt be, ez alapjan 1661 kulonbozo triggert-et tud, es masodpercenket ~120 kulonbozo adatott gyujt be. Jah es a load nem volt 0,2 folott egy ideje.
De vannak extrem esetek is, szepen fel lehet skalazni. A csucs amit lattam az 9400 NVPS (new value per second)

Vannak specialis esetek ahol a masodperc ala is mehetsz, ha birod hatetertarral, nekem a fenti setup is 2TB adatott general evente, de amugy igen alapértelmezetten a masodperc a legjobb felbontas, viszont sokkal inkább a 30-60 másodperc az ésszerű es életszerű. Van olyan is amit pl csak napota egyszer gyujtok be ( ami id, kernel verzio, package verziok stb )

Ezt a mennyire azonnali a riasztast kerdes nem is igazan ertem, mert ez toled fugg, ha azt mondod hogy ha egy ping kimaradt mar sms-t akarsz akkor megkapod, ha azt mondod hogy csak 10 perc utan egy e-mail 20 utan meg egy text akkor ugy, ez total izles es beallitas dolga.

Sot nem csak hogy alert script van, de vannak függőségek it, szoval ismeri az események közti osszefuggoseket (megtanithatod ra), ha a tuzfal ledoglott akkor valoszinuleg a weblap sem futt arrol mar nem kerek riasztast stb.
Alapertelmezetten, az alabbi akciokat kerheted, alert, script (local) script ( remote )

A fent emlitett azt ugy hivjak hogy active agent, es viszonylag limitalt a hataskore de amig futt addig eleg sok okos dologot meg tud csinalni.

Jopar eve hasznalom, es en meg vagyok elegedve.

+1 a Zabbixnak részemről is

Szerk.: közben láttam hogy megoldódott a probléma valamennyire pár hónapja (amiről sírtam fél oldalt az imént), mindenesetre ezt nem árt azért elolvasni:

https://support.zabbix.com/browse/ZBX-7494

Eredeti, már lezárt ticket:

https://support.zabbix.com/browse/ZBXNEXT-341

oké, két versenyzőt hagytam meg a végére, az icingát és a zabbixot. ez utóbbi a szimpatikusabb.

viszont amit nem találok, az az, hogy hogy tudja értesíteni egy megfigyelt gép a zabbix szervert, hogy éppen shutdown-ra készül, illetve, hogy megvolt a boot. zabbix_sender egy init.d scriptbe?

meg még egy gondom van. NFS miatt nagyon fontos lenne, hogy amikor az a gép, ami a zabbixot is futtatni fogja -- egy minicluster fejeként működő gateway szerver -- shutdownba kerül, még ki tudjon szólni a belső hálón levő gépeknek, hogy ideje lenne unmountolni az nfs share-eket... gondolom ez már a zabbix hatáskörén kívülre eső dolog, és oldjam meg, ahogy tudom :)

Igen, én a zabbix_sendert használnám erre a célra.

Az alap template-k tartalmaznak egy olyan triggert ami akkor élesedik amikor a gép elindul (azt nézi hogy az uptime az kisebb-e mint legutóbb volt: {Template OS Linux:system.uptime.change(0)}<0 )

Az NFS umountja valóban egy más kérdés.

+1 a zabbixnak

"viszont amit nem találok, az az, hogy hogy tudja értesíteni egy megfigyelt gép a zabbix szervert, hogy éppen shutdown-ra készül, illetve, hogy megvolt a boot. zabbix_sender egy init.d scriptbe?"

ezt nem értem, miért kellene szólnia?
(re)boot után az uptime nullázódik, ezt a zabbix szerver észreveszi, trigger generálódik, megy a levél
és a ping is kimarad párszor, mire újra él a figyelt kliens, tehát előbb jön a pingről az értestés, majd később a restartról szóló, mert azt ritkábban nézi

azért, mert a belső gépek állapotától függően akarom a gateway-en csücsülő nginx konfigját megváltoztatni. most úgy néz ki, hogy lesz két appszerver (ami csak php-fpm-et futtat, a site-ok php fájljai és a website által használt fájlok NFS-en jönnek a gatewayről), és egy db/memcached szerver (aminél nem kell nfs-t mountolni). írnék egy scriptet, ami a belső hostok állapotának a függvényében dinamikusan pakolja össze az nginx konfigját:
- ha egy appszerver sem érhető el, akkor STATUS_CRITICAL
- ha valamelyik appszerver nem érhető el, akkor STATUS_SLOW
- ha a db/memcached szerver nem érhető el, akkor STATUS_CRITICAL
- ha mindegyik szerver elérhető, akkor STATUS_OK

STATUS_CRITICAL esetén egy "műszaki probléma" statikus oldalt adna vissza minden dinamikus (php) webes kérésre. STATUS_SLOW esetén a php-fpm poolt úgy rakja össze, hogy csak a működő appszervereket tartalmazza. STATUS_OK esetén pedig a php-fpm pool összes gépét tartalmazná a pool.

a gateway (és egyúttal a zabbixot/icingát is futtató) gép rebootja esetén pedig még az NFS mountok megszűnése előtt kell szólnom az appszervereknek, hogy lőjék le a php-fpm processzeiket és unmountolják az NFS mountot, hogy ne akadjanak be.

Ezt én úgy csinálnám inkább, hogy a zabbix ellenőriz egy weblapot, és ha az ellenőrzés nem a megfelelő adatokat adja vissza, akkor úgy dönt, hogy ez a szerver kampeca.

A weblap akár egy .php is lehet, ami OK-t ad vissza ha minden remek.

https://www.zabbix.com/documentation/2.0/manual/web_monitoring

Van olyan, hogy zabbix_send, faék egyszerűen tudsz vele "üzenni", de... Amit te szeretnél (konfigot turkászni backend-ek állapotától függően) az nyeharaso ötlet. Szerintem... A "backend-ek figyelése, és ha egyik sem megy, akkor "szerelünk" oldalt adni" feladatra talán az nginx is rávehető, de hogy egy haproxy-val ez nagyjából nulla munkával összehozható.
A gw/nfs-szerver reboot esetén meg ugye nem lesz, ami a backend-ekre tolja a forgalmat, de az nfs-szerver leállítása előtt yool oda lehet szólni például ssh-n a klienseknek (kulcsos auth, kulcshoz rendelt parancs), hogy most szépen tessék leállítani az alkalmazásokat és lecsatolni az nfs-t, bár én ezt nem automatizálnám(!), mert a visszabootolás után az nfs-szerver indulása és az nginx/haproxy starja között meg a backend-eket arra kell utasítani, hogy nfs mount és alkalmazás start. Minthogy értelmes esetben az ilyen reboot az adminisztrátor által felügyelt folyamat (ha elhasal, akkor meg úgyis mindegy...), így egy ilyen szintű automatizálás nem biztos, hogy szükséges.

bezony, a dinamikus pool management csak a fizetős nginxben van. ráadásul ha arra hagyom ezt a fajta funkcionalitást, akkor az nginxhez kötöm magamat, amit nem szeretnék megtenni.

viszont a varnish/haproxy megoldás sem működik. nagyon egyszerű hajigálni a szervereket 1-1 feladatra, de mivel kis cég vagyunk, ezért tényleg költség- és hardver-hatékonyan kell megoldanunk a kiszolgálást.

a jelenlegi és várható forgalom mellett nincs szükség újabb absztrakciós layerre, ugyanis a statikus fájlokat így is az nginx fogja a gateway gépen kiszolgálni, lokális fájlrendszerből (így megvan a sendfile() és a memóriába cache-elés előnye plusz gépek nélkül), a dinamikus oldalakat meg amúgy is a php-fpm-ek állítanák elő. a haproxy és a varnish is csak két dologra lenne jó: a forgalom széjjelosztására (de nincs hova, csak egy webszerver van ebben a rendszerben), illetve a tartalom cache-elésére (amiknél meg csak a statikus fájlokat lehetne cache-elni, a php-t igénylő oldalak tényleg dinamikusak, usertől, logintól és időtől is függenek; a statikus fájlokat meg így is megfelelő tempóban nyomná ki az nginx), és ugye ez alapján értelmük most semmi nem lenne.

mivel végül is csak -- kezdetben -- négy gépet kéne monitorozni (és a közeljövőben sem látom úgy, hogy 8 gép fölé emelkedne ez az igény), lehet, hogy passzív monitorozásra a jelenlegi munin is bőven elég lesz. az aktív monitorozásra és state-checkekre, és az ez alapján történő parancskiadásokra és konfig-változtatásokra meg írok pár saját scriptet, és meg is oldottam a dolgot... :)

persze saját cucc helyet jobb lenne egy meglevő megoldást használni, ezért is ez a téma.

erre gondolsz, gondolom: http://grey-boundary.com/scaling-via-php-fpm-clustering/

ami majdnemhogy az, amit mi akarunk összehozni, csakhogy:
- a SEO-friendly URL-ek miatt kell valamiféle mod_rewrite támogatás, de abban az nginx megfelelő konfig mellett jobb teljesítményt nyújt,
- a statikus file kiszolgálásban a mod_php nélküli apache és az nginx jobbára ugyanolyan teljesítményt nyújt,
- az apache-ban viszont nincs rendes fastcgi pool kezelés, az nginxben van,
- ezért lesz a fronton nginx,
- egy haproxyt berakni azért, hogy a fastcgi pool kezelése hibatoleráns legyen, az nekem veszélyesen hat teljesítmény és megbízhatóság szempontjából -- relatíve nagyon ritkán esne ki egy-egy appszerver,
- és ebben még nincs benne a mysqld/memcached szerver figyelése, ugyanis, bár persze az megoldható lenne, hogy a php scriptek adják ki a "műszaki probléma" oldalt, amíg nem érhető el bármelyik service, a lényeg az lenne, hogy addig ne is fussanak olyan scriptek, amik megpróbálják elérni bármelyiket.

erre nálam tényleg csak az jön ki, hogy a legegyszerűbb az nginx konfigját dinamikusan változtatni.

Az fe: haproxy, ez fogad mindent, és dobál szét fastcgi pool-ra amit kell, illetve a lokális (statikus tartalom) nginx-re, ami oda kell. A DB/memcached kiesését kezelje az alkalmazás. Ha csak 2-3 konfigod van,amiket csereberélni kell, akkor egy symlink cseréjét bele lehet hegeszteni (ezzel a hely, i-node elfogyása okozta probléma kilőve) egy saját scriptbe - úgy. hogy a script csak egy példányban futhasson.

jó, hát azt én sem gondoltam, hogy egy idegbeteg, mindenre azonnal reagáló módon kezelném a monitorból bejövő adatokat, azért hagynék egy grace periodot (2-3 perc) arra, hogy helyreálljon az adott szerver, mielőtt konfigot változtatnék.

valahogy úgy gondoltam a dolgot, hogy a belső gépeken futna egy aktív health check minden percben -- a php-fpm-eseken a php-fpm-et ellenőrizné, a db-n meg a mysqld-t és a memcached-et --, és az eredményét egy kulcsos ssh kapcsolatban átnyomná egyszerűen egy fájlba a gw szerveren (a fájl tartalma meg OK vagy ERROR, ennyi). a gatewayen meg egy cronos script futna le minden percben, ami átnézné ezeknek a fájloknak a tartalmát, meg a timestampüket. ha a timestamp mondjuk három percnél régebbi, akkor feltételezhető, hogy a küldő szerver lehalt, így automatikusan ERROR lenne a tartalma. ez alapján össze tud állítani egy általános network állapotot, ami alapján már lehet konfigot változtatni. fontos még az is, hogy össze kell hasonlítania az új állapotot az előzővel, és ha nincs változás, akkor ne írja meg újra a konfig fájlt.

a trükk ott van, hogy tényleg be kell vezetni valami grace periodot, hogy ne induljon csak úgy újra az nginx a gatewayen. mondjuk hogyha a legutóbb összerakott konfig legalább 3 perces, akkor induljon csak újra azzal.

No ez az... Így lesz jó esetben 2-3 perces "félig működik" állapotod, ha az egyik backend kihullik valamilyen okból. És ha bármilyen(!) hiba történik, akkor belerúgsz az nginx-be, ami a kiszolgálást végzi - ami a szolgáltatás minimum "döccenését" okozza. Ha meg netán maga az nginx kezelne session-t, akkor meg kell nézni (nem tudom, hogy van), hogy bármilyen ilyen infó megmarad-e a szerveren? Vélhetően nem fog.
A konfig-fájlok másolása/mozgatása nem jó (bármilyen okból elfogy a hely pl.), ha mindenképp ezt az irányt választod, akkor használj simlinket, és a mögötte lévő konfigfájl kapjon egy touch-ot, az átlinkelés után.

1. nginx-nek van egy nagyon soft restart módja, nginx -s reload asszem, ami a SIGHUP-nál is finomabb átállást tesz lehetővé, így az újraindulás nem döccenésszerű lenne. http://nginx.org/en/docs/beginners_guide.html

2. nem az nginx fogja a session-t kezelni, hanem a php-fpm. az pedig memcached-et fog a sessionök tárolására használni, ami más gépen lesz, mint akár a gw, akár az appszerverek.

3. a konfig symlinkelés viszont tetszik, jó trükk a touch-olás is, hogy lássa a változást, így fogom csinálni. köszi!

az in-cluster gépeken aktív monitorozást fogok csinálni, ma megírtam a scriptet, és nagyon pöpecül megy, még scp-zi is az eredményt natívan. :) holnap jön a MCP megírása, hogy a tront idézzem.

Ez egyszerűen megoldható varázslás nélkül. Nginx 50x-es hibaoldalakra megadsz egy szép statikus karbantartásoldalt, amit szeretnél. Upstream-nek megadod a két appszervert. Ha az egyik nem érhető el, akkor arra nem küld forgalmat, ha egyik sem érhető el, akkor 502-t ad, aminél a szép hibaoldal jön be. Ha a db, vagy memcache nem érhető el, akkor az alkalmazás dobjon 500 errort, amire szintén a szép hibaoldal jön be.

Valami ilyesmi:

error_page 500 502 503 504 @500;

location @500 {
root /path/to/error/pages;
rewrite ^ /karbantartas.html break;
}

upstream fpms {
server 1.2.3.4:9000 weight=10;
server 1.2.3.5:9000 weight=10;
keepalive 8;
}

...
fastcgi_pass fpms;
...

A monitoring erre a célra való használata teljesen rossz irány. Trükkös szkriptek írása is rossz irány, mert egy idő után karbantarthatatlan lesz, ha már te is elfelejted, hogy mire is készült (másnak meg szép feladvány lesz). Az nfs-t is inkább felejtsd el, mert csak szívás lesz vele. A "ne akadjanak be" dolog ugyan elkerülhető bizonyos beállításokkal, de attól még ideális nem lesz.
Ha a hibaoldalakat nem ötszázas hibakódokkal szeretnéd kiszolgálni, akkor az seo szempontól elég rossz tud lenni.

( pdx | 2014. 05. 23., p – 12:37 )

elolvasva az icingat, azt nem tudom kideríteni, hogy az icinga2-n kész van-e már, akármilyen szinten az agentes rész. esetleg valaki erről tud valamit? illetve, icinga1-en megy az agentes monitorozás is? (a feature table szerint igen, de azért jó lenne valami realworld tapasztalat is.)

( cala | 2014. 05. 23., p – 13:33 )

OpenNMS? Elég jól beállítható, alapban van discovery a megadott IP tartományra. Kb. másfél éve használjuk, elég jól tanítható és testreszabható.

XML -ben konfigolható elég szabadon, ha nem tévedek az SNMP poll-t akár 1mp -re is állíthatod. Nagios agent-ek is mennek alatta, riasztani elég gyorsan tud (pár másodperc), jogosultságkezelés a használathoz, valamint szép színes grafikonokat rajzol a főnököknek és rendelkezésre állást is számol.

( o_O v | 2014. 05. 23., p – 13:27 )

Mi fizetos megoldast hasznalunk ServerDensity alap pluginok + nagios pluginek ( ezeket tudja hasznalni ). Fizetos de nekunk bejott.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

( ncc1701 | 2014. 05. 23., p – 15:55 )

Nálunk icinga fut, ~40 host, ~400 szolgáltatás.

-így utólag, a mostani tapasztalatommal egyátalán nem bonyolult annyira. :)
-fenntihez elég egy hp microserveren futó virtuális gép 1G memóriával, kevés lemez mérettel.
-passz. Defaultból úgy ütemezi magát, h 5 percenként fut körbe. Nekem ennyi elég.
-monitot kipróbálhatnád, ezzel lehet automatikusan birizgálni a gépeket ilyenolyan feltételek teljesülése szerint.

Összességében nekem nagyon bejött. Linuxakadémiás icinga videot melegen javaslom, ha mellette döntesz. Anélkül horror lesz a beálltás...

Szerk: ugyanazon a vm-en fut a munin is. Asszem 1 körüli loadja azért megvan. És nem a memória kevés, mikor a munin lekérdez, akkor 100%-on pörgeti a procit. Icinga minimális erőforrást kér nálunk, de ez nem egy nagy üzemi felhasználás.

( mr shadow v | 2014. 05. 25., v – 20:42 )

Nálunk a legutóbbi rendszer integráció során ~4800 check került a nagiosba, jórészt nsca-val küldve be, disk io azért így már egész jelentős, sok kis fájl, de a fő terhelést a gépen így se a nagios okozza ;)

--
>'The time has come,' the Walrus said<