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)

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

A Munin alapvetően nem arra való, mint amire a Zabbix. A Munin egy faék egyszerűségű eszköz, amivel a trendeket lehet figyelni, hogy egy-egy mért mutató hogyan változik az idő függvényében, egyszerűen ránézésre.

Nem is azt mondtam, hogy a Munin rossz, hanem, hogy volt kolléga rosszul használta (*), és amikor kellett volna, semmire nem ment vele, mert nem volt meg, hogy "mit, hogyan és miért" monitoroz (ok: "mindent IS, muninnal, csak hogy legyen" :) ), csak volt néhány grafikonja, ahol az érték a piros vonal felett volt.

(*): több szinten is, kezdve onnan, hogy egy munin master + több node helyett ahol telepítve volt, ott a munin master+http server+munin node, azon keresztül, hogy az elsősorban erőforrás monitorozót (mert azért még mindig egy grafikon rajzoló progit) próbálta szolgáltatás-monitorozásra használni, odáig, hogy ha ráböktél egy random gráfra, hogy az a metrika mit jelent, elsőként kb. a kuglit csapta fel...

BlackY

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

(ok: "mindent IS, muninnal, csak hogy legyen" :) )

Az erre való, de nem is kell többet várni tőle, incidens és probléma kezelésére nem alkalmas, nem tud komplex szabályokat. Cserébe Zabbix-ből például vérhugyozós dolog kiszedni egymás mellé egy szerver metrikáit vagy egy metrikát az összes szerverhez, pedig sokszor jól jön, hogy lásd egy görgetésre, hogy merre mennek a trendek mondjuk egy éves viszonylatban.

" Zabbix-ből például vérhugyozós dolog kiszedni egymás mellé egy szerver metrikáit " Egy screent összerakni nem kunszt - szerintem.

" vagy egy metrikát az összes szerverhez, " Egy grafikonra felszórni több értéket sem kunszt. Meg kell csinálni, össze kell kattingatni, az igaz.

Egy screent összerakni nem kunszt - szerintem. Egy grafikonra felszórni több értéket sem kunszt. Meg kell csinálni, össze kell kattingatni, az igaz.

Mennyi időbe telik például mondjuk 50 host és 20 grafikon esetén összerakni annyi Screen-t, hogy legyen minden grafikonra egy screen, ami az összes host-ot tartalmazza és legyen minden host-ra egy screen, ami az összes grafikont tartalmazza? Egy Munin ezt konkrétan 0 perc munkával tudja, ha hozzáadok egy új metrikát, akkor lesz egy új grafikon mindenhol, minden nézetben.

Használom mind a kettőt évek óta, komplementer funkciójuk van, a Munin nagyon jól jön, ha például több metrika között kell összefüggéseket keresni, hogy mi is történt, mi előzte meg a problémát, aztán át lehet tenni Zabbix-ba, hogy erre legközelebb jelezzen.

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

Ezt én is így gondolom, hogy több részre szedem a történetet.

Az első az architektúra, hogy milyen gépből (zabbix-proxy, zabbix-server) hány darabot és hova teszek, valamint mi lesz az adatcserék útja.

A második a mit mérünk, vagyis hogy a végén mi jelenjen meg a szerver gépen amikor megtámadom a böngészővel, valamint, hogy milyen küszöbértékek legyenek a riasztásoknál.

A harmadik pedig, hogy a második pont adatait milyen módszerrel szerzem meg, agent, SNMP, script kimenet, stb.

 

A harmadik ponttal kapcsolatban csak elképzeléseim vannak, nagyon nem görcsölök rajta, mert tudom, hogy kivitelezhető, ennyi jelenleg elég. Majd ha odaérek, akkor megírom a scriptet, vagy beállítom az agentet.

A második pontnál kicsiben kezdünk, egészen konkrétan annyi fog érdekelni egy gépről, (IP címről), hogy UP vagy DOWN, és majd innen megyünk tovább.

(Kis kitérő: A jelenlegi monitor rendszer is így fejlődött, hogy bekonfiguráltuk azt ami józan számítás szerint gondot okozhat (DISK, MEM, CPU megfutás illetve elfogyás, meg néhány service figyelés (syslog-ng, ntpd, sshd, stb.) és örültünk. Amikor aztán jött valami gebasz, akkor utána elmerengtünk rajta, hogy ezt hogy lehetett volna kivédeni, és utána megírtam például a file változás figyelő (spanyolviasz díjas) alkalmazásomat (pár sor bash kód, haha) ami kiabálni kezd, ha valami paraszt belemódosít például az sshd_config -ba. Így legközelebb felkészülve érkezünk. Most is hasonlót tervezek, nem akarom én felrakni az összes létező szenzort és applikációs siránkozást figyelő plugint, mert minek. Ahogy mondtad, a zajban elvész a tényleg fontos kiabálás. A Zabbix felületén azt akarom látni, amibe hajlamos belehalni a gép. A többit gereblyézze az, akinek van rá ideje. )

 

Most az első ponton rugózok, keresem a legkevesebb munkával előállítható legjobb topológiát, hogy lehetőleg ne kelljen semmit újracsinálnom. Nem szeretnék zsákutcába jutni.

"A második pontnál kicsiben kezdünk, egészen konkrétan annyi fog érdekelni egy gépről, (IP címről), hogy UP vagy DOWN, és majd innen megyünk tovább." define: UP/DOWN state. És ez nem minden esetben triviális - énmindenképp az adott host kritikus szolgáltatásának az állapotát nézném meg, mert az, hogy IP-szinten "él", az pontosan annyitmind meg, hogy IP-szinten elérhető.

A Zabbix-ban template-ek használata erősen javasolt, célszerű azokat előre _jól_ összerakni. Amiből ne engedj, az a szerver és a mögötte lévő DB magas rendelkezésre állása.

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 :-)

"a zabbix serverben egy hosthoz csak 1 proxy tartozhat"

Köszönöm az infót!

Utánanéztem ennek a mondatodnak, és sajnos igazad van, a hostokat hostname és útvonal alapján különbözteti meg, így az általam felvázolt két proxys módszer így, ebben a formában nem jó. :-/

A lejjebb olvasható módszer, a VIP cím és heartbeat alapú zabbix proxy service indítás megoldhatja ezt a problémát, így most ez a favorit. :-)

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.

Attól nem félek, hogy a Zabbix "egyszer csak meghal", mert a neten jókat olvastam róla.
Pontosabban nem olvastam róla olyat, hogy olyan öngyilkos hajlama lenne mint egyes MS termékeknek update után. :-)

Igazából egy dologtól tartok, hogy ha a fizikai VM host meghal (volt már ilyen, az alaplapi memóriavezérlő elpukkant, és nincs az a try-catch blokk ami egy ilyen kivételt megfog...) akkor a rajta lévő gépek gyakorlatilag reset -ből állnak fel.

Márpedig dirty filesystem -ről bootolni nem feltétlenül boldogság. Általában nincsen vele baj, de nem tudom, hogy a Zabbix (pontosabban az adatbázisa) hogy viseli az ilyen pofont?

Ha tranzakciókban gondolkodik, és észleli, hogy az utolsó nem sikerült, és annak nyomait eltakarítva visszaáll az egyel korábbi konzisztens állapot, az nekem megfelel, elvégre a hardware crash előtti 5 percben történtek elvesztése nem kritikus, hiszen nem szoftver hibáról beszélünk.

Ha viszont az inkonzisztens adatbázisát nem tudja saját maga kitakarítani, és nem áll fel a proxy, akkor az para.

Erről tudsz valamit mondani, hogy reset -ből visszajőve milyen tapasztalataid (vagy hallomásaid) voltak, hogy képet alkothassak róla, hogy mennyire kell félnem ettől a dologtól?

"Attól nem félek, hogy a Zabbix "egyszer csak meghal", mert a neten jókat olvastam róla." - OS meg tud alatta makkanni, tárhely dettó, hálózat/akármi szintén. A proxy adatbázisa lehet sqlite - de ezt csak kevés item-re javasolják, nálad vélhetően ennél több lesz, úgyhogy célszerűbb ott is db-fürtben gondolkodni, ha atomrobbanást túlélő megoldást szerertnél. Ha jó az, hogy az utolsó tranzakció(k) elveszhet(nek), akkor sima helyben futó mysql sem lesz katasztrófa - a boot idejére viszont cészerű ha-ba rakni ezt a stacket (proxy+local sql DB) is.

Láttam már nagyon hajtott mysql-t kvázi reset-tel lelőve nagyobb gond nélkül újraindulni, meg olyat is, amikor minimális terhelés mellett kirántott tápkábel után (sz@rul megírt app volt a root cause) sokat kellett a logikailag is konzisztens adatbázisig tornázni.

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.

A zabbix ha nincs elszúrva vagy nincs megfelelően optimalizálva akkor nagyon stabil és fölösleges túllihegni mert azzal sokkal több baj lesz.

Én ezt az felállást javaslom:

= Egyik hálózat =

  [Datacenter 1]
  - hostN ---> zabbix-proxy1
  - zabbix-proxy-1 ---> (PSK, active, tűzfal) zabbix-server
  - backup célra proxy3 de csak pár méréssel.

  [Datacenter 2]
  - hostN ---> zabbix-proxy2
  - zabbix-proxy-2 ---> (PSK, active, tűzfal) zabbix-server
  - backup célra proxy4 de csak pár méréssel.

= Másik hálózat =

zabbix-server

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

Pár extra viszont a proxykon sokat segíthet a rendelkezésreálláson, vagyis a folytonosságon:

Proxy will keep data locally for N hours

ProxyLocalBuffer=XX óra
ProxyOfflineBuffer=XX óra

HeartbeatFrequency=3 ( in seconds )
ConfigFrequency=60 ( in seconds )
DataSenderFrequency=1 ( in seconds )
HousekeepingFrequency=1
TLSConnect= psk
TLSAccept= psk
TLSPSKIdentity= (A PSK)

 

Minden más process-t trapper, poller, pinger, discover, vmeare hamar kimeríthetsz a default szinten, de ezeket mindig a felhasználás és a terhelés szerint kell beállítani, viszont a proxy-n és a szerveren is a zabbix processes busy százalékok nagyon pontosan megadják, hogy melyik fogyott el.

Amire még figyelj, hogy a DB alatta optiomalizálva legyen, ha MySQL-t hgasználsz akkor ez a InnoDB optimalizáslást jelenti leginkább.

"Amire még figyelj, hogy a DB alatta optiomalizálva legyen, ha MySQL-t hgasználsz akkor ez a InnoDB optimalizáslást jelenti leginkább." - Meg arra, hogy valamilyen fürtözés (pl. galera, 2n+1 node-dal) legyen alatta, mert hiába atomstabil a szerver meg minden, de a single point of failure beletervezése nagyon nem jó dolog...