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 7794×

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ů

    1.12.2016 22:13 /František Kučera
    Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.
    Komentářů: 1

    4.9.2016 20:13 /Pavel `Goldenfish' Kysilka
    PR: Dne 22.9.2016 proběhne v Praze konference Cloud computing v praxi. Tématy bude např. nejnovější trendy v oblasti cloudu a cloudových řešení, provozování ERP v cloudu, o hostování různých typů softwaru, ale třeba i o zálohování dat nabízeném podnikům formou služby.
    Přidat komentář

    1.9.2016 11:27 /Honza Javorek
    Česká konference o Pythonu, PyCon CZ, stále hledá přednášející skrz dobrovolné přihlášky. Máte-li zajímavé téma, neváhejte a zkuste jej přihlásit, uzávěrka je již 12. září. Konference letos přijímá i přednášky v češtině a nabízí pomoc s přípravou začínajícím speakerům. Řečníci mají navíc vstup zadarmo! Více na webu.
    Přidat komentář

    27.8.2016 8:55 /Delujek
    Dnes po 4 letech komunitního vývoje vyšla diaspora 0.6.0.0
    diaspora* je open-source, distribuovaná sociální síť s důrazem na soukromý
    Více v oficiálním blog-postu
    Přidat komentář

    24.8.2016 6:44 /Ondřej Čečák
    Poslední týden CFP LinuxDays 2016; pokud byste rádi přednášeli na LinuxDays 2016 8. a 9. října v Praze, můžete svůj příspěvek přihlásit, následovat bude veřejné hlasování.
    Přidat komentář

    9.8.2016 22:56 /Petr Ježek
    Zařazení souborového systému reiser4 do jádra 4.7 znamená konečně konec patchování jádra jen kvůli možnosti použít reiser4.
    Přidat komentář

    12.7.2016 13:14 /František Kučera
    Spolek OpenAlt zve na 130. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 21. července od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
    Přidat komentář

    11.7.2016 16:53 /Redakce Linuxsoft.cz
    Konference LinuxDays hledá přednášející. Přihlášky poběží do konce prázdnin, v září bude hlasování a program. Více na https://www.linuxdays.cz/2016/cfp/.
    Přidat komentář

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

    > Poslední diskuze

    10.12.2016 11:01 / jeorge
    kitchen designer

    7.12.2016 8:10 / Hamon
    scottish cottages

    4.12.2016 22:54 / František Kučera
    Dárek

    9.11.2016 7:42 / Mane
    hardwood floor waxing

    8.11.2016 13:38 / Mira
    Konfigurace maldet na Centos serveru

    Více ...

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