Z投稿|12000nvps下Zabbix性能維護—某支付平臺經(jīng)驗分享

前言：公司（某銀行旗下第三方支付平臺）最近在做運維大數(shù)據(jù)項目，需要將各個監(jiān)控系統(tǒng)的實時采集數(shù)據(jù)匯總到大數(shù)據(jù)平臺進行智能告警和根因定位，Zabbix作為整個公司數(shù)據(jù)量最大的監(jiān)控系統(tǒng)，超過12000的nvps，每周約產(chǎn)生400G左右的監(jiān)控數(shù)據(jù)，如何將Zabbix的實時監(jiān)控數(shù)據(jù)抽取出來并且不影響到Zabbix的性能？

之前做過一小部分的數(shù)據(jù)通過Zabbix API的方式獲取，大量的數(shù)據(jù)肯定不行的。我們的目標是：在不影響Zabbix性能的前提下，將Zabbix的實時采樣數(shù)據(jù)以標準格式輸出。經(jīng)過一系列的調(diào)研和測試，最終采用如下方案。（由于公司安全限制，部分代碼無法分享，還請見諒。）

1. 技術(shù)架構(gòu)：

在此技術(shù)架構(gòu)中，開源軟件Maxwell可以讀取mysql的binlog文件存放于kafka，讀取原理類似于mysql的存庫方式，這樣對數(shù)據(jù)庫的性能消耗較低；采用python腳本將Zabbix的配置信息讀取之后存放于Redis中，供后續(xù)Spark進行數(shù)據(jù)處理和組合；Spark算子會將kafka中的數(shù)據(jù)進行處理再和Redis的數(shù)據(jù)進行合并，最終獲取到要求的標準數(shù)據(jù)；influxdb作為時序數(shù)據(jù)庫大量存儲標準化之后的數(shù)據(jù)；再將標準數(shù)據(jù)存放于另外一個kafka topic供運維大數(shù)據(jù)消費和計算。

2.?Maxwell

Maxwell是一個能實時讀取MySQL二進制日志binlog，并生成 JSON 格式的消息，作為生產(chǎn)者發(fā)送給 Kafka，Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平臺的應(yīng)用程序。相同功能的還有阿里巴巴開源的canal和Yelp開源的mysql_streamer，在使用過程中主要測試了canal和Maxwell，最終選定了Maxwell，對比如下：

Maxwell沒有canal那種server+client模式，只有一個server把數(shù)據(jù)發(fā)送到消息隊列或redis。如果需要多個實例，通過指定不同配置文件啟動多個進程。

Maxwell有一個亮點功能，就是canal只能抓取最新數(shù)據(jù)，對已存在的歷史數(shù)據(jù)沒有辦法處理。而Maxwell有一個bootstrap功能，可以直接引導出完整的歷史數(shù)據(jù)用于初始化，非常好用。

Maxwell不能直接支持HA，但是它支持斷點還原，即錯誤解決后重啟繼續(xù)上次點兒讀取數(shù)據(jù)。

Maxwell只支持Json格式，而Canal如果用Server+client模式的話，可以自定義格式。

Maxwell比Canal更加輕量級。

在部署過程中，通過修改Maxwell的配置，可以只同步history_uint、history_str、history_txt、history等四張表的數(shù)據(jù)。

原binlog里面的數(shù)據(jù)樣式為：

insert into history_uint (itemid,clock,ns,value) values(40319,1614680424,22205258,1)

通過Maxwell同步到kafka里的json數(shù)據(jù)為：

{"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拿到的數(shù)據(jù)只有{"itemid":40319,"clock":1614680424,"ns":22205258,"value":1}，這個數(shù)據(jù)距離標準輸出數(shù)據(jù)還缺少主機名、主機IP、監(jiān)控項名稱、Key等內(nèi)容，這些內(nèi)容無論通過itemid使用API查詢還是直接查詢數(shù)據(jù)庫，所帶來的QPS都非常高，會極大的影響數(shù)據(jù)庫的性能，所以在這里使用Redis，通過如下SQL將監(jiān)控項的全量數(shù)據(jù)查詢出來，再進行數(shù)據(jù)處理，同步到Redis中，供給Spark進行查詢。

SELECT

i.itemid,

i.NAME,

i.key_,

h.host,

it.ip

FROM

items i,

hosts h,

interface it

WHERE

i.hostid = h.hostid

AND h.hostid = it.hostid

在Redis數(shù)據(jù)存儲中，以Itemid為Key，主機名稱、主機IP、監(jiān)控項名稱、監(jiān)控項key為value，在存儲的時候依舊存儲為jason的字符串格式，方便Spark進行數(shù)據(jù)計算。

redis 127.0.0.1:6379> SET itemid_40319 {"name":"ICMP ping","Key_":"icmpping","HOST":"zabbix server","IP":"127.0.0.l"}

OK

redis 127.0.0.1:6379> GET itemid_40319

{"name":"ICMP ping","Key_":"icmpping","HOST":"zabbix server","IP":"127.0.0.l"}

4. Spark

Spark承載的是原始數(shù)據(jù)的抽取和計算。將原始kafka中存放的數(shù)據(jù)提取為

{"itemid":40319,"clock":1614680424,"ns":22205258,"value":1}這樣的有效數(shù)據(jù)，再通過Itemid去Redis拿到相應(yīng)的配置信息進行整合，最終生成的數(shù)據(jù)格式為：

{"HOST":"zabbix server","IP":"127.0.0.l"，"name":"ICMP ping","Key_":"icmpping"，"itemid":40319,"clock":1614680424,"ns":22205258,"value":1}

在實際操作過程中，Spark的算子程序采用了Python編寫，此處的算子程序為整個架構(gòu)最困難的地方，程序的執(zhí)行效率，并發(fā)數(shù)量等等都會影響數(shù)據(jù)的計算效率，經(jīng)過多次調(diào)試和大數(shù)據(jù)專家的專業(yè)分析，最終能夠達到產(chǎn)線12000nvps的數(shù)據(jù)實時計算。整個規(guī)程還是極為不容易的。

5. 數(shù)據(jù)儲存

Spark計算完成后的數(shù)據(jù)就是我們想要的標準數(shù)據(jù)了，一式兩份，一份再反寫到kafka的另一個topic，用以給到運維大數(shù)據(jù)做集中的數(shù)據(jù)分析；另外一份通過API寫入到influxdb，做長時間的存儲(生產(chǎn)zabbix采用的是18T的SSD盤數(shù)據(jù)庫，數(shù)據(jù)存儲時間不到12個月)，解決了之前的數(shù)據(jù)存儲問題，也方便后續(xù)的數(shù)據(jù)讀取。

6. 總結(jié)

在整個部署過程中，所采用的的Spark、Redis、Kafka公司均有公共基礎(chǔ)組件和相應(yīng)的技術(shù)支持，實施難度一般，Maxwell和influxdb的部署和研究較為繁瑣，基本都是從頭搞起，最終還是達到了預期的效果：在不影響Zabbix性能的前提下，將zabbix的實時采樣數(shù)據(jù)以標準格式輸出。后續(xù)就是準備開展各個監(jiān)控系統(tǒng)的數(shù)據(jù)聚合模型、智能基線算法、單指標異常檢測、根因定位的相關(guān)工作了。

Zabbix

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。