interna databaza Zabbix servera

[Zabbix_Beginner]

dobry den, poprosil by som o radu.

Mam Zabbix server 4.4 (bezi na CentOS 7) a Zabbix databaza (predpokladam) si uklada data do filesystemu /var/lib/mysql. Tento filesystem sa mi velmi zaplna, jasne, ze zvacsovanie priestoru nie je dlhodobe riesenie.

df -k /var/lib/mysql
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/centos-lv_var_lib_mysql 339436116 274802220 48910004 85% /var/lib/mysql

du -hs /var/lib/mysql/zabbix |sort -n
261G /var/lib/mysql/zabbix

pwd
/var/lib/mysql/zabbix

du -sk *|sort -nr
124711028 history_uint.ibd
58904664 history.ibd
56959024 trends_uint.ibd
12529688 trends.ibd
11808772 events.ibd
3272708 event_recovery.ibd
1699844 history_str.ibd
1351684 history_log.ibd
729092 alerts.ibd
393220 sessions.ibd


Historicke data uchovavam 90 dni a trendove 365 dni.

Poradili by ste mi prosim, ze ako mam konkretne precistit tento fs? Predpokladam, ze asi na urovni usera mysql.
dakujem

[gofree]

manualne zasahy do databazy vacsinou nekoncia dobre

osobne by som sa do tho nepustal https://programmer.help/blogs/data-c...-database.html

dlhodobym riesenim by bolo prejst na partitioning databazy - pozorne citat - benefitom je to ze sa odhadzuju particie dat a tym sa uvolnuje miesto

mysql

https://bestmonitoringtools.com/zabbix-partitioning-tables-on-mysql-database/

alebo timescaledb + timescale compression ( zabbix out of box support )

https://www.zabbix.com/documentation/5.0/manual/appendix/install/timescaledb

vseobecne odporucania:

rozumna historia ( naozaj 90 dni ? trendy rok ? )

upgrade na supportovanu verziu - napr 5.0

optimalizovat intervaly zberu dat ( niekedy nema zmysel zbierat data kazdu minutu a zapisovat ich do DB )

nastavit throttling - rovnake hodnoty sa nezapisu do db - setri miesto

https://blog.zabbix.com/why-zabbix-t...itoring/12364/

[bitboy]

gofree zhrnul najdolezitejsie informacie ohladom spravy dat v Zabbixe. Ja by som doplnil este niekolko ponzamok.

Co sa tyka fungovania spravy dat v Zabbixe, tak plati nasledovne:

1. Zabbix vsetky zbierane udaje a generovane udalosti udrziava v definovanych casovych oknach (s vynimkou otvorenych problemov).
2. O 'upratovanie" databazy (udrziavanie dat v casovych oknach) sa stara housekeeper (ak nepouzijete gofreem spominany partitioning db)
3. Housekeeper je v pravidelnych intervaloch aktivovana sluzba (default 1x za hodinu), ktora pomocou specifickeho algoritmu cisti db a udrziva udaje v casovych oknach
4. Frekvenciu aktivacie housekeepera je mozne menit v konfiguracnom subore zabbix servera (alebo zabbix proxy) - parameter HousekeepingFrequency
5. Housekeeper pri kazdej aktivacii zmaze maximalne objem udajov v case od konca danej postupnosti (historia, trend, eventy...), ktory sa rovna stvornasobku intervalu jeho aktivacie. Cize pri frekvencii 1 hodina maze maximalne 4 hodiny zozbieranych udajov od konca postupnosti (napr, itemu).
6. Spravanie housekeepera je mozne nastavit globalne v Administration-General-Housekeeping alebo pre kazdu metriku/item samostatne (historia/trendy)

Objem udajov, ktory sa uklada do databazy je ovplyvneny viacerymi faktormi:

1. Pocet zbieranych itemov a nastavenie ich intervalov historie a trendov
2. Frekvencia zberu udajov pri jednotlivych itemoch
3. LLD - proces autodiscoveringu itemov - pri nespravnej konfiguracii moze neumerne rast pocet zbieranych itemov
4. Autodiscovering novych hostov a nasledne narast poctu zbieranych itemov ich prostrednictvom
5. Itemy zbierajuce udaje zo zdrojov typu SNMP trapy, log subory, zabbix trapper - tu nie je mozne predikovat objem zachytenych udajov v case a bez osetrenia vstupu (event storm detection) moze dochadzat k zahlteniu db (Zabbix pre tieto situacie bohuzial nema ziadne riesenie okrem pomerne primitivneho throttlingu, ktory je pre tento typ zdrojov prakticky nepouzitelny)
6. Flapping triggerov, ktory moze sposobit nadmerne generovanie udalosti a nasledne problemov v case a opat intenzivne plenenie DB

Vsetko uvedene ma vplyv na plnenie db a problemy s nou. Na co je vhodne si dat pozor:

1. Ako uz spominal geofree, volit vhodnu velkost historie, trendov a intervalov zberu udajov (casto zbytocna snaha zbierat udaje kazdych par sekund)
2. Ak je to mozne, vyhybat sa zdrojom udajov typu log subor alebo SNMP trap. Ak uz je nutne vyuzit tieto zdroje, tak nasadit aspon throttling. Advanced postupy riesenia spracovania logov a trapov sme rozoberali v nasom webinari.
3. Sledovat trend narastu poctu itemov v case (moze byt problem s LLD alebo s autodiscoveringom hostov)
4. Sledovat flapping triggerov (Monitoring-Reports-Triggers Top 100) - ak intenzivne flapuju triggery, tak to znamena dve veci: Monitoring nie je vytvoreny optimalne (operatori su zahlcovani nadmernym objemom incidentov) a databaze je plnena vysokym objemom incidentov
5. Zabezpecit proces uzatvarania problemov - kazdy otvoreny problem by sa mal uzatvorit v konecnom case a to najlepsie automatizovane (otvoreny problem totiz db neopusti)
6. Housekeeper ako uzke hrdlo - housekeeper sa snazi v co najkratsom intervale upratad db pri kazdej aktivacii podla vyssie uvedeneho algoritmu. Moze sa vsak stat, ze uzkym hrdlom systemu je storage pre DB. Je preto vhodne sledovat vytazenie housekeepera (nasdenie default sablon pre monitoring Zabbix servera a proxy je zaklad). V pripade problemov je vhodne zvazit prechod na partitioning (optimalne je vyuzitie PG db a TimescaleDB ako spominal geofree). Treba vsak upozornit, ze ani partitioning nie je uplnen riesenie problemu plnenia db (v Zabbixe su casto veci riesene na pol cesty a nedotiahnute).

[hermanekt]

Dobry vecer,

vim, ze se tady pise o zabbix 4.4 a mysql.

Osobne v produkci neukladam historii dele nez 7 dni a trendy mam nastavene na 365 dnu. Kdyz to srovnam s tim, kolik ma 1 den v historii a v trendech, tak je to 20gb vs 500mb. S mysql pouzivam partitioning a je to v pohode. Je tu zminen throttling, ktery taky dost pomuze. Historie je dobra primarne pro triggery jako je avg (15min) a podobne. Ja bych udelal upgrade na verzi 5.0 a data odmigroval do postgresql a nasledne zapnul timescale DB. Historii a trend data to automaticky rozhaze na chunky a umi to kompresi po 7 dnech. Priklad 600gb DB s postgresem ma ted 200gb.

Tom

[Zabbix_Beginner]

dakujem vam vsetkym za odpovede a rady. Vsetko co radite sa budem usilovat uplatnit v praxi no je to beh na dlhe trate takze pekne postupne step-by-step. :-) Este raz vdaka.