LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> Dohledový systém Zabbix VI - na plný výkon

V dnešním díle o dohledovém systému Zabbix nepatrně odbočíme od monitoringu hostů a zařízení. Podívejme se na možnosti sledování samotného Zabbix serveru a na to, jak dohledový systém optimalizovat a přizpůsobit konrétnímu prostředí a situaci. Velmi důležitým výkonostním krokem v reálném nasazení je nastavení databázového serveru a celková koncepce návrhu hardware, jak bylo poukázáno v druhém díle tohoto seriálu.

11.7.2013 12:00 | Antonín Kolísek | Články autora | přečteno 9629×

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
  • shell> sysctl -a

  • 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
  • shell> sysctl -a | grep -E "shmall|shmmax"
    kernel.shmmax = 4294967295
    kernel.shmall = 268435456

  • sledujte hodnotu Load average, sledujte ji i Zabbixem :-), hodně napoví o využití serveru
  • shell> uptime
    11:10:10 up 61 days, 19:53, 1 user, load average: 0.21, 0.19, 0.23

  • používejte co nejaktuálnější verzi distribuce a také jádra
  • neprovozujte na serveru nic dalšího, co není potřeba

Nastavení 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)
  • shell> mkdir /tmp/mysqltmp
    shell> echo "tmpfs /tmp/mysqltmp tmpfs rw,size=300,nr_inodes=10k,mode=0700,uid=mysql,gid=mysql 0 0" >> /etc/fastab
    shell> mount /tmp/mysqltmp

  • 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
  • [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
    
  • k otestování parametrů DB můžeme použít některý s nástrojů jako třeba mysqltuner
  • výkonostně zajímavým řešením je rozdělení databáze tzv. partitioning v přápadě zájmu viz uvedený odkaz

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.

  • Monitoring → Graphs : Zabbix internal process busy % zoobrazuje jak si na tom stojí procesy, které se starají o aktualizaci a konzistenci dat v databázi, synchronizaci databáze s internímy procesy a mazazání starých dat (historie, trendy) v databázi


  • Monitoring → Graphs : Zabbix data gethering process busy % Zde naopak vidíme stav procesů, které se starají o monitoring, komunikaci s agenty, jinými proxy servery, atd.
  • 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/

    Verze pro tisk

    pridej.cz

     

    DISKUZE

    Nejsou žádné diskuzní příspěvky u dané položky.



    Příspívat do diskuze mohou pouze registrovaní uživatelé.
    > Vyhledávání software
    > Vyhledávání článků

    16.7.2018 1:05 /František Kučera

    Červencový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 7. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát bude přednáška na téma: automatizační nástroj Ansible, kterou si připravil Martin Vicián.


    Přidat komentář

    18.6.2018 0:43 /František Kučera
    Červnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 21. 6. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: F-Droid, aneb svobodný software do vašeho mobilu. Kromě toho budou k vidění i vývojové desky HiFive1 se svobodným/otevřeným čipem RISC-V.
    Přidat komentář

    23.5.2018 20:55 /Ondřej Čečák
    Od pátku 25.5. proběhne na Fakultě informačních technologií ČVUT v Praze openSUSE Conference. Můžete se těšit na spostu zajímavých přednášek, workshopů a také na Release Party nového openSUSE leap 15.0. V na stejném místě proběhne v sobotu 26.5. i seminář o bezpečnosti CryptoFest.
    Přidat komentář

    20.5.2018 17:45 /Redakce Linuxsoft.cz
    Ve čtvrtek 31. května 2018 připravuje webový magazín BusinessIT ve spolupráci s Best Online Média s.r.o. pátý ročník odborné konference Firemní informační systémy 2018. Akce proběhne v kongresovém centru Vavruška (palác Charitas), Karlovo náměstí 5, Praha 2 (u metra Karlovo náměstí) od 9:00 hod. dopoledne do cca 15 hod. odpoledne. Konference je zaměřena na efektivní využití firemních informačních systémů a na to, jak plně využít jejich potenciál. Podrobnější informace na webových stránkách konfrence.
    Přidat komentář

    14.5.2018 7:28 /František Kučera
    Květnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 17. 5. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: Audio – zvuk v GNU/Linuxu.
    Přidat komentář

    7.5.2018 16:20 /František Kučera
    Na stránkách spolku OpenAlt vyšla fotoreportáž Pražské srazy 2017 dokumentující srazy za uplynulý rok. Květnový pražský sraz na téma audio se bude konat 17. 5. 2018 (místo a čas ještě upřesníme).
    Přidat komentář

    17.4.2018 0:46 /František Kučera
    Dubnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 4. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tématem tohoto srazu bude OpenStreetMap (OSM) aneb svobodné mapy.
    Přidat komentář

    16.3.2018 22:01 /František Kučera
    Kulatý OpenAlt sraz v Praze oslavíme klasicky: u limonády a piva! Přijďte si posedět, dát si dobré jídlo a vybrat z mnoha piv do restaurace Kulový blesk, který najdete v centru Prahy nedaleko metra I. P. Pavlova na adrese Sokolská 13, Praha 2. Sraz se koná ve čtvrtek 22. března a začínáme v 18:00. Heslo: OpenAlt. Vezměte s sebou svoje hračky! Uvítáme, když si s sebou na sraz vezmete svoje oblíbené hračky. Jestli máte nějaký drobný projekt postavený na Arduinu, nějakou zajímavou elektronickou součástku, či třeba i pěkný úlovek z crowdfundingové akce, neváhejte. Oslníte ostatní a o zábavu bude postaráno.
    Přidat komentář

       Více ...   Přidat zprávičku

    > Poslední diskuze

    20.2.2018 18:48 / Ivan Majer
    portal

    20.2.2018 15:57 / Jan Havel
    Jak využíváte služby cloudu v podnikání?

    16.1.2018 1:08 / Ivan Pittner
    verejna ip od o2 ubuntu

    15.1.2018 17:26 / Mira Harvalik
    Re: Jak udělat HTML/Javascript swiping gallery do mobilu?

    30.12.2017 20:16 / Michal Knoll
    odmocnina

    Více ...

    ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2018) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze