023-zabbix性能優化中的幾個中肯建議

隨着zabbix的普遍應用，少數人的zabbix服務器在性能上出現瓶頸，或者在將來會出現性能方面的瓶頸，接下來討論幾個有效而且簡單的優化方案。

服務器硬件

想經過幾個簡單的配置讓服務器提升成倍的性能，想法很好，可是基本不太現實。簡單的說，你須要搭配更好的CPU、更大的內存，更快的硬盤：條件容許的花，能夠考慮購買SSD，它比更大的cpu和更大的內存帶來的效果更好，或者考慮使用SAS 15K硬盤，組raid等等，總之一句話，配置優化不動的狀況，增長硬件投入，別絞盡腦汁搜索：zabbix如何優化之類的文章，你在浪費時間。

操做系統

使用最新的操做系統，優化、定製化操做系統內核。應該會有些做用，可是確定不大。

數據庫優化

DBsock優化

若是MySQL和zabbix server在同一臺服務器上，socket鏈接要比tcp鏈接要更快。

數據庫分離

將數據庫服務器獨立，數據庫和zabbix資源互相獨立，例如：能夠購買一臺RDS

數據庫引擎

使用MySQL5.6或者更高版本，自從MySQL被Oracle收購了，它的性能確實有很多的提高。請必定選擇innodb，別選擇myisam，由於zabbix在innodb的性能比在myisam快1.5倍，並且myisam不安全，zabbix監控數據量很大，一旦表壞了，那就是一個悲劇。

mysql分區，history等等表數據量較大，能夠試着分區替身性能。

其餘優化

一、減小history保存時間

二、減小item獲取間隔時間

三、減小沒必要要的監控項

在條件不容許或者以上方法都無效的狀況下，請必定考慮以上建議。在監控環境中，以上三點是你們都在犯的錯誤，大部分item是不須要保存太長的數據，有些監控項根本無心義，有些監控項的間隔時間過短。一直以來我都在犯這個錯，可是由於zabbix性能一直不錯，暫時不糾正，數據多點總比少點好，是否是~

 

 

 

 

 

1. Zabbix性能變慢的可能表現：

• zabbix隊列有太多被延遲的item，能夠經過administration-queue查看
• zabbix繪圖中常常出現斷圖，一些item沒有數據
• 帶有nodata()函數的觸發器出現flase
• 前端頁面無響應，或者響應慢
  

  a.經過Zabbix agent採集數據的設備處於moniting的狀態可是此時機器死機或其餘緣由致使zabbix agent死掉server獲取不到數據，此時unreachable poller
  就會升高。
  b.經過Zabbix agent採集數據的設備處於moniting的狀態可是server向agent獲取數據時時間過長，常常超過server甚至的timeout時間，此時unreachable poller就會升高。

   如何度量Zabbix性能:

         經過Zabbix的NVPS(每秒處理數值數)來衡量其性能。在Zabbix的dashboard上有一個錯略的估值。

  

2. Zabbix性能優化的幾點原則：

• 確保zabbix內部組件性能處於被監控狀態(調優的基礎！)
• 使用硬件性能足夠好的服務器
• 不一樣角色分開，使用各自獨立的服務器
• 使用分佈式部署
• 調整MySQL性能
• 調整Zabbix自身配置

3. Zabbix變慢的幾個緣由總結以下：

• Zabbix server硬件配置，建議更好的CPU、更大的內存，更快的硬盤
• Zabbix架構，若總體架構過大，建議使用分佈式proxy，各服務器功能獨立
• 數據量太大，vps過高，zabbix來不及處理
• Housekeeper設置不當，數據庫體積變大
• 前端主機太多，查詢過多的數據
• Item工做模式及Triggers優化，Triggers太過複雜

   

3.1 瞭解Zabbix目前的工做狀態

     得到zabbix內部狀態

         zabbix[wcache,values,all]

          zabbix[queue,1m]   ----延遲超過1分鐘的item

     

    得到zabbix內部組件工做狀態(該組件處於BUSY狀態的時間百分比)

       zabbix[process,type,mode,state]

    其中可用的參數爲:

• type: trapper,discoverer,escalator,alerter,etc
• mode: avg,count,min,max
• state: busy,idel

     
     

3.2 Zabbix性能優化---Item工做模式及Triggers優化

• 添加proxy節點，減小了server端的負荷。（下面方法無用，再使用此辦法）
• Zabbix中的item默認工做是被動模式，能夠經過設置主動模式來提升server的性能。   

   主要講講採用主動模式，若採用active checks模式:

  ①zabbix_agentd.conf配置調整

1 2 3 4 5 6 7 8

LogFile=/tmp/zabbix_agentd.log Server=xxx.xxx.xxx.xxx    server端ip ServerActive=xxx.xxx.xxx.xx   指定Agentd收集的數據往哪裏發送 Hostname=yyy.yyy.yyy.yyy   agent的hostname ，必需要和Server端添加主機時的主機名對應 RefreshActiveChecks=60 BufferSize=10000 MaxLinesPerSecond=200 Timeout=30

     比較重要的參數是ServerActive和Hostname，ServerActive是指定Agentd收集的數據往哪裏發送，Hostname是必需要和Server端添加主機時的主機名對應起來，這樣Server端接收到數據才能找到對應關係，這裏爲了兼容被動模式，沒有把StartAgents設爲0，若是一開始就是使用主動模式的話建議把StartAgents設爲0，關閉被動模式。
  ②zabbix_server.conf 配置調整

    StartPollers=100     減小主動收集數據進程，由原來的500---100，減少
    StartTrappers=200    負責處理Agentd推送過來的數據的進程，由原來的50---100 ，變大

  ③模板調整

    a. 以任何一個現有模板爲例，clone並重命名，假如重命名模板爲TEST
    b. 將模板TEST裏全部items和discovery rules裏的items都變動type爲atvice agent

    至此active-checks模式的agent部署完畢，能夠在overview中查看模板中的監控項。

    Tigger中正則表達式函數last()、nodata()的速度是最快的。。。Min()、max()、avg()是最慢的。。。儘可能使用速度快的函數

3.3  數據量太大，vps過高，zabbix來不及處理

    經過如下圖，可看出哪一個item致使慢：     若more than 10 min 有數據則表示對應的Item數據量過大。

解決辦法：

• 修改監控項
• 調整Item的時間間隔（主要辦法）       將zabbix agent監控 timeout時間增大

備註：

調整unsupport items檢查時間的方法是：在Adiministration裏選擇General而後在右側下拉菜單裏選擇Other，而後修改Refresh unsupported items (in sec)的值，表示「每多少秒去從新檢查一下那些not_supported的值」。

3.4 調整MySQL性能

 採用分佈式架構，性能瓶頸的最大可能出如今數據庫中。

• 關閉housekeeper， 將history分區
• 將zabbix_server.conf中的StartDBSyncers參數上調，表示將數據從zabbix寫入數據庫的進程是多少

  • 原由：近幾日zabbix報警的恢復時間變得很長，頁面有卡頓的現象。抓包查看發現，確實是收到了最近正常的值，可是面板不更新，從新zabbix_server進程，才能完成面板更新。

    1. Zabbix性能概述

    當zabbix性能低時會出現多種情況，Zabbix前端頁面出現無響應、卡頓、列隊沒法更新，zabbix圖形中常常出現斷圖，無圖。一些item獲取不到數據。列隊中出現大多被延遲的item

    如何判斷zabbix-server性能

    首頁導航中經過zabbix狀態能夠看到zabbix的主機數量、監控項的數目、觸發器的數目。並經過zabbix的NVPS（每秒處理數值數）衡量性能標準，NVPS是經過PHP代碼編寫實現的計算，從整體上反映出了zabbix-server的處理速度。

    NVPS與History的保留時間和Trends的保留時間都有直接關係。以下圖中zabbix狀態性能提高空間還很大，能夠調整主機模版、修改被禁用和不支持的監控項及觸發器。

     

    我這裏由於服務器比較老，再加上zabbix，mysql都是比較老的因此數字會很低

    能夠經過看zabbix對於自己server列隊的監控，來肯定是什麼類型的監控項形成的性能問題，見下圖。等待的列隊越多、時間越長，說明zabbix-server性能越差。能夠針對受影響的監控類型作調整，好比調整監控項的時間間隔，或者根據監控類型定製模版，將模版寫到最簡。若是以上方法仍是沒有效果，那麼就說明zabbix server壓力過大，採用搭建proxy分佈式架構，將server的壓力分擔給proxy

     

    上圖是我調整後的

    調整前

     

    從上圖能夠看出有幾個監控項延遲達到3年。。。。。

    先將這幾個延遲超長的監控項禁用掉，完事看看隊列是否有變化

    2. Zabbix配置文件優化

    Zabbix自帶模版還會監控各工做進程的狀態，可對數據收集過程當中的性能作分析，見下圖，數據採集過程和使用緩存的空間容量。須要特別注意的有：

    Zabbix busy housekeeper processes,in %##管家處理數據佔緩存的百分比

    Zabbix busy history syncer processes,in %##寫入數據庫的同步程序佔緩存的百分比

    Zabbix busy poller processes,in % ## zabbix輪詢進程佔比

    Zabbix busy unreachable poller processes in %##不可達的輪詢進程佔比

     

     

     

     

    root@localhost ~]# vim /etc/zabbix/zabbix_server.conf
    
    #配置文件前面內容爲初始安裝zabbix時須要配置的基本參數。找到高級配置這一行開始，涉及優化內容用紅色標識填充
    
    ############ ADVANCED PARAMETERS #################
    
    ### Option: StartPollers
    
    # Number of pre-forked instances of pollers.
    
    #
    
    # Mandatory: no
    
    # Range: 0-100
    
    # Default:
    
    StartPollers=5
    
    #填寫範圍0-100，默認5 。輪詢處理監控項的進程數，增長太大會影響服務器自己性能，保持此參數的值儘量低，20000個監控項大概控制在80左右便可。
    
    StartIPMIPollers=0
    
    #IPMI輪詢進程實例個數，服務器使用IPMI協議監控時須要更改此項，默認0爲關閉
    
    StartPollersUnreachable=10
    
    #不可達主機輪詢數量。此值特別耗費性能，設置在10-20之間便可，默認1
    
    StartTrappers=5
    
    #負責處理agents和proxy推送過來的數據的進程數，默認爲5，若是zabbix-agent監控類型較多須要加大此參數
    
    StartPingers=1
    
    # ICMP- ping進程輪詢實例數，默認爲1.，建議更改成20-50之間，根據業務填寫便可。
    
    StartDiscoverers=1
    
    #自動發現子進程實例數，默認爲1，範圍0-250
    
    StartHTTPPollers=1
    
    #HTTP進程輪詢實例個數，默認1，範圍0-1000，web監控很少選擇默認便可
    
    HousekeepingFrequency=1
    
    #zabbix執行管家的頻率，從數據庫中刪除過時的數據。爲了防止 housekeeper 過載 (例如, 當歷史和趨勢週期大大減少時), 對於每個item，不會在一個housek週期內刪除超過4倍HousekeepingFrequency 的過期信息. 所以, 若是 HousekeepingFrequency 是 1, 一個週期內不會刪除超過4小時的過期信息，爲了下降server壓力，kousekeeping延後server啓動30分鐘，默認爲1，最大24，爲0時關閉使用。
    
    MaxHousekeeperDelete=5000
    
    #執行一個Housekeeping週期時，默認刪除的數據條目數。默認5000條。若是設置爲0，不限制刪除的行數，這種狀況數據庫多數會崩潰。
    
    CacheSize=8M
    
    #緩存大小，單位字節。用於存儲主機、監控項、觸發器數據的共享內存大小，默認8M最大8G。根據自身zabbix業務需求配置合理的參數。
    
    CacheUpdateFrequency=60
    
    #zabbix緩存更新頻率，單位秒。設置範圍1-3600
    
    HistoryCacheSize=1024M
    
    #歷史數據緩存大小，單位字節
    
    TrendCacheSize=256M
    
    #趨勢數據緩存大小，單位字節。用於存儲趨勢數據的共享內存大小
    
    ValueCacheSize=1024M
    
    #歷史數據緩存大小, 單位bytes.緩存item歷史數據請求的共享內存大小.0即禁止緩存（不建議這麼作）
    
    Timeout=3
    
    #agent, SNMP 設備或外部檢查的超時時長(單位秒),填寫範圍1-30
    
    以上爲配置優化主要參數，其餘內容配置文件中均有簡要說明，可根據業務需求更改優化。對配置參數進行合理的設置會使zabbix處於正常的工做狀態。值越大，越高消耗的CPU和內存越多。修改配置文件後，須要重啓zabbix-server進程。加載新配置生效
    當以上方法不能有效時，建議清楚一下趨勢數據。固然若是有保存的需求，那就只能作分片了（本文不涉及分片）。

    truncate table history; truncate table history_str; truncate table history_uint;truncate table trends; truncate table trends_uint;