一種zabbix server擴容改造方案

本文原創作者鮑光亞，京東商城基礎平臺部軟件開發工程師，經作者同意發表于本人博客，如需轉載需經本人同意。

一、引言

隨著監控量的迅速增長，zabbix管理員有一天會發現硬盤iops達到了數萬，接近硬盤io的極限，無力支持處理更多監控數據。本文提出一種橫向擴展方案，以盡量小的改動，增加zabbix系統的數據io能力。
考慮到zabbix的數據庫io主要在于history表和trends表，這一方案是在不增加zabbix server數量的情況下，將history表和trends表的io分散到其他主機上。此方案的優點是保持單個zabbix server，不需要考慮多server之間的協同一致。這一數據庫分離模式還可以兼容原有的集中模式。但是，由于io分散到多個主機上，當需要讀寫數據時，不得不訪問多個數據庫實例。同時，代碼中涉及數據庫讀寫的部分，包括zabbix server和web api，都需要重寫，好在大部分可以參考已有的代碼。
本方案設計基于zabbix 3.0.10版本。本文只論及對zabbix server的改造方案，對web api的修改方案將另文討論，本文不涉及。

二、zabbix數據讀寫機制

由于configuration數據的io遠小于history和trends數據io，本方案沒有涉及對configuration數據的改動。
cache和vc_cache是zabbix源碼中的兩個變量名稱，前者用于存儲來自agent/proxy的原始數據，后者存儲的則是從數據庫中加載的數據(當數據已過期時，新數據則會直接從前者復制到后者之中)，用于進行trigger計算等。
1．history和trends數據的寫入
poller和trapper兩類進程(包括pinger)負責從agent和proxy接收history數據，然后flush到cache中，同時更新cache中的trends數據。對cache的更新主要通過函數 process_hist_data實現。
dbsyncer進程則負責將cache中的數據寫入到數據庫中的history表和trends表中。由于dbsyncer存在多個進程，進程之間通過鎖進行協調，避免沖突。cache數據入庫主要通過DCsync_history和DCsync_trends兩個函數實現。

2. history和trends數據的讀取
   vc_cache在程序啟動時分配空間，但是并不加載數據。此時poller和trapper進程尚未開始接收數據，因此也不會往vc_cache中寫數據。
   程序啟動以后，當需要數據進行計算時，會嘗試從vc_cache中獲取values，如果獲取不到則會從history表中加載數據到vc_cache中。源文件中有三個函數用于從數據庫讀取value并加載到vc_cache中，這三個函數名為vc_db_read_values_by_time、vc_db_read_values_by_count、 vc_db_read_values_by_time_and_count。
3. history和trends數據的刪除
   housekeeper進程負責將過期的數據從history和trends表中刪除。housekeeper還負責刪除過期的events、alerts、sessions等。
4. 數據庫連接
   zabbix各進程對數據庫的訪問通過單個connection來建立連接。各個查詢的執行函數都沒有設置連接參數，而是通過全局性的conn變量維持連接。如果要實現對多數據庫的訪問，則只能增加連接變量數，或者動態修改conn。
5. watchdog
   watchdog進程負責監視數據庫狀態，當發現連接失敗時發送報警信息。

三、具體方案及實現

在數據庫中，history表依照數據類型不同分為history、history_uint、history_str、history_text、history_log五個表，trends表則分為trends和trends_uint兩個表。遵循著分散io的思路，可以考慮兩種方案，第一種方案是按照類別將history和trends分散到兩個獨立的數據庫中，另外一種是按照類別以及數據類型的不同，將每一個表都獨立地存儲到單個數據庫中。下文主要按照第一種方案進行論述。

1. 改寫配置文件
   在配置文件中增加所需的數據庫連接參數，以及用于集中和分離模式切換的開關。配置文件的解析在程序啟動時進行，因此還需要修改啟動程序，增加存儲數據庫連接參數的數組元素以及開關變量。
2. 修改數據庫connect函數
   在保留原有connect函數的基礎上，新增一個帶有入參的connect，以根據需要建立不同的連接。同時增加全局變量，用于保持多個連接。
3. 修改數據庫查詢函數
   在保持原有查詢函數的基礎上，增加帶有連接參數的查詢函數，以動態變換查詢連接。zabbix中有多個查詢函數，用于不同類型的查詢，所有這些都需要修改。
4. 對函數的調用
   上文提及的涉及history和trends讀寫的函數中，對數據庫的訪問部分都需要修改，增加對模式開關的條件判斷，以調用不同的函數。模式開關的邏輯應保證通過重啟服務可以使數據存儲模式在集中和分離模式之間切換。
   如果采用按監控數據類型分庫的方案，則還需要對sql文本構造過程進行修改。
5. 修改watchdog邏輯
   將原來的單個實例狀態監視，改為多實例同時監視，有任何實例連接失敗時均報警。

四、數據一致性問題

分離模式存在的風險之一是數據一致性問題。在集中模式時，zabbix通過互斥鎖來協調對緩存的訪問，保證緩存數據的一致性。寫數據庫時則通過transaction保證一致性。因為緩存鎖機制的存在，數據庫的分離與否并不會影響緩存的一致性，問題只能存在于數據庫內部。
如果采用按類別分離的方案，即history和trends數據分別存儲在兩個數據庫中，則需要考慮history、trends和其他表之間的一致性。如果采用按類別+數據類型分離的方案，則同時要考慮history各個表之間的數據一致性以及trends表之間的一致性。
通過分析源碼中的transaction邏輯，history/trends表的更新操作不需要與其他表保持一致性(在數據庫級別)，在程序允許的情況下，雙方可以獨立寫數據庫。

五、進一步的方案

遵循數據庫分離的思路，更激進的方案是將history和trends數據中的每一個表都進行拆分，以itemid或者clock為key按照一定的哈希算法，將數據分散存儲到更多的數據庫中。