專欄|Zabbix server多進程協作式數據流處理過程及負載分析

鮑光亞 | zabbix開源社區簽約專家

2021 zabbix深圳大會演講嘉賓

長期專注監控系統軟件領域，精通Zabbix，具有多年Zabbix監控系統運維和相關開發經驗，持續關注Zabbix的發展，熟悉Zabbix源碼。曾就職于某大型互聯網企業，專門從事Zabbix系統運維和開發工作。

作為一款適用廣泛、功能強大的監控軟件，Zabbix的核心能力在于快速高效地處理持續涌入的大量監控數據。這種能力所面對的挑戰，一方面是監控數據的規模龐大，另一方面是這些數據要求在極短的時間內處理完畢。兩方面的挑戰集中體現在了Zabbix Server端，因為相對于agent和proxy來說，Zabbix Server所需處理的數據流量最大，所要完成的功能也最多、最復雜。那么，Zabbix server如何做到對監控數據的流暢處理？我們又如何使Zabbix server達到最佳性能呢？

本文試圖通過剖析Zabbix server內部的數據處理流程，從數據流的角度為該問題提供一種解釋。本文將從三部分闡述：

1.梳理出數據流在Zabbix server端各種進程之間如何傳遞和加工；

2.考察各進程的工作量以及影響工作量的因素；

3.講述Zabbix內部監控所提供的進程繁忙率是如何計算的，以及進程數量如何影響繁忙率。

（本文所述內容基于Zabbix 5.0版本，其他版本可能有所不同。）

1. 數據流加工和傳遞過程

Zabbix server采用多進程架構，極端情況下可以啟動數千個進程。這些進程進一步劃分為很多類，不同類的進程之間接力傳遞和加工數據，形成上下游關系。每一類進程負責完成特定的數據加工，當某類進程的數據加工流量過大時，可以通過增加該類進程的數量來提高吞吐量。

如果我們將Zabbix server的總體數據處理流程繪制成圖表，將如圖1所示。

圖1. Zabbix server數據加工和傳遞過程

在監控數據的源頭，Zabbix server需要從agent或者proxy獲取數據輸入（主動或者被動方式），這一過程主要由poller或者trapper進程完成。Zabbix可以監控的對象種類很多、很全面，實際上該過程所涉及的進程不只是poller和trapper這兩種，但是所有這些進程的作用歸根結底是實現數據輸入。為了簡化問題，本文使用poller/trapper來代表數據輸入進程。

監控數據通過poller/trapper進程流入Zabbix server。隨后poller/trapper進程會將數據傳遞給預處理進程（preprocessing），并在預處理進程中完成監控數據的初步加工，這些加工遵照用戶配置的規則完成。在Zabbix 5.0中，這些加工可以很復雜，加工的方式也很多。當然，用戶也可以不設置預處理，這種情況下預處理進程相當于什么也不做。

在預處理完成之后，監控數據會分流到不同的進程。其中一部分是LLD（low level discovery）數據，這部分會被傳遞給lld進程加工；剩余的部分則通過共享內存傳遞給history syncer進程加工。LLD進程所做的加工是根據監控數據生成配置信息（監控項、觸發器等），所生成的信息最后寫入共享內存和數據庫。

history syncer進程是所有數據加工中最關鍵的，它一方面負責將監控數據本身寫入到數據庫中，另一方面還負責計算監控數據，并根據計算結果生成事件和問題（problem），以及為事件和問題生成響應計劃。事件、問題以及對事件的響應計劃也寫入到數據庫中。

事情到這里并沒有結束，history syncer進程所生成的響應計劃是一系列的操作，這些操作可能會持續較長的時間。escalator進程和alert進程負責跟進（follow up）并完成這一系列的操作，它們會從數據庫讀取所需要的計劃信息，并遵照計劃進行跟進。

除了以上進程外，Zabbix server中還有一些不直接參與監控數據處理但是仍然非常重要的進程，例如用于配置信息同步的configuration syncer進程、用于自身監控的self-monitoring進程。因為它們不直接參與外來監控數據的處理，本文忽略這些進程。

2. 各進程的工作量及其影響因素

現在考慮一個問題，圖1所示各進程的工作量受哪些因素影響？這些工作量之間又具有怎樣的比例關系？圖中各進程所完成的任務既有區別又有聯系。

其區別之處，一方面在于各進程的工作職責不同，另一方面也體現在其所加工的數據成分不同。進程之間的聯系則在于它們構成了上下游的流水線，如果某個節點發生擁堵，那么這種擁堵會向上游傳導，影響整體的吞吐量。

poller/trapper進程的職責是獲取數據輸入，這就要求它能夠接受大量的連接，并從socket及時讀取大量數據，這些數據就是原始的監控數據。該進程的應然工作量取決于監控項的數量和采集頻率，工作量大小可以用nvps值（new values per second）來衡量。網絡傳輸具有波動性，因為監控值通過網絡輸入，所以實際的每秒傳輸數據量并非恒定，而是有一定的起伏變化。如果poller/trapper進程處理數據的速度趕不上數據流入的速度，就會發生擁堵排隊，所造成的結果就是監控數據無法及時處理或者數據丟失。此時我們往往會觀察到zabbix[queue]監控值的升高。由于poller/trapper是整個數據流的源頭，如果下游的進程發生擁堵，最終也會傳導到該進程（在數據庫之后的一些進程例外，因為數據庫相當于一個極大的緩沖池，會截斷向上游的傳導）。

預處理進程的職責是按照用戶設置對原始監控數據進行各種加工，這意味著，該進程的工作量取決于加工的步驟數以及復雜程度。Zabbix 5.0的預處理功能支持25種加工，這些加工既有簡單的數值加減也有復雜的文本處理（正則表達式、JSON Path等），甚至可以自定義處理函數（JavaScript腳本）。預處理進程的工作量取決于每一種加工步驟所處理的數據量。顯然，對一個5000字符長度的字符串執行復雜的正則運算要遠比兩個整數的減法運算工作量大（讀者可以在網上找到正則表達式拒絕服務攻擊——ReDoS的例子）。一般來說，并非所有的監控數據都需要進行預處理。如果某些監控項沒有配置預處理，那么這些監控項的數據就不需要進行這一步的加工。當預處理進程的處理能力不能滿足要求時同樣會發生擁堵，所造成的結果就是流向下游的數據量減少，而上游的進程則無法向下傳遞數據。

lld進程的職責是解析預處理之后的監控數據（JSON串），并按照規則創建或者修改監控項和觸發器等。該進程所加工的數據量取決于lld規則的數量和采集頻率。lld規則所采集到的數據是特定格式的JSON串，其中包含了自動發現的對象信息，lld進程根據這些新發現的對象創建或者修改監控項、觸發器、主機等。顯然，當自動發現的對象數量很多時，就意味著lld進程需要創建或者修改大量的監控項、觸發器等（對于重復發現的對象則不需要創建）。lld進程的下游是數據庫和共享內存，當數據庫出現問題時，lld進程也會受到影響。如果lld進程發生擁堵，那么上游的預處理進程也無法幸免。

history syncer進程既需要進行大量的計算又需要完成大量的IO。計算工作主要是根據監控數據和觸發器表達式進行運算，以決定是否生成事件和問題（problem）。IO工作主要是將所有監控數據以及事件信息寫入數據庫中。顯然，監控值和觸發器的數量共同決定了計算量，而IO的工作量則主要取決于監控值的數量和類型以及事件的多少。當數據量很大時，IO往往首先成為瓶頸，進而導致history syncer的處理能力下降，繼而發生擁堵。但是IO能力受限于數據庫的性能，所以即使增加history syncer進程的數量也無助于提高其處理能力。

數據庫相當于一個巨大的緩沖池，可以隔絕上游和下游的擁堵傳遞。當數據庫下游的進程發生擁堵時，數據庫中的事件數據不能得到及時處理，但是如果寫庫的速度沒有受到影響，那么位于數據庫上游的進程（例如history syncer、lld進程）仍然可以正常工作，繼續向數據庫寫入數據。

在數據庫的下游有escalator和alert進程，雖然邏輯上后者的數據來自前者，但是實際上兩者都是從數據庫中消費數據的。escalator進程主要消費escalations表中的數據并將生產的數據寫入alerts表中，alert進程則消費alerts表中的數據。顯然兩個進程的工作量取決于所消費的表中尚未處理的數據的量。一般來說，當監控數據觸發了大量事件和問題時，就會導致escalations表數據增速上升，進而導致alerts數據增速上升。換句話說，這兩個進程的壓力與被監控對象的整體健康程度有關。在擁堵傳導方面，因為兩者中間有alerts表作為緩沖，下游的擁堵不會傳導至上游。

根據上述內容，Zabbix server的穩定運行要求每種進程都有能力避免發生擁堵，這就要求每種進程應達到足夠的處理能力。一般來說，處理能力的擴展可以通過增加進程數量來實現，但是Zabbix server的進程數量是通過配置文件設置的，修改進程數量就意味著重啟服務。因此，為了盡可能少調整進程數量，在設置進程數時不僅要考慮當前負載還要考慮未來的負載，以及監控頻率、觸發器、預處理、lld規則等的調整。另外，考慮到監控數據流本身會有自然的波動，還需要在負載本身的基礎上再加上一定的冗余（例如留出20%~30%的余量）。而對于各種進程之間的相對負載比例，則因系統而異，不能一概而論。

3. 進程繁忙率的計算與進程數量調整

Zabbix自身監控提供了Zabbix server各個進程的繁忙率，這是衡量各進程負載的重要指標。本節講述Zabbix自身進程繁忙率的計算方法，以幫助運維人員了解繁忙率的準確意義，從而可以基于此對進程數量進行可靠的調整。

分析Zabbix server端各進程的代碼會發現，這些進程采用兩種不同的數據處理模式：主動式脈沖和IO阻塞式脈沖。主動式脈沖是指進程每次處理一小批數據，如此循環往復，只要有待處理的數據就持續循環，當所有待處理數據都處理完畢時調用sleep函數，主動休眠一定時長，從而形成圖2所示的不定長的繁忙脈沖（黃色方塊），每次繁忙脈沖時間長短不固定，受到數據處理速度的影響。history syncer進程就屬于主動式脈沖，其繁忙脈沖時長不固定，但是每次休眠的時長是固定的（每次1秒）。poller進程和escalator進程也屬于主動式脈沖，其繁忙時長不固定，而且休眠時長也不固定（因為他們的任務都是定點的，要求在準確的時間點醒來）。

圖2. 脈沖式數據處理

IO阻塞式脈沖是指進程不會主動休眠，而是被動IO阻塞。這些進程每次循環會首先讀取數據，當沒有數據可消費時被迫阻塞，直到有新數據到來。trapper進程、預處理進程、lld進程和alert進程都屬于IO阻塞式，其中trapper進程阻塞于TCP套接字，另外3種進程則阻塞于Unix域套接字。

Zabbix自身監控的進程繁忙率實際上是將主動休眠或者被動IO阻塞的時間計為空閑，而把所有其他時間都計為繁忙，按照這種口徑統計出繁忙時間的百分比。基于這種計算方法，當增加某種進程的數量時，分配到每個進程的數據量相應減少，從而增加了每個進程進入休眠或者阻塞的幾率，從而降低繁忙率。

4. 總結

總之，Zabbix server采用多進程架構，不同種類的進程分別承擔不同的數據加工職責，所有進程構成了上下游式的流水線，監控數據在各種進程之間傳遞，并最終流出系統或者流入數據庫。由于進程之間的這種上下游關系，下游進程的擁堵很容易傳導至上游，為了避免擁堵，應使每一種進程具有足夠的處理能力，其處理數據的速度應超過數據流入的速度。另一方面，監控數據的成分結構和類型也會影響到各種進程之間的能力配比。當需要調整各進程的能力配比時，Zabbix自身的內部監控所提供的進程繁忙率是一個重要依據，繁忙率采用兩種不同的計算方式，因進程而異。

Zabbix 任務調度

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。