Optimalizace dohledového systému Zabbix je velmi důležitým krokem v reálném nasazení. Při návrhu je nutné zvažovat všechny hlediska, ať už se jedná o návrch hardware, typ databáze tak i nastavení parametrů operačního systému, databázového systému a také samotného dohledového prostředí. V praxi je někdy nutné parametry občas měnit a přispůsobovat s aktuálním stavem a měnícím se počtem dohlížených zařízení, respektive s počtem prováděných testů a operací. Podívejme se postupně na všechny hlediska, která je nutné zohlednit pro maximální výkon dohledového systému. V žádném případě není vhodné spoléhat na výchozí nastavení databázového systému a Zabbix serveru. V druhém díle, který se týkal pouze instalace jsem se záměrně vyhnul detajlnímu nastavení. Teď je ten pravý čas podívat se na problematiku optimalizace podrobněji.
Hardware
Volba správného hardware je nejdůležitějším výkonostním hlediskem. Pokud bude hardware pomalý nepo špatně navržený, nepomohou nám žádné další optimalizace databáze, systému, ani ničeho jiného. Jak již bylo mnohokrát zmíněno, velmi záleží na počtu sledovaných zařízení a na celkové topologii sítě. U velkých rozsáhlých sítí nebude stačit pouze jeden Zabbix server, ale budeme se muset přiklonit k použití více serverů v režimu proxy nebo použití Nodů, čemuž se ale budeme věnovat v jiném díle tohoto seriálu.
Podle následujích tří příkladů můžeme vidět několik z mnoha možností, jak provozovat dohledový systém Zabbix. Podívejme se postupně na tyto tři možnosti.
- jeden server na vše
- levné řešení pro malý počet hostů cca do 1000
- v případě výkonostního problému se těžko hledá úzké místo
- o výkon se dělí DB, Zabbix, web server,...
- v případě poruchy nejde nic
- vhodné oddělit DB na jiný fyzický disk případně RAID (nejlépe RAID 10)
- Zabbix server + DB server
- výkonostně velmi rozumné řešení, kdy je oddělena DB od Zabbix serveru
- nutné zajistit co nejrychlejší konektivitu (Gbps síť, FibreChannel, iSCSI,... )
- z hlediska disků platí to, co pro první řešení, nejvhodnější je použití RAID 10
- Zabbix server + DB server + storage
- nejvhodnější řešení z hlediska bezpečnosti i výkonu
- při odděleném storage (diskové uložiště) je možné zajistit mirror serverů, jak DB tak Zabbix serveru a v případě výpadku jej nahradit v poměrně malém časovék intervalu
Ve všech případech z hlediska hardware je vhodné alespoň zvážit, ne-li přímo dodržet následující doporučení:
- čím více jader CPU, tím lépe
- používejte rychlé disky SCSI nebo SAS
- v případě lokálního uložiště oddělte DB od ostatního
- čím více paměti RAM, tím lépe (platí především pro databázový server)
- používejte Fast etehrnet nebo lépe Gigabit ethernet
V dnešní době virtualizace je poměrně zajímavé řešení použít virtualizovaného hardware. Především z hlediska přidělovaných zdrojů, kdy je možné za chodu přidávat, v případě potřeb paměť nebo počet CPU, případně zvětšovat prostor na disku, a nebo stroj migrovat dle potřeb v rámci clusteru. Tuto možnost pouze nastiňuji jako vhodný námět k přemýšlení. Je také možné provozovat produkční Zabbix server jako fyzický hardware a záložní řešení mít ve virtualizovaném prostředí.
Nastavení / ladění operačního systému
V některých situacích zjistíme, že je dohledový systém velmi pomalý a plní se fronta nevyřízených požadavků. Sledované hodnoty jsou stále ve větším zpoždění a dohledový systém tak přestává plnit funkci dohledového systému. V takovém případě, pokud není problém očividný, např. souvisí s nedostatečným výkonem (disk, paměť, CPU, ...), musíme přikročit k prvnímu kroku, tedy ke kontrole nastavení limitů jádra systému. Vešekré nastavení se provádí pomocí nástroje sysctl případně editací souboru /etc/sysctl.conf.
- parametry jádra ověříme následujícím příkazem
- nastavení limitů jádra jsou velice individuální pro konkretní situaci, proto není možné podat nějaké doporučení. V podstatě nejdůležitějším parametrem z hlediska Zabbixu je velikost minimální a maximální hranice sdílení paměti, kterou využívá pro sdílení historie, trendů, textové paměti..., mezi procesy
- sledujte hodnotu Load average, sledujte ji i Zabbixem :-), hodně napoví o využití serveru
- používejte co nejaktuálnější verzi distribuce a také jádra
- neprovozujte na serveru nic dalšího, co není potřeba
shell> sysctl -ashell> sysctl -a | grep -E "shmall|shmmax"kernel.shmmax = 4294967295kernel.shmall = 268435456shell> uptime11:10:10 up 61 days, 19:53, 1 user, load average: 0.21, 0.19, 0.23Nastavení databáze MySQL
Hned v úvodu a po celou dobu tohoto seriálu používáne jako databázový server MySQL, proto se i následující kroky a doporučení budou týtak primárně databáze MySQL. V ideálním případě je prvním krokem k optimalizaci DB použití zvláštního fyzického serveru, který je vyhraněn jen pro DB. Server by měl být s dostatečným počtem CPU, hodně pamětí a rychlými disky v RAID 10. Především u paměti RAM se nevyplácí šetřit a v tomto případě platí několikanásobně pravidlo - čím více, tím lépe. Veškerá nastavení konfigurace probíhá v /etc/my.cnf. Podívejme se na některá doporučení v rámci optimalizace databázového serveru.
- MySQL potřebuje odkládat některé soubory do záložního adresáře, mnohem rychlejší je použití paměti než-li lokálního disku. Vytvoříme tedy tmpfs pro dočasné soubory o velikosi 300MB (rozumná velikost je cca 8 až 10 procent paměti RAM)
- provedeme potřebné úpravy v /etc/my.snf, které jsou velmi závyslé na HW a na konkrátní situaci a nasazení. Následující příklad se mi osvědčil v praxi u systému se 4GB RAM a QuadCore CPU. Nastavení jsou pouze orientáční, sloužící jako příklad naznačující, na které parametry v nastavení MySQL si dát pozor
shell> mkdir /tmp/mysqltmpshell> echo "tmpfs /tmp/mysqltmp tmpfs rw,size=300,nr_inodes=10k,mode=0700,uid=mysql,gid=mysql 0 0" >> /etc/fastabshell> mount /tmp/mysqltmp[mysqld] datadir = /mnt/storage/mysql/data tmpdir = /tmp/mysqltmp connect_timeout = 60 wait_timeout = 28800 max_connections = 512 max_allowed_packet = 5M max_connect_errors = 1000 tmp_table_size = 512M max_heap_table_size = 256M table_cache = 512 log_error = /var/log/mysql/mysql-error.log slow_query_log_file = /var/log/mysql/mysql-slow.log slow_query_log = 1 long_query_time = 20 innodb_data_home_dir = /mnt/storage/mysql/data innodb_data_file_path = ibdata1:128M;ibdata2:128M:autoextend:max:2048M innodb_file_per_table = 1 innodb_status_file = 1 innodb_additional_mem_pool_size = 128M innodb_buffer_pool_size = 2048M innodb_flush_method = O_DIRECT innodb_io_capacity = 2000 innodb_flush_log_at_trx_commit = 2 innodb_support_xa = 0 innodb_log_file_size = 512M innodb_log_buffer_size = 128M query_cache_size = 128M query_cache_limit = 1M [isamchk] key_buffer = 64M sort_buffer = 64M read_buffer = 16M write_buffer = 16M [myisamchk] key_buffer = 64M sort_buffer = 64M read_buffer = 16M write_buffer = 16M event_scheduler = 1 query_cache_type = 0
Nastavení parametrů Zabbix serveru
Dalším velmi podstatným a důležitým výkonostním krokem je nastavení parametrů Zabbix serveru. Veškeré nastavení najdeme v /etc/zabbix/zabbix_server.conf. V žádném případě není možné spoléhat na výchozí nastavení. Pojďme se nejprve podívat na zakladní možnosti, jak se dozvědět něco o výkonu Zabbix serveru.
- v Monitoring → Dashboard : Status of Zabbix máme informaci o počtu operací zpracovaných za vteřinu (Required server performance, new values per second), což je první údaj, který nám něco napoví o aktuálním stavu
- velmi důležitým parametrem je spouštění počtu procesů v danných režimech (Pollers, DBSyncesrs, Trappers, PIngers, ...)
- pokud se vám začně neúměrně plnit fronta Administration → Queue, není něco v pořádku a bude nutné přikročit ke změnám v nastavení /etc/zabbix/zabbix_server.conf
- v ideálním případě čím je ve frontě méně čekajících úkolů, tím lépe a zárověň čím je plnější časově delší fronta, tím je to pro nás větší problém
- na podrobnější stav operací ve frontě se můžeme podívat v Administration → Queue : Details
- hodnoty jsou opět bohužel pouze orientační a velmi závislé na konkrétní situaci, počtu sledovaných zařízení, typu testů, atd. Následující příklad se mi velmi osvědčil v praxi, kde mi to pomohlo zvednout hodnoty StartPoolers, StartDBSyncesr, StartPollerUreachable a změnit frakvenci HousekeepingFrequency
- počet procesů zvedejte opatrně, v ideálním přápadě by měla být fronta zabbix serveru rovna 0
StartPollers=80 StartDBSyncers=16 StartPollersUnreachable=80 StartTrappers=16 StartPingers=16 StartDiscoverers=8 HousekeepingFrequency=12 SenderFrequency=30 Timeout=10 UnreachablePeriod=120 UnavailableDelay=60 CacheSize=128M HistoryCacheSize=16M TrendCacheSize=16M HistoryTextCacheSize=32M
Je velmi těžké, ne-li nemožné říci, co a jak nastavit, protože případ od případu je vždy různý. V zásadě je ale možné přidržet se následujících doporučení, která mají na výkon zásadní vliv.
- používejte co nejméně externí skripty a v rozumné míře SNMP
- je-li to možné upřednostněte aktivní testy před pasivními
- čím složitější Triggery, tím větší zátěž
- číselné hodnoty Itemů jsou mohem lepší než text, řetězec, ...
- hlídejte hodnotu Housekeeper (čištění databáze)
- příliš mnoho sezení na webovém rozhranní na rychlosti nepřidá (zatěžování DB dotazy)
- udržujte databázi pokud možno v rozumné velikosti (zvažte potřebnou délku historie a trendů)
- komunikujte s databází pokud možno pomocí socketů
Sledování stavu Zabbix procesů
Zabbix server umožňuje sledovat stav vlastních interních procesů a informovat nás v podobě grafů o aktuální situaci. Tato možnost je velmi důležitá při ladění parametrů v zabbix_server.conf. Často budeme nuceni hlavně v první fázi ladění výkonu přikročit k metodě pokus omyl :-) a sledovat, jaký vliv mají konkrétní nastavení na dannou situaci. Následující grafy zobrazují stavy jednotlivých procesů Zabbixu v čase. V případě hladání problému můžeme vidět souvislost jednotlivých procesů, jak jsou provázány.
Pro lepší orientaci uvádím alespoň ve zkratce popis a vysvětlení jednotlivých procesů Zabbix serveru:
- alerter – proces zasílající veškeré výstrahy a hlášení
- configuration syncer – synchronizace cache konfigurace
- db watchdog - hlídač dostupnosti databáze
- discoverer - prohledává dostupnost zařízení
- escalator - proces řídící eskalaci
- history syncer - zapisuje načtená data do databáze
- http poller - proces pro web monitoring
- housekeeper - proces, který se stará o čištění databáze
- icmp pinger - proces řídící ICMP ping testy
- ipmi poller - proces řídí IPMI kontroly
- node watcher - zajišťuje zasílání dat v distribuovaném prostředí
- self-monitoring - kontrola vnitřních procesů
- poller - hlavní proces Zabbixu komunikující s agenty
- proxy poller - komunikuje ze servery v režimu proxy
- timer - časovač hlídací časově závyslé funkce triggerů
- trapper - hlídá a obsluhuje všechna příchozí spojení
- java pooler - zajišťuje komunikaci přes JMX
- unreachable poller - proces starající se o nedostupná zařízení
Rekapitulace
V dnešním díle seriálu jsme se seznámili s metodami, jakými je možné optimalizovat činnost dohledového systému Zabbix. Při malém počtu sledovaných zařízení není problém s výkonem prakticky znatelný,ale v reálném nasezení, kdy sledujeme tisíce zařízení a potřebujeme uchovávat historii nějakou dobu, budeme postaveni před otázku výkonu. U velmi rozsáhlé infrastruktury nebude stačit použití jednoho dohledového serveru a budeme tak nuceni použít Zabbix v režimu proxy serveru a nebo rozdělit jednotlivé části sítě do nodů. O této probematice si povíme v příštím díle seriálu.
Odkazy
1. Zabbix domovské stránky : http://www.zabbix.com
2. Zabbix dokumentace : http://www.zabbix.com/documentation.php
3. Zabbix - Performance tunning : https://www.zabbix.com/documentation/2.0/manual/appendix/performance_tuning
4. MySQL performance typs : http://zabbixzone.com/zabbix/mysql-performance-tips-for-zabbix/
5. Partitioning tables : http://zabbixzone.com/zabbix/partitioning-tables/