Üdv mindenkinek,
Sajnos átmeneti hálózati hiba miatt előfordul, hogy mínusz egy órakor üzen a nagios szolgáltatás elérhetetlenség miatt. A téves riasztásokat elkerülendő szeretnék egy olyan nagios megoldást találni ami a következők szerint működik.
Egy nagios szerver helyett legalább két nagios szerver figyelje a szolgáltatásokat és ha mindegyiken elérhetetlen a szolgáltatás csak akkor értesítse az adminisztrátort.
A neten nem találtam értékelhető megoldást...
Esetleg van valakinek ötlete a felvetéssel kapcsolatban? RTFM is jöhet dokumentum megjelöléssel.
A válaszokat előre is köszönöm.
- 2030 megtekintés
Hozzászólások
ha hálózati hiba van, a másik szervert is érintheti
nem is beszélve arról, hogy a két szerveren a lekérdezési időket hogy akarnád szinkronizálni?
- A hozzászóláshoz be kell jelentkezni
Nyílván ha több nagios szerver van akkor azok _nem_ egy hálózatban vannak pont azért, hogy a hálózati hibák kiszűrhetők legyenek.
A lekérdezési időket nem bisztos hogy szinkronizálni kellene. Talán elég lenne csak egy vizsgálat, hogy értesítés előtt megkérdezné a másik (többi) nagios szervert, hogy részükről mi az ábra a szolgáltatást illetően. Ha ott rendben van a dolog akkor nem kell értesítést küldeni. Ha nem éri el a másik (többi) nagios szervert akkor meg a kérdéses nagios szerver szakadt le a hálózatról ezért nem kell értesítrést küldeni.
De lehet, hogy ez az elgondolás fabatkát sem ér... ezért kérdezem itt, hogy hátha van megoldás.
--
maszili
- A hozzászóláshoz be kell jelentkezni
Clustert lehet csinalni, de nekem pl. nem tiszta, h mit is szeretnel.
Ha a teves riasztast akarod elkerulni, akkor dependeljenek a service-ek es a host-ok a halozat elerhetosegen (tipikusan gw).
Viszont ha valoban azt akarod, amit irsz, akkor a ket nagios hogy beszeli meg, hogy egyikukrol sem elerheto, ha koztuk nem letezik a kapcsolat?
Vagy arrol van szo, hogy van 3 halozat, 2-ben a nagios, a maradekban a figyelt service? Ezt a nagios-szal viszonylag nyogvenyelosen lehet megcsinalni tudtommal, nezd meg az incinga-t vagy a shinken-t.
udv,
tompos
- A hozzászóláshoz be kell jelentkezni
Köszi az infót a két ajánlott cuccot megnézem.
--
maszili
- A hozzászóláshoz be kell jelentkezni
Átmeneti hibákat 'eltakarhatsz' a soft-state-el is. Ezt a max_check_attempts és retry_interval paraméterekel szabályozhatod. Ettől persze a Nagios nagyobb késéssel fog riasztani.
Ja, és mi az a 'mínusz egy óra'?
- A hozzászóláshoz be kell jelentkezni
A mínusz egy óra az amikor nagyon-nagyon korán van még ahhoz, hogy számítógép előtt üljön az ember. :)
--
maszili
- A hozzászóláshoz be kell jelentkezni
Aha, BED timezone! ;)
- A hozzászóláshoz be kell jelentkezni
Persze, de ha _nagy_baj_van_ akkor természetesen be kell avatkozni bárhány óra is legyen...
--
maszili
- A hozzászóláshoz be kell jelentkezni
Nem világos még hogy miben is rejlik a probléma, mi ez az időszakos hálózat szakadás.
A nagios és a figyelt szolgáltatás külön-külön hálózaton vannak?
Mikor szakadás van csak a nagios esik le vagy minden?
Milyen hosszan tart az "átmentei" hiba?
A figyelt service tulajdonképp elérhető rendesen csak a hálózati szakadás miatt jön a jelzés, vagy ebben az időben a hálózat szakadás miatt a szolgáltatás sem elérhető?
Amúgy a hálózat szakadását, mégha átmeneti is, én nem nevezném rendes munkamenetnek, kivéve ha tervezett a dolog.
Amennyiben jól behatárolható hogy az "átmeneti" hiba mikor jelentkezik, akkor arra az időszakra akár más szabályokat bevezetni.
Esetleg több tényezőt figyelembe venni a riasztáshoz
- szolgáltatás nem fut, de van ping = azonnali riasztás;
- szolgáltatás nem fut, ping sincs a szerverre, de van ping egy független szerverre = azonnali riasztás
- Szolgáltatás nem fut, ping sincs a szerverre és egy másik független szerverre sincs ping = várjunk 2 percet az első észleléstől és ha letelt és még gáz van mehet a riszatás a hálózat elérhetetlenségéről.
-Mr-
- A hozzászóláshoz be kell jelentkezni
A probléma abból áll, hogy jelenleg egy bérelt kis virtuális gépen fut egy nagios és nem ritkán előfordul, hogy a nagios nem éri el a monitorozandó szervereket. Sajnos volt olyan is, hogy több mint egy óráig egyáltalán nem volt elérhető a virtuális gép amin a nagios futott, még ping szintjén sem.
(Ja és ez egy másik virtuális gép mert az előző teljesen használhatatlan volt. http://hup.hu/node/100767)
Ezért gondoltam arra, hogy egy másik szolgáltatónál is bérelhetnénk egy VM-et ahol szintén egy nagios figyelné a szolgáltatásokat és ha megoldható akkor valahogy össze kellene kapcsolni a két nagiost.
--
maszili
- A hozzászóláshoz be kell jelentkezni
Van egyszer a check_nagios.
Aztán van az nsca, ami helyben futkos és küldi az infót a nagios szerveredre.
Másrészt, ha a nagios timeoutra fut, akkor vajon bármilyen más dolognak van még értelme? Azonkívül, hogy a gép uptime értéke folyamatos működést mutat (azt mutat?), kintről feltehetően nem csak a nagios válik elérhetetlenné, hanem gondolom az összes többi szolgáltatás is, pl ssh.
Lehet futtatni munin-t is helyben, ekkor vissza tudsz pár dolgot nézni utólag, mi akadhat, aztán abból eldönteni mi a teendő.
- A hozzászóláshoz be kell jelentkezni
Akkor ha jól értem a nagios nem elérhető ami virtuálisan fut. Hogy küld riasztást az a virtuális szerver ami épp elérhetetlen?
Ha később küldi a riasztást, mikor már helyre állt a rendszered, akkor annak nincs értelme.
Én első körben gyorsan váltanék szolgáltatót, ha ilyen pocsék a szolgáltatása.
-Mr-
- A hozzászóláshoz be kell jelentkezni
Egyrészt gondolkodj el ezen. Nem cluster, de több szerver együttműködése a célja.
http://dnx.sourceforge.net/
Másrészt passzív checkekből építhetsz logikát.
Pl. mindkét szerver vizsgálja a szervizt és az állapotát beállítják egy passzív checkben a másik szerveren is. Ha véges időn belül nem állítja senki, akkor riaszt. Az elemi állapotokra meg nem kötsz riasztást.
- A hozzászóláshoz be kell jelentkezni
Ha máshonnan is akarsz nézni egy szolgáltatást, de a két monitorozó gép közötti hálózati kapcsolatban biztos vagy, akkor nézd meg az NRPE-t is.
- A hozzászóláshoz be kell jelentkezni