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

創(chuàng)新互聯(lián)長期為上千多家客戶提供的網(wǎng)站建設(shè)服務，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為橋西企業(yè)提供專業(yè)的成都網(wǎng)站建設(shè)、網(wǎng)站制作，橋西網(wǎng)站改版等技術(shù)服務。擁有10年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

一、引言

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

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

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

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

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

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

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

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

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

五、進一步的方案

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

新聞名稱：一種zabbixserver擴容改造方案
標題來源：http://aaarwkj.com/article12/pcdegc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計、網(wǎng)站導航、定制網(wǎng)站、手機網(wǎng)站建設(shè)、用戶體驗

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)