一種zabbix server擴(kuò)容改造方案

本文原創(chuàng)作者鮑光亞，京東商城基礎(chǔ)平臺(tái)部軟件開(kāi)發(fā)工程師，經(jīng)作者同意發(fā)表于本人博客，如需轉(zhuǎn)載需經(jīng)本人同意。

一、引言

隨著監(jiān)控量的迅速增長(zhǎng)，zabbix管理員有一天會(huì)發(fā)現(xiàn)硬盤(pán)iops達(dá)到了數(shù)萬(wàn)，接近硬盤(pán)io的極限，無(wú)力支持處理更多監(jiān)控?cái)?shù)據(jù)。本文提出一種橫向擴(kuò)展方案，以盡量小的改動(dòng)，增加zabbix系統(tǒng)的數(shù)據(jù)io能力。
考慮到zabbix的數(shù)據(jù)庫(kù)io主要在于history表和trends表，這一方案是在不增加zabbix server數(shù)量的情況下，將history表和trends表的io分散到其他主機(jī)上。此方案的優(yōu)點(diǎn)是保持單個(gè)zabbix server，不需要考慮多server之間的協(xié)同一致。這一數(shù)據(jù)庫(kù)分離模式還可以兼容原有的集中模式。但是，由于io分散到多個(gè)主機(jī)上，當(dāng)需要讀寫(xiě)數(shù)據(jù)時(shí)，不得不訪(fǎng)問(wèn)多個(gè)數(shù)據(jù)庫(kù)實(shí)例。同時(shí)，代碼中涉及數(shù)據(jù)庫(kù)讀寫(xiě)的部分，包括zabbix server和web api，都需要重寫(xiě)，好在大部分可以參考已有的代碼。
本方案設(shè)計(jì)基于zabbix 3.0.10版本。本文只論及對(duì)zabbix server的改造方案，對(duì)web api的修改方案將另文討論，本文不涉及。

二、zabbix數(shù)據(jù)讀寫(xiě)機(jī)制

由于configuration數(shù)據(jù)的io遠(yuǎn)小于history和trends數(shù)據(jù)io，本方案沒(méi)有涉及對(duì)configuration數(shù)據(jù)的改動(dòng)。
cache和vc_cache是zabbix源碼中的兩個(gè)變量名稱(chēng)，前者用于存儲(chǔ)來(lái)自agent/proxy的原始數(shù)據(jù)，后者存儲(chǔ)的則是從數(shù)據(jù)庫(kù)中加載的數(shù)據(jù)(當(dāng)數(shù)據(jù)已過(guò)期時(shí)，新數(shù)據(jù)則會(huì)直接從前者復(fù)制到后者之中)，用于進(jìn)行trigger計(jì)算等。
1．history和trends數(shù)據(jù)的寫(xiě)入
poller和trapper兩類(lèi)進(jìn)程(包括pinger)負(fù)責(zé)從agent和proxy接收history數(shù)據(jù)，然后flush到cache中，同時(shí)更新cache中的trends數(shù)據(jù)。對(duì)cache的更新主要通過(guò)函數(shù) process_hist_data實(shí)現(xiàn)。
dbsyncer進(jìn)程則負(fù)責(zé)將cache中的數(shù)據(jù)寫(xiě)入到數(shù)據(jù)庫(kù)中的history表和trends表中。由于dbsyncer存在多個(gè)進(jìn)程，進(jìn)程之間通過(guò)鎖進(jìn)行協(xié)調(diào)，避免沖突。cache數(shù)據(jù)入庫(kù)主要通過(guò)DCsync_history和DCsync_trends兩個(gè)函數(shù)實(shí)現(xiàn)。

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

三、具體方案及實(shí)現(xiàn)

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

1. 改寫(xiě)配置文件
   在配置文件中增加所需的數(shù)據(jù)庫(kù)連接參數(shù)，以及用于集中和分離模式切換的開(kāi)關(guān)。配置文件的解析在程序啟動(dòng)時(shí)進(jìn)行，因此還需要修改啟動(dòng)程序，增加存儲(chǔ)數(shù)據(jù)庫(kù)連接參數(shù)的數(shù)組元素以及開(kāi)關(guān)變量。
2. 修改數(shù)據(jù)庫(kù)connect函數(shù)
   在保留原有connect函數(shù)的基礎(chǔ)上，新增一個(gè)帶有入?yún)⒌腸onnect，以根據(jù)需要建立不同的連接。同時(shí)增加全局變量，用于保持多個(gè)連接。
3. 修改數(shù)據(jù)庫(kù)查詢(xún)函數(shù)
   在保持原有查詢(xún)函數(shù)的基礎(chǔ)上，增加帶有連接參數(shù)的查詢(xún)函數(shù)，以動(dòng)態(tài)變換查詢(xún)連接。zabbix中有多個(gè)查詢(xún)函數(shù)，用于不同類(lèi)型的查詢(xún)，所有這些都需要修改。
4. 對(duì)函數(shù)的調(diào)用
   上文提及的涉及history和trends讀寫(xiě)的函數(shù)中，對(duì)數(shù)據(jù)庫(kù)的訪(fǎng)問(wèn)部分都需要修改，增加對(duì)模式開(kāi)關(guān)的條件判斷，以調(diào)用不同的函數(shù)。模式開(kāi)關(guān)的邏輯應(yīng)保證通過(guò)重啟服務(wù)可以使數(shù)據(jù)存儲(chǔ)模式在集中和分離模式之間切換。
   如果采用按監(jiān)控?cái)?shù)據(jù)類(lèi)型分庫(kù)的方案，則還需要對(duì)sql文本構(gòu)造過(guò)程進(jìn)行修改。
5. 修改watchdog邏輯
   將原來(lái)的單個(gè)實(shí)例狀態(tài)監(jiān)視，改為多實(shí)例同時(shí)監(jiān)視，有任何實(shí)例連接失敗時(shí)均報(bào)警。

四、數(shù)據(jù)一致性問(wèn)題

分離模式存在的風(fēng)險(xiǎn)之一是數(shù)據(jù)一致性問(wèn)題。在集中模式時(shí)，zabbix通過(guò)互斥鎖來(lái)協(xié)調(diào)對(duì)緩存的訪(fǎng)問(wèn)，保證緩存數(shù)據(jù)的一致性。寫(xiě)數(shù)據(jù)庫(kù)時(shí)則通過(guò)transaction保證一致性。因?yàn)榫彺骀i機(jī)制的存在，數(shù)據(jù)庫(kù)的分離與否并不會(huì)影響緩存的一致性，問(wèn)題只能存在于數(shù)據(jù)庫(kù)內(nèi)部。
如果采用按類(lèi)別分離的方案，即history和trends數(shù)據(jù)分別存儲(chǔ)在兩個(gè)數(shù)據(jù)庫(kù)中，則需要考慮history、trends和其他表之間的一致性。如果采用按類(lèi)別+數(shù)據(jù)類(lèi)型分離的方案，則同時(shí)要考慮history各個(gè)表之間的數(shù)據(jù)一致性以及trends表之間的一致性。
通過(guò)分析源碼中的transaction邏輯，history/trends表的更新操作不需要與其他表保持一致性(在數(shù)據(jù)庫(kù)級(jí)別)，在程序允許的情況下，雙方可以獨(dú)立寫(xiě)數(shù)據(jù)庫(kù)。

五、進(jìn)一步的方案

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