一種zabbix server擴容改造方案

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

1、引言

隨着監控量的迅速增加，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的修改方案將另文討論，本文不涉及。

2、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進程負責監視數據庫狀態，當發現鏈接失敗時發送報警信息。

3、具體方案及實現

在數據庫中，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邏輯
   將原來的單個實例狀態監視，改成多實例同時監視，有任何實例鏈接失敗時均報警。

4、數據一致性問題

分離模式存在的風險之一是數據一致性問題。在集中模式時，zabbix經過互斥鎖來協調對緩存的訪問，保證緩存數據的一致性。寫數據庫時則經過transaction保證一致性。由於緩存鎖機制的存在，數據庫的分離與否並不會影響緩存的一致性，問題只能存在於數據庫內部。
若是採用按類別分離的方案，即history和trends數據分別存儲在兩個數據庫中，則須要考慮history、trends和其餘表之間的一致性。若是採用按類別+數據類型分離的方案，則同時要考慮history各個表之間的數據一致性以及trends表之間的一致性。
經過分析源碼中的transaction邏輯，history/trends表的更新操做不須要與其餘表保持一致性(在數據庫級別)，在程序容許的狀況下，雙方能夠獨立寫數據庫。

5、進一步的方案

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