Zabbix architektúra - szerintetek ez megvalósítható?

Címkék

Egy atomvillanást is túlélő Zabbix topológián töröm a fejem. Az alábbi felállás szerintetek működőképes? (Tovább »)

= Egyik hálózat =

  [Datacenter 1]
  - host1 ---> zabbix-proxy1
  - host1 ---> zabbix-proxy2
  - host2 ---> zabbix-proxy1
  - host2 ---> zabbix-proxy2
  - hostN ---> zabbix-proxy1
  - hostN ---> zabbix-proxy2
  - zabbix-proxy-1 ---> zabbix-server

  [Datacenter 2]
  - host3 ---> zabbix-proxy1
  - host3 ---> zabbix-proxy2
  - host4 ---> zabbix-proxy1
  - host4 ---> zabbix-proxy2
  - hostM ---> zabbix-proxy1
  - hostM ---> zabbix-proxy2
  - zabbix-proxy-2 --> zabbix-server

= Másik hálózat =

zabbix-server <--- nézegető emberkék

Remélem érthetőre sikerült az ábra. :-)

A két adatközpont egy L3 tartományban van, de L2 -ben nem ér össze.

A gépek mind virtuálisak, mindkét adatközpontban vannak VM node -ok.

A fenti topológia értelme, hogy ha az egyik node megpukkan, és a rajta futó zabbix proxy leáll, akkor az adott oldal még élő gépei továbbra is megjelennek a zabbix server felületén, mert a másik proxy felé is elküldik az állapotukat.

Aztán persze, ha a proxy már felbootolt egy másik nodeon, (ami vagy sikerül, vagy nem, mert fsck, vagy database anyázás, vagy akármi miatt ami nem szereti ha tarkón lövik) akkor visszatér az életbe az adott proxy, de addig is jó lenne tudni, hogy mi halt még el vele, és mi az ami ennek ellenére zöld.

Elvileg egy agent tud küldeni adatot két külön zabbix proxy felé.

Az égető kérdés, amire a Google-n nem találtam választ (lehet, hogy PEBKAC):

  • A Zabbix szerver a két proxy -ról is megkapott, de ugyanazt a gépet ábrázoló (és emiatt abszolút redundáns) adatokat / állapotot jól kezeli vagy belezavarodik?

Mit tippeltek?

Szavazatok

Hozzászólások

Ez zabbix clusternek tűnik.  Pl. MySQL-nél az egyik node autoincrement értéke páros, másiknak páratlan, így sosem vesznek össze.

Zabbix tapasztalat viszont nincs, de engem is érdekel. Nagios/Naemon-t használunk és erősen gondolkozunk a váltáson.
A Naemon jól kezeli a duplikált OK adatokat. Ha eltérőt kapott egy hostról, akkor viszont prellezett. Gondolom a Zabbix is így tenne.

Használj két szervert két külön lokáción.

Ne is tudjanak egymásról, tehát ez nem cluster.

 

 

Korábban használtál már zabbixot?

Nagyságrendileg hány gépet kell monitorozni, azokon milyen alkalmazésokat, egyedi fejlesztéseket (alkalmazásszerver, adatbázis, ilyesmi)? Ugyanis nagyon-nagyon hasznos előbb megtervezni azt, hogy mit monitorozzunk, és utána eldönteni az eszközt, illetve a módszereket. Ha úgy kezded, hogy telepítés, majd a default template-ek használatával elkezded monitorozni mondjuk a Linuxokat (csak OS paraméterek), el fognak önteni a fölösleges adatok, és sokkal több szívás lesz kitakarítani azt, ami nem kell. (Tapasztalat...).

Összesen 3-400 gép, előre gondolkodva max 600 host.

90% Linux, de lesznek (vannak) Windowsok is.

Hozzá hálózati eszközök, meg néhány appliance, pl. IPS/IDS.

A meleg vizet csak egy kicsit szeretném feltalálni, ezért úgy tervezem, hogy a gyári módszereket használnám.

A hálózati eszközöket és az appliance -okat SNMP -vel tudom lekérdezni, a Linux és Windows hostokat pedig egyrészt a hivatalos Agent -ekkel, másrészt pedig támaszkodva egy már jól megírt speciális script halmazra, ami megnéz néhány speciális dolgot (pl. törölt de fel nem szabadult fileok, Meinberg kártya állapot, stb.) a gépen, abból fogok Zabbix kompatibilis kimenetet gyártani, amire szintén riaszthat, ha az általam generált kimenet nem zöld.

Az alkalmazás rétegpanaszait szeretném teljesen külön kezelni ettől, mert azt más csapatnak kell néznie, más SLA, más riasztási rend vonatkozik rá. Én most az infrára lövök, de ha ez beválik, akkor a jelenlegi app riasztásokat is lehet Zabbixosítani, nem zárkózom el előle, de hogy az ezen a szerveren fog-e átmenni, vagy dedikált Zabbix szervereken, azt még nem tudom, mert nem tudom, hogy erőforrásban, illetve a megjelenítésben hogyan lesz jobb.

Ha most egy olyan úton tudok elindulni, aminek az eredménye az amit várok, és hosszú távon sem vezet zsákutcába, akkor én már boldog vagyok. :-)

Sok. Mármint hogy ad-hoc nekilódilj csinálni valamit. Ha a standard Linux-os template-eket használod, lesz többezer semmire sem használt adatod. Tervezd meg, hogy milyen információkat "must have" monitorozni az egyes gépeken, illetve gépek adott csoportján, csinálj saját template-et, és azt "húzd rá" a gépekre - indulásként mondjuk 10-15 Linux-os meg Windows-os gépre, majd szelektálj tovább, ha szükséges, és az így kialakuló template-készlettel vágj bele az éles rendszer kiépítésébe. Első körben több meló, meg kevesebb "látványosság" - de bőven megtérül akkor, amikor az éles implementáció után nem az lesz a mindennapos feladat, hogy a zabbixból jövő csillió+1 e-mail alertet dobáld kifelé - miközben a marha nagy zajban elvész az a 2-3 üzener, amire asap reagálni kéne.

+1. (mondjuk ez nálam Icingával játszik, de az elv a lényeg) Amin még érdemes lehet elgondolkodni: leülni és egy doksiba/wikibe/akármibe bevésni, hogy melyik check mit figyel, ha X állapota van, akkor mi a teendő. Így ránézésre látni fogod, hogy mi az, amit feleslegesen figyelsz / feleslegesen riasztasz rá, abból, hogy nincs nála értelmes magyarázat / eljárásrend (nálam is van néhány check, ami simán statisztikát gyűjt, de kb. ha nem lángol a fél épület, azok sosem lesznek nem OK-k). És még csak bonyolult dolog sem kell: pl. van egy terminál szerverünk, ami szándékosan kicsire van méretezve, úgyhogy időnként picsog az icinga, hogy jajúristen fogy a hely... "Ha warningol és nem vagy patchelési időszak környékén, lépj be, delprof2, oszt jónap" [mert a régen használt profilokat csak újraindításkor hajlandó egyébként törölni]. Monitorozhatnám a gépben levő RAID kártya cache hit ratio-ját, rajzolgathatnék belőle színes-szagos grafikont, beállíthatnák rá riasztást, de értelme nem lenne: azon kívül, hogy lelövök mindent azon a gépen és ciklusban írok-és-olvasok egy cache méretű fájlt, túl sok értelmes dolgot úgyse tudok vele kezdeni (oks, grafikonra statisztikának érdekes lehet, pl. hogy lehessen mutogatni, hogy az újonnan beállított app lőtte lábon a cache-t és ezzel a régi cuccok alatt az IO-t...)

Volt kollégánál merült ki a monitorozás abban, hogy egy-két gépre (ahol eszébe jutott? nem tudom, nem sikerült mögötte a logikát megértenem) feltette a munint, ráeresztette a disztróból szállított összes plugint, hogy legyen sok-sok adata... amivel pont akkor nem ment semmire, amikor gond volt, mert ahogy zeller is írta, a nagy zajban elveszett a lényeges infó, a root cause helyett a már annak következményeként beálló kiugró értékeket kezdte vadászni (már amikor volt kiugró érték, mert ugye a gyári összes plug-in Murphy törvénye szerint pont azt nem tartalmazza, amire szükséged lenne :) ).

BlackY

"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Én kihagynám a proxykat, direktben szólongatnám a hostokat.

Ha a két datacenter között több a szakadás, mint szeretnéd, akkor két zabbix szervert futtatnék (mindkét DC-ben 1-1).

Mindkét zabbix-server csak a saját gépeit figyeli, és összekötném a kettőt, így a frontend egyben mutatná a két DC-t.

A frontend lehet egy olyan gépen, ami független a két DC-től, így ha megszakad a kapcsolat a két DC között, de a frontend mindkettőt látja egy másik vonalon (VPN?), akkor nem vesztettél semmit.

A szerver bár fizikailag az egyik adatközpontban van, de egy teljesen "másik hálózat" -ban. Ez a (mondjuk office) hálózat kevésbé védett, ezért innen nem kérdezhet be az "egyik hálózat" névre hallgató (termelési) hálózatba.

Márpedig a zabbix vélhetően snmp trap -ekkel is fog operálni, vagyis a terveim szerint a proxy gépek felől is fog kérés indulni a hostokhoz. Valamint a host felől is fog indulni kommunikáció a proxy felé. Ez amíg az "egyik hálózat" -ban marad a forgalom, addig mehet a dolog. A helyi IBSZ azt megengedi, hogy a védett hálózat "kibeszéljen", de befele nem lehet beszólni ebbe a hálózatba. Ezért szeretném a proxikat, mert azt meg nem szeretném, hogy az "egyik hálózat" összes gépe elkezdjen kifele beszélni, ezt csak a proxyknak szeretném megengedni a tűzfalakon.

A frontend (szerver) viszont kint lenne a kevésbé védett hálózatban, amire periodikusan ráküldöm a mérési adatokat.

Szerkesztve: 2020. 02. 13., cs - 21:53

Válasszuk szét három részre a dolgot. Első réteg az adatok gyűjtése. Ezt valamilyen aktív/passzív HA-ban működő zabbix-proxyval csinálnám meg (Emiatt kiesik a sqlite), 2+1 node: három node-os MariaDB/galera fürt, amiből kettőn aktív/passzív módban zabbix-proxy fut.
A beküldött adatokat aktív/passzv párban lévő zabbix szerverre tolnám, amik külön 2+1 node-os mondjuk MariaDB/Galera fürtöt "etetnének" az adatokkal. (2 node az egyik, egy node a másik gépteremben, ha a "2 node-os" gépterem kuka, akkor kell csak kézi beavatkozás a továbbműködéshez, de lehet 1+1+1 node, amiből a harmadik az irodai szegmensben van)
Tehát a tárolás, mint funkció önmagában redundáns, de "kifelé" egységes réteket kapna itt is. A webes frontend meg mehetne a ha-ban működő zabbix-szerver(ek)re, vagy egy plusz gépre, ha a vizualizációnál megengedhetünk egy hosszabb kiesést.

Szumma: 3 node/DC plusz 5 node a szerverek+tárolás és opcionálisan nulla, egy vagy két szerver a webes frontend.

Ajjaj. Ez mar egy szep csillaghaborus terv. 8-10 gep asszem mar az agyuval verebre kategoria. De vegiggondolva jogos, hogy igy minden reteg magas tulelessel rendelkezik.

Asszem vegig kell gondolnom, hogy mennyire akarom, mennyire komoly az igenyem a HA kepessegekre, hogy hany gepet er meg a tortenet.

Szepen feladtad nekem a lecket, koszonom! :-)

Ha tényleg mindent valamely komponens kiesését túlélő megoldást keresel, akkor az bizony ennyi. Amiből semmiképp sem engednék a proxy - proxy DB - szerver - szerver DB - web magas rendelkezésre állásából, az a szerver és a mögé rakott DB. Ekkor a proxy kiesése esetén "eltűnik" a hostok egyik fele, kérdés, hogy ez vállalható-e, és ha igen, mennyi időre maradhat "sötétben" a szerverpark egyik vagy másik fele.

Ezért írtam korábban, hogy a "mit mérünk" és a "hogyan mérünk" tervezése az első. Ez utóbbiba beleértendő a monitoring rendszer adatgyűjtési- tárolási- és vizualizálási/alerting funkcióinak a rendelkezésre állása is. Ez a tervezés a kihívás és az igazi "kulimunka" a monitoring összerakásában, nem a tényleges telepítés és konfigurálás - 3-400 host esetén nagyon-nagyon nem szabad elhanyagolni ezeket a lépéseket, mert utána sokkal nehezebb lesz "takarítani" és átvariálni a méréseket. Mondom ezt úgy, hogy nem egy olyan Zabbixhoz volt szerencsém, ahol -hasonlóan hozzád- százas nagyságrendben voltak a monitoringba bekötve szerverek.

Az egy szem Zabbixot mi fogja felügyelni? Meg mire jó mindez? Ha a Zabbix maga nem képes active-active HA cluster működésre, márpedig legjobb tudomásom szerint nem képes, akkor csak szopni fogsz, mert úgysem a faék proxy fog megdögleni, hanem a Zabbix vagy alatta az adatbázis, az ellen meg nem véd.

fixme, de a zabbix serverben egy hosthoz csak 1 proxy tartozhat. tehat az nem fogod tudni beallitani hogy a host1-et kerdezze le a proxy1 is egy a proxy2 is, es ugyanabba a zabbix serverbe tolja be az adatot.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ezért írtam, hogy a zabbix-* az aktív/passzív HA-ban, a DB-k meg megint külön életet élő fürtben (mondjuk Galera, 3-3 node-dal). Ráadásul a proxy esetében van idő átbillenni (elindítani a motyót a tartalék node-on, ha az elsődleges node megpunnyad. (másodperceket jelent csak, annyit a pollozással működő figyelés kibír, a passzív check meg legfeljebb újraküldi az adatot, ha épp belerongyol a proxi billenésébe)

Mondjuk ha mindkettőn fut, az sem világvége, csak meg kell oldani, hogy a "passzív" node-ről ne menjen kérés a monitorozott gépek felé, és ne írhasson a DB-de :-)

Kb 12 éve foglalkozom zabbix üzemeltetéssel, nem jellemző rá, hogy elszáll a rendszer, ezért szerintem túlzás ennyire túlbiztosítani a dolgot.

Nálunk most is egy szerveren van az összes komponense, direktben szólongatja meg a klienseit. Korábban én is használtam minden DC-ben 1-1 proxy-t, de az előnyét nem kompenzálta a hátránya.

Lazán kapcsolódik:

Ugyannyi host és service monitorozása esetén Nagios vs. Zabbix szerver terhelése hogy alakul?

Fél füllel hallott tapasztalás: a zabbix szerver sokkal jobban terhel, adatbázis oldalon nagy terhelést okoz, kell alá a vas.

Úgy látom sokan régóta üzemeltettek Zabbixot, validálnám a hallomást.

Szerkesztve: 2020. 02. 16., v - 18:01

Hasonló cipőben jártam én is.
Még 4.0-s verziónál 2 db VM-et felhúztam mindkettőre ugyan azzal a zabbix proxy configgal.
Kettő közé corosync, pacemaker-t lőttem be, míg a primary futott, a másikon a zabbix-proxy service le volt állva.
Heartbeat figyelt, majd ha lehalt a primary, felhozta a service-ét amiben mindkettő esetén a Virtual IP address volt a confban.
Ez a VIP address pedig vándorolt a linuxok között attól függően ki él.
Mivel nem vagyok SQL mágus azt nem raktam clusterbe, nem is volt rá szükség, mert amint feljött a secondary-n a service, indítás után a zabbix-serverrel megbeszélte a friss bekérdezni valókat.
Sokat teszteltem és nem volt érezhető kimaradás. Most is így fut egy siteon.

Lehet a proxy-kat így is csinálni, ez igaz, viszont a zabbix-szerver plusz az adatbázisa plusz a webes frontend az más téma, ott a magas rendelkezésre állás két zabbix szerver aktív-passzívban, vándorló IP-vel, mögötte meg egy legalább három node-os DB-fürt - a webes frontend meg igény szerint a zabbix-szerveren vagy másik node(ok)on futkotrásszon. Az adatok begyűjtésében a kiesés kisebb gond, mint a begyűjtött adatok illetve a monitoring/alerting funkciók  elvesztése/kiesése.