Zabbix 3.0 szülő-gyermek viszony [MEGOLDVA]

Ü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.

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.

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."