Éjjel riasztott az Icinga 2, hogy egy hosttal baj van. Majd öt perc múlva már jött is a RECOVERY e-mail, hogy a szerver helyreállt. Kb egy órára rá, ugyanaz a szerver ismét elérhetetlenné vált, jött is az újabb ALERT e-mail. Öt perc múlva ismét helyreállt. Az icinga webes felületén zöld is lett a státusza, de RECOVERY e-mail értesítés már nem érkezett. Egy ideig még flip státuszban maradt a szerver, majd azóta is stabilan OK.
Megnézve az icinga naplóit, nem látom nyomát annak, miért nem küldte el a második RECOVERY e-mail-t. Debug logolás nem volt bekapcsolva. Most kapcsoltam notification debug-ot, de nem tudom, ez elég lesz-e egy hasonló ilyen esethez.
Megnézve az icinga szerverén futó exim naplóját, abban nem is szerepel a negyedik e-mail. Vagyis az icinga meg sem próbálta elküldeni a notification e-mailt. Egyébként több e-mail cím is van a contact groupban, egyikre sem ment ki a negyedik levél.
Ez ugyan nem akkora gáz, de mi van, ha egyszer ugyanez történik egy ALERT e-maillel?
Találkozott már valaki hasonló problémával? Netán tud is rá megoldást? Hogyan stabilizálható az icinga, hogy megbízható legyen? Vagy hogyan találhatom meg a hiba okát?
Megoldás: nem bug, feature
Hozzászólások
Mivel küldeted a levelet? A standard script-jével? Vagy módosítottál rajta?
Érdekel a problémád, mert kb hasonló cipőben járok: kopogjuk le eddig nem volt probléma, de tegnap "besárgultak" a szünetmentesek, mert ideje lenne az éves kalibrációnak. Erről kellett volna jönni valaminek, de nem jött. Most akarok nekiülni én is, hogy wtf. Október 30-al küldött utoljára valamit, azóta sok minden volt.
(Jó ez a cicinga, kb ahhoz a kocsihoz hasonlítanám, amit az ember hobbiból vesz: hétvégente vagy vigyorogva ótókáz vele, vagy elmélyülten bütyköli. De legtöbbször inkább bütyköli, mint ótókáz.)
Nem piszkáltam bele. Felvettem pár hostot, szolgáltatásokat, conatact e-mailek, és mehet. A konfigok egyébként még egy régebbi nagiosból származnak. Tehát teljesen fapadosan alap.
Icinga1-et használok aktívan, így lehet nem releváns amit írok, és egyébként is csak iránymutatást tudok adni.
A helyedben a flapping detection körül keresném a megoldást.
Nekem is gyanús a flapp, de nem találtam ilyen irányú beállítási lehetőséget. Úgy tűnik, ez a belső lelkivilágának a része.
Hm, nekem IcingaWeb-en ott virít a "Flap detection" nevű kapcsoló, minden hostnál. Igaz, ki van kapcsolva alapból, de mindjárt utána nézek, mivel lehet pl globálisan bekapcsolni.
Szerk: https://icinga.com/docs/icinga2/latest/doc/08-advanced-topics/ - "Check Flapping"
Gondolom globálishoz be kell vésned a generic host-ba.
Nem a flap ki-/bekapcsolását értettem beállítás alatt, hanem, hogy ennek függvényében küldjön-e e-mail-t vagy sem.
Lehet most nekem vannak téves elképzeléseim a rendszer működéséről, de a fejemben az van meg, hogy a FD megvizsgálja visszamenőlegesen n db check eredményét és ebből von le következtetést. Ezért nem értem, hogy milyen levelet vársz ennek függvényében? Ne küldjön levelet, mert csak "megszaladt" a ping a bedugult switch miatt? Vagy mire gondolsz?
Egyébként folyamatosan azon jár az agyam, hogy nálad valahol valamelyik folyamat "timeout-olt", nem futott le időben, egyik check a másikat érte, ebből lehetett gebasz. Apropó, pontosan melyik verzióról beszélünk a 2-esen belül?
Csak pinget monitorozol, vagy fent van a kliens is? (Szerény tapasztalatom monitoring terén az, hogy mindig előbb száll el a load, mint a ping. Teljesebb képet kapok a problémáról, ha látom előzőleg mi történt.)
Arról várok levelet, hogy visszaállt OK státuszba.
Értem.
Nem tudom. Én még mindig ott tartok gondolatban, hogy nem futott le időben a check, a következő beérte és felülírta. Legalábbis nekem ez az elképzelésem, hogyan működhet. Induláskor rögzíti a státuszt, lefut, kiértékel, vizsgálja, hogy volt-e változás, aminek függvényében ütemez egy riasztást. Ha erre ráfutott egy másik folyamat, simán belefér, hogy az rárögzíti a státuszt, amit utána az előző folyamat felhasznál kiértékeléshez. (és akkor már OK volt.) Ezért szokták írni a fórumokon, hogy jól válaszd meg az intervallumokat, meg a próbálkozások számát.
Igen, ezt elképzelhetőnek tartom. És annyiból megnyugtató is lenne, hogy ez a fajta hiba akkor csak RECOVERY esetén fordulhat elő, így az ALERT értesítéseket mindig meg fogom kapni.
A beállításokat nem tudom, én alapértelmezetten használom. Csak a monitorozott szolgáltatásokat konfiguráltam fel. Ha defaultban ez lehet rossz, akkor lehet rossz.
Én csak azt tudom javasolni, hogy frissítsd rendszeresen, amikor van új verzió belőle. Jócskán van még benne hiba, de folyamatosan javítják. Bár nincs némelyik official moduljához sem step-by-step leírás, de azért van benne potenciál.
-
Úgy tűnik, ez nem bug, ez feature.
Flapping esetén következetesen nem küldi el a RECOVEY értesítést ...
Ez kell neked:
https://icinga.com/docs/icinga-2/latest/doc/08-advanced-topics/#check-f…
Eztet mondtam én is.
Bocsi. Azon akkor automatikusan túllépett az agyam, mivel én nem a flap detektálását akartam megszüntetni/állítani, hanem azt, hogy ha lezárult, és visszatért normálba, akkor küldjön értesítést, hogy mán normális.
Még egy dolog nem világos nekem: akkor most pontosan milyen verziót is használsz? :)
Nekem nem rémlik ilyen eset, amikor nálam nem jött volna RECOVERY. Igaz a problémás gépeken terhelést is nézek. Ha baj van, 2-3 service-ről is jön riasztás, aztán most, hogy a 3-ból csak 2 RECOVERY jött, már nem tűnik fel.
Icinga 1.13.4
Hát, az már egy pár éve EOL, már megbocsáss :)
Ici 2-őt írtál a címbe, ezért amit írtam az mind a 2-esre vonatkozik és mint a matekban az 1 és a 2 közé itt sem lehet egyenlőségjelet tenni. Tudomásom szerint a két rendszer között igen nagy különbségek vannak, lévén, hogy az 1 az csak 1 nagios fork, a 2 meg már valami teljesen más. (Ami most 2.12-nél jár.)
Szerintem, - ha teheted - upgrade-elj. Én csak azt tudom mondani, hogy az Icinga2 az egy tök jó valami, ami tök jól működik.
Igen, látom már én is, hogy ez az 1-es. :( Előtte nagios volt, az egyszerűség kedvéért lett ez. Na, meg ez volt csomagban. Nem tudom, miért volt bennem az, hogy ez a 2-es. Sorry.