感謝作者郭曉雲投稿！
前言：公司（某銀行旗下第三方支付平臺）最近在做運維大數據項目，需要將各個監控系統的實時採集數據彙總到大數據平臺進行智能告警和根因定位，Zabbix作爲整個公司數據量最大的監控系統，超過12000的nvps，每週約產生400G左右的監控數據，如何將Zabbix的實時監控數據抽取出來並且不影響到Zabbix的性能？
之前做過一小部分的數據通過Zabbix API的方式獲取，大量的數據肯定不行的。我們的目標是：在不影響Zabbix性能的前提下，將Zabbix的實時採樣數據以標準格式輸出。經過一系列的調研和測試，最終採用如下方案。（由於公司安全限制，部分代碼無法分享，還請見諒。）
1. 技術架構：
在此技術架構中，開源軟件Maxwell可以讀取mysql的binlog文件存放於kafka，讀取原理類似於mysql的存庫方式，這樣對數據庫的性能消耗較低；採用python腳本將Zabbix的配置信息讀取之後存放於Redis中，供後續Spark進行數據處理和組合；Spark算子會將kafka中的數據進行處理再和Redis的數據進行合併，最終獲取到要求的標準數據；influxdb作爲時序數據庫大量存儲標準化之後的數據；再將標準數據存放於另外一個kafka topic供運維大數據消費和計算。
2. Maxwell
Maxwell是一個能實時讀取MySQL二進制日誌binlog，並生成 JSON 格式的消息，作爲生產者發送給 Kafka，Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平臺的應用程序。相同功能的還有阿里巴巴開源的canal和Yelp開源的mysql_streamer，在使用過程中主要測試了canal和Maxwell，最終選定了Maxwell，對比如下：
Maxwell沒有canal那種server+client模式，只有一個server把數據發送到消息隊列或redis。如果需要多個實例，通過指定不同配置文件啓動多個進程。
Maxwell有一個亮點功能，就是canal只能抓取最新數據，對已存在的歷史數據沒有辦法處理。而Maxwell有一個bootstrap功能，可以直接引導出完整的歷史數據用於初始化，非常好用。
Maxwell不能直接支持HA，但是它支持斷點還原，即錯誤解決後重啓繼續上次點兒讀取數據。
Maxwell只支持Json格式，而Canal如果用Server+client模式的話，可以自定義格式。
Maxwell比Canal更加輕量級。
在部署過程中，通過修改Maxwell的配置，可以只同步history_uint、history_str、history_txt、history等四張表的數據。
原binlog裏面的數據樣式爲：
insert into history_uint (itemid,clock,ns,value) values(40319,1614680424,22205258,1)通過Maxwell同步到kafka裏的json數據爲：
{"database":"zabbix","table":"history_uint","type":"insert","ts":1614680424,"xid":10595,"commit":true,"data":{"itemid":40319,"clock":1614680424,"ns":22205258,"value":1}}3. Redis
在通過Maxwell拿到的數據只有{"itemid":40319,"clock":1614680424,"ns":22205258,"value":1}，這個數據距離標準輸出數據還缺少主機名、主機IP、監控項名稱、Key等內容，這些內容無論通過itemid使用API查詢還是直接查詢數據庫，所帶來的QPS都非常高，會極大的影響數據庫的性能，所以在這裏使用Redis，通過如下SQL將監控項的全量數據查詢出來，再進行數據處理，同步到Redis中，供給Spark進行查詢。
SELECTi.itemid,i.NAME,i.key_,h.host,it.ipFROMitems i,hosts h,interface itWHEREi.hostid = h.hostidAND h.hostid = it.hostid
在Redis數據存儲中，以Itemid爲Key，主機名稱、主機IP、監控項名稱、監控項key爲value，在存儲的時候依舊存儲爲jason的字符串格式，方便Spark進行數據計算。
redis 127.0.0.1:6379> SET itemid_40319 {"name":"ICMP ping","Key_":"icmpping","HOST":"zabbix server","IP":"127.0.0.l"}OKredis 127.0.0.1:6379> GET itemid_40319{"name":"ICMP ping","Key_":"icmpping","HOST":"zabbix server","IP":"127.0.0.l"}
4. Spark
Spark承載的是原始數據的抽取和計算。將原始kafka中存放的數據提取爲
{"itemid":40319,"clock":1614680424,"ns":22205258,"value":1}這樣的有效數據，再通過Itemid去Redis拿到相應的配置信息進行整合，最終生成的數據格式爲：
{"HOST":"zabbix server","IP":"127.0.0.l"，"name":"ICMP ping","Key_":"icmpping"，"itemid":40319,"clock":1614680424,"ns":22205258,"value":1}在實際操作過程中，Spark的算子程序採用了Python編寫，此處的算子程序爲整個架構最困難的地方，程序的執行效率，併發數量等等都會影響數據的計算效率，經過多次調試和大數據專家的專業分析，最終能夠達到產線12000nvps的數據實時計算。整個規程還是極爲不容易的。
5. 數據儲存
Spark計算完成後的數據就是我們想要的標準數據了，一式兩份，一份再反寫到kafka的另一個topic，用以給到運維大數據做集中的數據分析；另外一份通過API寫入到influxdb，做長時間的存儲(生產zabbix採用的是18T的SSD盤數據庫，數據存儲時間不到12個月)，解決了之前的數據存儲問題，也方便後續的數據讀取。
6. 總結
在整個部署過程中，所採用的的Spark、Redis、Kafka公司均有公共基礎組件和相應的技術支持，實施難度一般，Maxwell和influxdb的部署和研究較爲繁瑣，基本都是從頭搞起，最終還是達到了預期的效果：在不影響Zabbix性能的前提下，將zabbix的實時採樣數據以標準格式輸出。後續就是準備開展各個監控系統的數據聚合模型、智能基線算法、單指標異常檢測、根因定位的相關工作了。
線上專題培訓 ：數據預處理高級功能
3月20日 週六 10:00-18:00 (線上）
課程大綱請見報名鏈接，名額有限，預留席位。
關注Zabbix開源社區
乾貨滿滿
加“小Z“入羣
3000+Zabbixer已加入
本文分享自微信公衆號 - Zabbix開源社區（china_zabbix）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。