Üdv!
Igen nagy, és kiterjedt rendszer monitorozását ttervezzük megoldani Zabbix-szal.
Remek funkciók, parasztvakító felület, meg minden...
Viszont nem jutok dűlőre a szülő-gyermek viszonnyal.
A cél:
Ha ledöglik a switch, akkor 1db riasztást kérek arról, hogy ledöglött a switch, és nem akarok további 48 mail-t kapni azért, mert a mögötte lévő 48 szerver nem elérhető.
Ami nem ment:
A szerver elérhetőség trigger dependency mezőjében kiválasztom a switchportot, de nem működött, ha kihúztam az UTP-t, ugyanúgy jött a risztás.
Megpróbáltam a trigger feltételébe beleírni ilyet:
csak akkor riasszon, ha elérhetetlen, ÉS adott switchport up.
Ezzel két probléma volt:
1: a host triggere nem szerkeszthető, csak teplate-ben, de az mindenre érvényes lenne.
2: ha már template, akkor ott nem hivatkozhatok host tulajdonságra.
Kérdés:
- Körbe lehet valahogy hack-elni a dolgot hogy működjön is?
- Tényleg nincs egyszerűbbb mód, vagy csak nem olvastam eleget?
Hozzászólások
A switchport státusza már pozor volt amikor a gépekről is jött még a riasztás? Ez csak tipp :D
A template függőségénél ki tudod választani hogy melyik portra kell figyelnie. Ez portonként más template-t jelent (2.2-esem van, de a 3-asban már lehet hogy okosabb ez is). Ha másképp nem, egymásba ágyazással talán lehet normálisan kezelni.
Ezen a vonalon nem okosabb. :)
És 100+ szerver, és további sok-sok switch/router stb között ennyi taemplate-el nem játszanék.
Lentebb megvan mi lesz a módszer.
Köszönöm.
---
"A megoldásra kell koncentrálni nem a problémára."
Én ugyan amit lehet, template-tel csináltam meg, de te látod hogy melyik a járható út. Nekem úgy van, hogy kb. egy router és ahhoz képest sok host. A switcheket nem is tudom monitorozni :D
Nem értem teljesen, péntek van. De a probléma#1 szemet szúrt. -> Template-ből származó triggert helyben klónozod, local újat szerkeszted, a template-t letiltod.
Igen, ide jutottam magam is végül.
---
"A megoldásra kell koncentrálni nem a problémára."
Megoldva.
Egyedi triggert külön létrehozhatok a hosthoz. Azt szerkeszthetem is.
Ez az új trigger ugyanolyyan, mint ami azt figyeli elérhető-e a hoszt, de ezt már kiegészíthetem a switch-re vonatkozó feltétellel.
Az eredeti triggert pedig letiltom a hoszton.
Ez ugyan hostonkénti macera, de működik.
Ha valaki tud egyszerűbb utat, azt szívesen veszem.
---
"A megoldásra kell koncentrálni nem a problémára."
Nem tudom, szebb-e, jobb-e, gömbölyűbb-e, de én a következőre gondoltam - jelzem, még nem követtem el:
- a template-ben definiálok egy makrót, legyen a neve $PARENT_UP és az alapértelmezett értéke TRUE
- az eredeti triggert kibővítem, hogy az eredeti feltétel *és* $PARENT_UP
- innen kezdve a nem direktben monitorozott gépek esetén ezt a makrót átírom, hogy ellenőrizze a szülő elérhetőségét
Előny, hogy nem kell külön trigger - de igazából a hostonkénti macera nem úszható meg vele. Illetve ebben sem vagyok biztos, mert lehet az sem rossz megoldás, hogy a template-ben nem definiálom a makrót, viszont létrehozok új template-ket, amelyek összesen a $PARENT_UP makrót definiálják, de a nekem tetsző módon. Ezek után minden géphez hozzá csapom azt a templatet, amely a neki megfelelő makrót definiálja. Példa:
template name --- makro
NO_PARENT --- TRUE
SWPORT1 --- swp1:agent.ping.nodata(6m)=1
SWPORT2 --- swp2:agent.ping.nodata(6m)=1
...
Az sem utolsó, hogy ha megjelenik a nagyszülő, akkor az is kezelhető ezen a módon: a makró egy összetett feltétel, amely mindkét eszköz elérhetőségét ellenőrzi.
"jelzem, még nem követtem el"
Én megpróbáltam. Template triggerében nem hivatkozhatsz konkrét host-ra. Azt csak a host egyedi triggerében teheted.
Ami egyébként nem is logikátlan...
---
"A megoldásra kell koncentrálni nem a problémára."
Mi azt csináljuk, hogy lekérdezzük a zabbix adatbázisából SQL szinten az aktív triggerek listáját, ebből generálunk hasht amit monitorozunk egy külön zabbix odbc item-ként, és ennek a változására riasztunk. Így ha beesik 30-40 alert fél perc alatt, akkor is csak 1-2 riasztás generálódik, illeve ha változik a riasztási lista, akkor is kapsz plusz értesítést. A riasztás maga is egy saját szkript, ami pedig zabbix API-n kérdezi le az aktív triggereket, hogy valami értelmes infó tudjon kerülni az SMS/emailbe.
Ez tetszik... :)
Az elvét értem, a megvalósításához lehet hogy előbb-utóbb teszek fel privátban kérdéseket.
De először menjen frankón az alap rendszer, a woodoo majd akkor ha az alap hiányait pontosan felmértük.
Köszönöm.
---
"A megoldásra kell koncentrálni nem a problémára."