Zabbix 5.0:服務端程式總結

不羈的羅恩發表於2022-03-03

Blog:部落格園 個人
參考:《深入理解Zabbix監控系統》、《Zabbix使用者手冊》

Zabbix服務端程式被分為不同的種類,每一種程式負責相應的任務,包括收集原始監控資料、對原始監控資料進行預處理、將預處理後的監控資料同步到資料庫、對監控資料進行計算以生成事件、計算和獲取內部監控資料,以及對資料庫中的資料進行清理等。

監控資料的收集程式

Zabbix伺服器的重要任務之一就是被動接收由Zabbix代理和各種Zabbix客戶端傳送的監控資料,以及主動向Zabbix代理、Zabbix java gateway和Zabbix客戶端等資料來源請求資料,其中被動接收資料由trapper類程式實現,主動請求資料則由poller類程式實現。

trapper類程式通過監聽TCP套接字來捕獲符合通訊協議的原始監控資料,poller類程式則使用ConfigCache作為輸入,根據快取資訊實現完善的任務排程。trapper類和poller類程式的下游是預處理程式,這兩類程式需要將收集到的原始監控資料傳送到預處理程式。trapper類程式和poller類程式都會在程式內部維護一個靜態變數cached_message,用於暫存待傳送的監控資料,並在各種必要的時機將該變數中的訊息傳送到預處理程式。

trapper類程式

Zabbix伺服器端的trapper程式負責接收來自Zabbix客戶端、Zabbix代理、zabbix_sender及其他外部程式發來的請求並進行處理,按照Zabbix 5.0的通訊協議規範,trapper程式只能接收JSON格式字串的請求。

trapper程式由配置檔案中的StartTrappers引數決定其啟動數量(允許啟動0~1000個程式,預設為5個)。

[root@prod-zabbix-server ~]# ps -ef|grep trapper
zabbix    8740  8643  0 Feb21 ?        01:55:26 /usr/sbin/zabbix_server: trapper #1 [processed data in 0.001288 sec, waiting for connection]
zabbix    8741  8643  0 Feb21 ?        01:13:24 /usr/sbin/zabbix_server: trapper #2 [processed data in 0.000863 sec, waiting for connection]
zabbix    8742  8643  0 Feb21 ?        01:02:48 /usr/sbin/zabbix_server: trapper #3 [processed data in 0.000664 sec, waiting for connection]
zabbix    8743  8643  0 Feb21 ?        01:55:36 /usr/sbin/zabbix_server: trapper #4 [processed data in 0.000788 sec, waiting for connection]
zabbix    8744  8643  0 Feb21 ?        01:43:59 /usr/sbin/zabbix_server: trapper #5 [processed data in 0.000802 sec, waiting for connection]

?注意:至少要執行一個trapper程式用於在web前端展示伺服器可用性和佇列檢視。

總體而言,trapper程式所做的事情就是迴圈從TCP 套接字讀取請求訊息,然後根據訊息型別呼叫不同的函式進行處理,處理完畢後關閉該套接字連線。即每個迴圈處理一個請求,每個請求的處理都是在新的連線中進行通訊的。

資料處理:

  • 處理agent data和sender data請求:兩者處理過程類似,唯一區別是驗證過程,agent data要求監控項屬於主動客戶端(active agent)型別,而傳送者資料(sender data)要求監控項屬於Zabbix trapper型別。請求的過程中,trapper程式的作用在於驗證資料的有效性,包括監控項狀態、監控項型別和主機狀態等。
  • 處理proxy config請求:將Zabbix伺服器的配置資訊傳輸到Zabbix代理。可以由Zabbix代理髮送到Zabbix伺服器(主動模式,預設),也可以由Zabbix伺服器傳送到Zabbix代理(被動模式)。
  • 處理proxy data請求:可能由Zabbix伺服器或者被動模式下的Zabbix代理來處理。如果是Zabbix伺服器,說明它接收了一批來自Zabbix代理的監控值,此時需要將資料寫入快取或者進行LLD(Low-level discovery,自動發現)處理;如果是被動代理,說明它接收了Zabbix伺服器傳送的資料請求,此時需要做的是將監控資料回覆給Zabbix伺服器。從Zabbix 5.0開始,Zabbix代理具有了預處理的能力,所以proxy data中的監控值其實是已經預處理過的,不需要在Zabbix伺服器端再次預處理。
snmp trapper程式

snmp trapper程式由配置引數StartSNMPTrapper決定其啟動數量(允許0或1個程式),預設為0。該程式的工作方式是迴圈呼叫get_latest_data()和read_traps()函式,從trap檔案(檔案路徑由SNMPTrapperFile配置引數決定)中讀取資料,然後呼叫parse_traps()函式進行解析處理。

poller類程式

poller類程式是指以主動方式獲取原始監控資料的程式,包括poller程式、unreachable poller程式、ipmi manager/poller程式、icmp pinger程式、javapoller程式、proxy poller程式和http poller程式,一共有7種,它們各自負責採集不同型別的監控項資料。與trapper類程式不同的是,poller類程式需要自己執行監控資料採集邏輯,每一種監控項都需要呼叫不同的函式進行處理才能得到監控資料,而trapper類程式可以直接接收監控資料。從這個角度來說,對於同樣數量的監控任務,使用poller工作方式要比使用trapper工作方式的負載更高

工作機制

poller類程式首先需要解決的問題是如何排程資料採集過程,以保證大量資料採集任務的執行順序和間隔是正確且準確的。此外,每一種程式都並非唯一的,所以還要保證多程式之間的協調,避免衝突。Zabbix的解決方案是通過ConfigCache中定義的6個二叉堆結構來確定資料採集任務的執行順序和間隔。

多程式之間的衝突問題,解決方法是使用ConfigCache互斥鎖,即在訪問二叉堆之前加鎖,在訪問結束以後解鎖,從而保證同一時間只有一個程式在訪問。

poller程式

poller程式能夠處理除IPMI型別之外的所有監控項的資料採集,包括Zabbix客戶端(Zabbix agent)監控項、簡單檢查(Simple check)監控項、SNMP客戶端(SNMP agent)監控項、Zabbix內部(Zabbix internal)監控項、Zabbix聚合(Zabbix aggregate)監控項、外部檢查(External check)監控項、資料庫監視(Database monitor)監控項、HTTP客戶端(HTTP agent)監控項、SSH客戶端(SSH agent)監控項、TELNET客戶端(TELNET agent)監控項、JMX客戶端(JMX agent)監控項以及計算型(Calculated)監控項,共12種。

Zabbix客戶端監控項處理

poller程式對Zabbix客戶端(Zabbix agent)監控項進行處理的過程實際上就是以TCP套接字客戶端的身份與作為伺服器端的Zabbix客戶端進行通訊的過程。因此,當poller程式需要處理大量Zabbix客戶端監控項時,會同時與很多Zabbix客戶端建立TCP連線。(同一時刻每個程式最多建立一個連線,用後即關閉。)

unreachable poller程式

在網路通訊良好並且各方服務正常的情況下,poller程式所處理的Zabbix客戶端和SNMP客戶端監控項,以及IPMI程式處理的IPMI客戶端(IPMIagent)監控項和java poller程式處理的JMX監控項,都能夠成功執行並獲取監控資料。但是,當出現agent服務故障時,如果繼續由原來的poller類程式處理對應的監控項,大量的連線超時就有可能引起整體服務水平下降。unreachable poller程式就是對該問題的解決方案,當客戶端(包括Zabbix客戶端、SNMP客戶端、IPMI客戶端和JMX客戶端)服務不可用時,對應的監控項會轉移到unreachable poller佇列中處理。當unreachable poller程式發現某個客戶端已經恢復正常時,則將對應的監控項再轉移回原始佇列中。

一般情況下,由於大部分客戶端狀態是良好的,因此unreachable poller程式的負載並不高。但是,一旦發生大面積網路故障,會有大量監控項轉移到unreachablepoller程式的任務佇列中,此時程式的負載會飆升。如果要降低負載,可以考慮增加UnavailableDelay引數值,或者增加unreachable poller程式的啟動數量。

總結

Zabbix支援兩種收集監控資料的模式,在Zabbix伺服器端表現為同時存在trapper類程式和poller類程式。

trapper類程式用於被動接收來自Zabbix客戶端或者Zabbix代理的監控資料;poller類程式用於主動發起連線並向被監控物件請求監控資料。trapper類程式包括純trapper程式和snmp trapper程式,前者用於從Zabbix客戶端和Zabbix代理接收監控資料,後者用於從snmp trap檔案讀取監控資料。當採用拉的工作模式時,由於每種監控項的具體拉取方式存在較大區別,因此poller類程式進一步劃分為多種程式,包括純poller程式、unreachable poller程式、ipmi manager與ipmi poller程式、icmp pinger程式、java poller程式、proxy poller程式和http poller程式。每一種poller程式負責拉取相應型別的監控資料。

預處理程式

預處理(preprocessing)程式是從Zabbix 3.4開始新增的一種程式型別,它用於對原始的監控資料進行各種形式的變換和計算,並通過共享記憶體,將輸出結果傳遞到history syncer程式進行處理。在Zabbix的早期版本中,預處理程式只能執行在Zabbix伺服器端,當資料量大時會給Zabbix伺服器端造成較大的壓力。因此從Zabbix 4.2版本開始,預處理程式可以同時執行在Zabbix伺服器端和Zabbix代理端。在這種情況下,由Zabbix代理負責採集的監控資料在傳輸到Zabbix伺服器端之前就已經完成了預處理,直接從Zabbix客戶端傳輸到Zabbix伺服器端的資料則需要由Zabbix伺服器端完成預處理。

[root@prod-zabbix-server ~]# ps -ef|grep preprocessing
zabbix    8652  8643  0 Feb21 ?        00:47:49 /usr/sbin/zabbix_server: preprocessing manager #1 [queued 0, processed 716 values, idle 5.029540 sec during 5.035809 sec]
zabbix    8653  8643  0 Feb21 ?        00:13:20 /usr/sbin/zabbix_server: preprocessing worker #1 started
zabbix    8654  8643  0 Feb21 ?        00:04:00 /usr/sbin/zabbix_server: preprocessing worker #2 started
zabbix    8655  8643  0 Feb21 ?        00:03:44 /usr/sbin/zabbix_server: preprocessing worker #3 started
zabbix    8656  8643  0 Feb21 ?        00:03:35 /usr/sbin/zabbix_server: preprocessing worker #4 started
zabbix    8657  8643  0 Feb21 ?        00:03:29 /usr/sbin/zabbix_server: preprocessing worker #5 started
zabbix    8658  8643  0 Feb21 ?        00:03:23 /usr/sbin/zabbix_server: preprocessing worker #6 started
zabbix    8659  8643  0 Feb21 ?        00:03:25 /usr/sbin/zabbix_server: preprocessing worker #7 started
zabbix    8660  8643  0 Feb21 ?        00:02:28 /usr/sbin/zabbix_server: preprocessing worker #8 started
zabbix    8661  8643  0 Feb21 ?        00:02:17 /usr/sbin/zabbix_server: preprocessing worker #9 started
zabbix    8662  8643  0 Feb21 ?        00:02:18 /usr/sbin/zabbix_server: preprocessing worker #10 started

以上命令結果可知,preprocessing程式由1個preprocessing manager(管理者程式)和多個preprocessing worker(工作者程式)程式組成。

processing manager程式負責監聽預處理所使用的Unix域套接字並處理由poller / trapper程式和preprocessing worker程式傳送過來的訊息。還會向lld manager程式傳送訊息,因為原始監控資料中同時包含LLD規則監控項資料,這些資料在預處理完畢以後還需要進行LLD處理(由lld manager和lld worker程式完成)

預處理工作者(preprocessing worker)程式的數量由配置引數StartPreprocessors決定,允許1~1 000個程式。工作者程式負責讀取管理者程式傳送的程式間通訊服務訊息,並執行所獲得的任務。

LLD程式

LLD程式是從Zabbix 5.0開始出現的專門負責LLD規則(LLD rule)監控資料處理的程式,由於底層發現(Low Level Discovery,LLD)得到越來越多的應用,因此這類資料的處理壓力隨之增加,將這些工作交給單獨的程式來處理將有利於效能的提升和將來的進一步擴充套件。

LLD程式包括lld manager程式和lld worker程式兩種,其中管理者程式是唯一的,工作者程式可以啟動多個。LLD程式只能執行在Zabbix伺服器端,它們位於預處理程式的下游,接收預處理程式傳送的訊息作為輸入,而輸出則是對各項監控配置的更新操作。本質上,LLD就是通過解析LLD規則監控項(一種特殊型別的監控項,其配置資訊儲存在items表中,其監控值不用於儲存,只用於更新監控配置)返回的特殊格式的字串,建立、更新或者刪除監控項、觸發器、圖表或主機,使之與返回結果保持一致。由於LLD規則監控值會按照設定的頻率進行更新,因此Zabbix可以隨著資料的更新而動態調整監控物件、監控指標和監控引數等。從Zabbix 4.2開始,LLD規則的監控值跟普通監控項一樣可以進行預處理,在預處理結束以後,LLD程式再對資料進行解析並更新配置資訊,這一方式賦予使用者更多對LLD規則資料進行處理的能力,從而增強了底層發現的功能。

[root@prod-zabbix-server ~]# ps -ef|grep lld
zabbix    8663  8643  0 Feb21 ?        00:01:33 /usr/sbin/zabbix_server: lld manager #1 [processed 15 LLD rules, idle 5.385801sec during 5.385996 sec]
zabbix    8664  8643  0 Feb21 ?        00:29:15 /usr/sbin/zabbix_server: lld worker #1 [processed 14 LLD rules, idle 6.001249 sec during 6.150509 sec]
zabbix    8665  8643  0 Feb21 ?        00:29:28 /usr/sbin/zabbix_server: lld worker #2 [processed 15 LLD rules, idle 8.471019 sec during 8.725697 sec]

lld manager程式雖然只有一個,但是其需要完成的任務有多種,包括註冊lldworker程式、接收其他程式傳送的訊息、給lld worker程式分配任務、處理lldworker程式返回的結果以及響應佇列長度請求等。

lld worker程式負責處理lld manager程式分配的任務,即接收並處理通過程式間通訊服務傳送過來的code 1100訊息。總體的處理過程包括解析訊息,驗證LLD規則有效性(通過ConfigCache),載入filter、LLD macros和overrides,解析LLD訊息的JSON陣列,進行配置資訊更新,以及根據LLD規則監控項狀態生成內部事件。lld worker程式的工作機制是被動模式,即發出註冊訊息以後,並不會主動向管理者程式請求任務,而是等待管理者程式分配任務。

image-20220303143549989

預處理程式和LLD程式處於poller類程式和trapper類程式的下游,負責處理poller類程式和trapper類程式獲取的原始監控資料。預處理程式按照使用者設定的處理規則對資料進行變換和計算,處理之後的資料傳遞給history syncer程式處理。預處理程式通過程式間通訊服務方式與上游程式通訊。處理之後的資料寫入共享記憶體,供下游程式使用

history syncer程式

history syncer程式是Zabbix伺服器端最為核心的程式,它負責將監控資料(包括趨勢資料)寫入資料庫和寫入快取、生成並處理事件,以及處理動作(action)並生成升級序列(escalation)等。如果沒有history syncer程式,Zabbix伺服器將什麼也做不了:既不能處理監控資料,又不能生成事件,也不能進行告警。history syncer程式位於預處理程式的下游,它將預處理程式寫入HistoryCache和HistoryIndexCache的資料作為輸入。

history syncer程式的啟動數量由配置檔案中的StartDBSyncers引數控制,允許1~100個程式。history syncer程式的作用是將HistoryCache和HistoryIndexCache中的監控值寫入資料庫中的history表和trends表,同時根據監控值計算觸發器表示式,決定是否觸發事件。該程式在Zabbix伺服器端和Zabbix代理端都存在,但是有所不同,這一點體現在程式碼清單9-1所示的程式標題中。在Zabbix伺服器端時,該程式既需要處理監控值(values),也需要處理觸發器(triggers),在Zabbix代理端時,該程式只需要處理監控值,而不需要處理觸發器,因為觸發器表示式統一由Zabbix伺服器端處理。本章講述Zabbix伺服器端的處理過程。

[root@prod-zabbix-server ~]# ps -ef|grep history
zabbix    8720  8643  0 Feb21 ?        00:30:13 /usr/sbin/zabbix_server: history syncer #1 [processed 10 values, 8 triggers in 0.004174 sec, idle 1 sec]
zabbix    8721  8643  0 Feb21 ?        00:30:28 /usr/sbin/zabbix_server: history syncer #2 [processed 12 values, 5 triggers in 0.004013 sec, idle 1 sec]
zabbix    8722  8643  0 Feb21 ?        00:30:38 /usr/sbin/zabbix_server: history syncer #3 [processed 24 values, 7 triggers in 0.006277 sec, idle 1 sec]
zabbix    8723  8643  0 Feb21 ?        00:30:21 /usr/sbin/zabbix_server: history syncer #4 [processed 4 values, 3 triggers in 0.004239 sec, idle 1 sec]
zabbix    8724  8643  0 Feb21 ?        00:30:30 /usr/sbin/zabbix_server: history syncer #5 [processed 236 values, 146 triggers in 0.058686 sec, idle 1 sec]
zabbix    8725  8643  0 Feb21 ?        00:30:18 /usr/sbin/zabbix_server: history syncer #6 [processed 0 values, 0 triggers in 0.000022 sec, idle 1 sec]

處理動作相關程式

escalator程式用於處理事件觸發的整個動作序列,該程式讀取escalations表中的資料並進行處理,並將生成的警報訊息插入alerts表中,供alerter程式使用。所以,escalator程式並不實際傳送警報訊息,而只生成警報。

[root@prod-zabbix-server ~]# ps -ef|grep escalator
zabbix    8726  8643  0 Feb21 ?        00:00:32 /usr/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.001072 sec, idle 3 sec]

alerter程式族用於實際傳送警報,該程式族包括alert syncer程式、alert manger程式和alerter程式。alert syncer程式負責將資料庫中的警報資訊和媒體型別資訊同步到alert manager程式,具體方法是從資料庫讀取資料,然後構造為程式間通訊服務訊息併傳送到alert manager程式。alert manager程式負責向alerter程式分發警報處理任務,並接收alerter程式反饋的結果。alerter程式負責按照alertmanager分配的任務處理警報並反饋結果。task manager程式執行在Zabbix伺服器端和Zabbix代理端,它負責處理儲存在資料庫task表中的遠端命令(remote command)、立即檢查(check now)、問題確認(problem acknowledge)和問題關閉(problem close)等任務。

[root@prod-zabbix-server ~]# ps -ef|grep alert
zabbix    8645  8643  0 Feb21 ?        00:00:44 /usr/sbin/zabbix_server: alert manager #1 [sent 0, failed 0 alerts, idle 5.006731 sec during 5.006787 sec]
zabbix    8646  8643  0 Feb21 ?        00:00:00 /usr/sbin/zabbix_server: alerter #1 [sent 0, failed 0 alerts, idle 657.095715 sec during 657.405902 sec]
zabbix    8647  8643  0 Feb21 ?        00:00:00 /usr/sbin/zabbix_server: alerter #2 [sent 0, failed 0 alerts, idle 656.705429 sec during 657.122473 sec]
zabbix    8648  8643  0 Feb21 ?        00:00:00 /usr/sbin/zabbix_server: alerter #3 [sent 0, failed 0 alerts, idle 656.675887 sec during 657.107786 sec]
zabbix    8649  8643  0 Feb21 ?        00:00:00 /usr/sbin/zabbix_server: alerter #4 [sent 0, failed 0 alerts, idle 656.699989 sec during 657.124047 sec]
zabbix    8650  8643  0 Feb21 ?        00:00:00 /usr/sbin/zabbix_server: alerter #5 [sent 0, failed 0 alerts, idle 656.677134 sec during 657.137743 sec]
zabbix    8651  8643  0 Feb21 ?        00:00:00 /usr/sbin/zabbix_server: alerter #6 [sent 0, failed 0 alerts, idle 658.772114 sec during 659.591568 sec]
zabbix    8746  8643  0 Feb21 ?        00:01:29 /usr/sbin/zabbix_server: alert syncer [queued 0 alerts(s), flushed 0 result(s) in 0.001063 sec, idle 1 sec]

優化建議

以4C8G配置、能夠處理監控項5萬個為例,相關程式優化項如下(僅供參考):

配置 預設值 推薦值
StartDBSyncers 4 8,不宜太高,預設值已能處理4000 NVPS
StartAlerters 3 6
StartDiscoverers 1 3
StartPollers 5 12
StartPreprocessors 3 6
StartProxyPollers 1 3
StartTrappers 5 12
StartLLDProcessors 2 3
StartEscalators 1 1

相關文章