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等等表數據量較大，可以試着分區替身性能。

其他優化

1、減少history保存時間

2、減少item獲取間隔時間

3、減少不必要的監控項

在條件不允許或者以上方法都無效的情況下，請一定考慮以上建議。在監控環境中，以上三點是大家都在犯的錯誤，大部分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;