案例 | 華為對Zabbix的3個(gè)探索:水平擴(kuò)展、數(shù)據(jù)實(shí)時(shí)消費(fèi)及網(wǎng)絡(luò)體驗(yàn)監(jiān)控

“和大家分享華為對Zabbix的三個(gè)探索實(shí)踐，為了解決集群管理、Agent遷移、高可用管理問題，設(shè)計(jì)了水平擴(kuò)展方案。為了實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)實(shí)時(shí)呈現(xiàn)，設(shè)計(jì)了數(shù)據(jù)實(shí)時(shí)消費(fèi)方案，還有為了構(gòu)建萬物互聯(lián)的智能世界，設(shè)計(jì)了網(wǎng)絡(luò)的體驗(yàn)監(jiān)控方案。

——肖駿,?華為技術(shù)有限公司，SRE

本文整理自肖駿在2020Zabbix中國峰會(huì)的演講，ppt可在網(wǎng)盤獲取:https://pan.baidu.com/s/1KL58mpRWcYl4UmBtJbvFDg ?密碼:ew3p。更多演講視頻可關(guān)注官方Bilibili賬號主頁（ID：Zabbix中國）。

一 Zabbix在華為的實(shí)踐歷程

首先介紹華為IT生產(chǎn)環(huán)境，華為IT是內(nèi)部支撐的IT，人數(shù)龐大，它對應(yīng)的IT系統(tǒng)也很龐大，主要包括辦公系統(tǒng)、HR系統(tǒng)、財(cái)經(jīng)系統(tǒng)，還有運(yùn)營商系統(tǒng)等等。

我現(xiàn)在負(fù)責(zé)華為的全鏈路壓測服務(wù)，今天分享的內(nèi)容包括：Zabbix建設(shè)歷程，業(yè)務(wù)體量，架構(gòu)設(shè)計(jì)，后面我會(huì)分享我們做的三個(gè)探索實(shí)踐。主要是水平擴(kuò)展，數(shù)據(jù)實(shí)時(shí)消費(fèi)，還有網(wǎng)絡(luò)的體驗(yàn)監(jiān)控。

首先看一下華為的一個(gè)Zabbix的實(shí)踐歷程，在2015年，華為商城引入了Zabbix，當(dāng)時(shí)使用的Zabbix2.2版本，主要是監(jiān)控VMall公有云的主機(jī)，中間件數(shù)據(jù)庫等，在2016年看到在VMall試點(diǎn)很成功之后，在內(nèi)網(wǎng)也引入了Zabbix，引入的是3.0版本，覆蓋的是主機(jī)中間件數(shù)據(jù)庫監(jiān)控，在2016年試點(diǎn)完之后，在2017年在內(nèi)網(wǎng)全部鋪開了，將ZabbixAgent作為主機(jī)監(jiān)控的標(biāo)準(zhǔn)Agent，存量機(jī)器也全部覆蓋了。

在全部覆蓋之后，在2017年和2018年替換掉原來的Patrol監(jiān)控，Patrol監(jiān)控是一個(gè)比較老的軟件，它面臨一些問題，它的監(jiān)控配置是需要人工手工去上面配的，每新加一個(gè)監(jiān)控項(xiàng)，或者說修改一個(gè)監(jiān)控項(xiàng)。都得上Patrol的界面，去每一個(gè)Agent的上面配一下，太影響效率了，而且它的監(jiān)控?cái)?shù)據(jù)不能實(shí)時(shí)消費(fèi)，也是比較影響監(jiān)控效率的，用Zabbix把Patrol替換掉之后，可以實(shí)現(xiàn)監(jiān)控策略的自動(dòng)下發(fā)，監(jiān)控?cái)?shù)據(jù)是可以實(shí)時(shí)消費(fèi)的，就極大地提升了監(jiān)控效率。

在2017~2018的時(shí)候，嘗試了做一些網(wǎng)絡(luò)體驗(yàn)監(jiān)控，在華為的市場大會(huì)都有做的網(wǎng)絡(luò)設(shè)備的監(jiān)控，在那種運(yùn)營大屏上展示，當(dāng)大規(guī)模展開之后，單靠Zabbix是滿足不了需求的，就得搭很多套的Zabbix，就會(huì)有一個(gè)Zabbix集群。在2018年做了一個(gè)探索，做了一個(gè)高可用建設(shè)，實(shí)現(xiàn)了多套Zabbix的集中管理,就是說Agent可以在集群間自由遷移。

二 業(yè)務(wù)體量

接下來看一下我們的業(yè)務(wù)體量，我們的業(yè)務(wù)范圍主要分為三大塊，第一塊主要是主機(jī)/中間件監(jiān)控，第二塊主要是端口撥測監(jiān)控，第三塊是網(wǎng)絡(luò)監(jiān)控。其中主機(jī)/中間件監(jiān)控主要使用的是Zabbix Agent功能，端口波次監(jiān)控和網(wǎng)絡(luò)監(jiān)控使用的是Zabbix proxy ping監(jiān)控能力。

大家可以看一下我們的數(shù)量級，主要的監(jiān)控?cái)?shù)量級都是10萬級以上的，這種規(guī)模還比較大，監(jiān)控頻率主要都是按需，有的是分鐘級，有的是一分鐘級，那種要求最高的是網(wǎng)絡(luò)體驗(yàn)監(jiān)控，是一秒級。我在后面會(huì)講到。

三? 架構(gòu)設(shè)計(jì)

接下來講一下我們監(jiān)控的整體架構(gòu)，監(jiān)控的覆蓋范圍是很廣的，它覆蓋了I層P層S層的監(jiān)控，左邊可以看我們的業(yè)務(wù)范圍是很廣的。為了做這些監(jiān)控，有一個(gè)監(jiān)控策略，統(tǒng)一管理平臺(tái)，類似于對標(biāo)Zabbix 的trigger，但是它肯定不只，就是說Zabbix因?yàn)橛泻芏嗟谋O(jiān)控工具，它其實(shí)就是一個(gè)告警閾值項(xiàng)。在監(jiān)控策略管理平臺(tái)上統(tǒng)一管理，監(jiān)控策略會(huì)下發(fā)到監(jiān)控探針，由所有的探針去做數(shù)據(jù)采集，并且做告警，我們的Zabbix就在監(jiān)控探針這一層。當(dāng)監(jiān)控探針采集完數(shù)據(jù)之后，會(huì)把監(jiān)控?cái)?shù)據(jù)受到一個(gè)監(jiān)控?cái)?shù)據(jù)底座中做一些更高階的處理，包括一些實(shí)時(shí)計(jì)算、聚合分析，把它生成那種更高階的一些運(yùn)營數(shù)據(jù)，供用戶和領(lǐng)導(dǎo)查看。

我們的告警數(shù)據(jù)走的是另外一條路，有一個(gè)統(tǒng)一告警平臺(tái)，會(huì)做一些 告警的處理，包括它會(huì)生成事件，給到指定的責(zé)任人去進(jìn)行處理，會(huì)跟自動(dòng)化平臺(tái)做結(jié)合，做治愈處理。就是監(jiān)控?cái)?shù)據(jù)跟告警數(shù)據(jù)都會(huì)統(tǒng)一匯聚在用戶入口。有一個(gè)IT Monitor門戶網(wǎng)站，用戶可以在這個(gè)門戶網(wǎng)站上進(jìn)行查看，也提供標(biāo)準(zhǔn)的消費(fèi)API,監(jiān)控?cái)?shù)據(jù)跟告警數(shù)據(jù)都是可以通過API實(shí)時(shí)消費(fèi)出去的，就從監(jiān)控?cái)?shù)據(jù)的生產(chǎn)到加工，到消費(fèi)到展示整個(gè)一條鏈路都拉通了。

講完監(jiān)控的整體架構(gòu)之后，講一下Zabbix的整個(gè)架構(gòu)，從下往上看，Zabbix就分為Agent層，Proxy層，Server層，因?yàn)槭侨蚍植际降囊粋€(gè)公司，我們的Agent跟Proxy都是分布于全球的，Server可能主要集中在我們的數(shù)據(jù)中心，東莞的數(shù)據(jù)中心上，為了管理這么多的集群，在上面還有一個(gè)數(shù)據(jù)跟服務(wù)層，這數(shù)據(jù)跟服務(wù)層它主要有一個(gè)就是Zabbix高可用管理，因?yàn)槟氵@么多集群它是要管理的。

還有一個(gè)監(jiān)控策略管理，也就是剛才我說到的監(jiān)控策略統(tǒng)一管理平臺(tái)，還有監(jiān)控?cái)?shù)據(jù)的存儲(chǔ)分析和處理，這種是監(jiān)控?cái)?shù)據(jù)的一個(gè)更高階的分析功能。還有告警信息處理，在數(shù)據(jù)跟服務(wù)層上面還有一個(gè)可視層，給用戶去查看，做一些操作，還有告警的通知和自動(dòng)修復(fù)，類似于這樣一些功能。

四? 水平擴(kuò)展方案

講完架構(gòu)之后，后面就講幾個(gè)我們自己做的一些探索。當(dāng)Zabbix Agent的數(shù)量多了之后，那么就會(huì)面臨問題，就是一套Zabbix Agent是滿足不了我們的情況的。在2017年的時(shí)候做了一下調(diào)研，發(fā)現(xiàn)業(yè)界最佳實(shí)踐一套Zabbix監(jiān)控的主機(jī)數(shù)量大概是2萬左右。昨天在這里會(huì)議交流的時(shí)候，發(fā)現(xiàn)好像有公司能把一套Zabbix的NVPS做到6萬，是比較厲害的，待會(huì)應(yīng)該會(huì)有講師會(huì)講到，也想學(xué)習(xí)一下。

這里我先講一下我們的一個(gè)解決方案。因?yàn)閆abbix的瓶頸是在數(shù)據(jù)庫上，就在MySQL那一層做了一些優(yōu)化，用物理機(jī)加上存儲(chǔ)的方案提升數(shù)據(jù)庫的性能，這樣可以將單套Zabbix的監(jiān)控?cái)?shù)量從2萬提升到4萬，但是4萬這個(gè)量級還是不能滿足需求。

因此就必須要構(gòu)建多套Zabbix，但它會(huì)帶來一個(gè)集群管理的困難，你有單套的時(shí)候你比較好看，你每天上班去一套Zabbix上面點(diǎn)一點(diǎn)，你就知道整個(gè)情況。當(dāng)你數(shù)量很多的時(shí)候，你就沒法說我上班的時(shí)候我這一套點(diǎn)一點(diǎn)，那一套點(diǎn)一點(diǎn)，你就點(diǎn)了很多，希望有一個(gè)統(tǒng)一管理的頁面去看所有Zabbix性能情況。

第二個(gè)問題，當(dāng)你多套Zabbix的時(shí)候，Agent是打到標(biāo)準(zhǔn)鏡像里面去，新增一臺(tái)主機(jī)，Agent會(huì)自動(dòng)連到一套Zabbix。比如說Zabbix01上，業(yè)務(wù)規(guī)模擴(kuò)大很大，Agent真的很多，所有的Agent的都會(huì)往Zabbix01上面擠，這樣Zabbix01是永遠(yuǎn)就面臨它的性能瓶頸問題的。這時(shí)候就需要有一個(gè)水平遷移的功能，將Zabbix01上面的Agent無損地遷移到另外一套Zabbix去，就保持所有的監(jiān)控都不丟。

還有一個(gè)問題，Zabbix它作為生長環(huán)境的主要監(jiān)控工具之后，它的重要性是日益提升的，你每一套Zabbix都不能出問題，因?yàn)槟阋怀鰡栴}，就會(huì)有很多機(jī)器的基礎(chǔ)建構(gòu)是失效的，這種風(fēng)險(xiǎn)是很高的。Zabbix的高可用也提上了日程。

為了解決上面三個(gè)問題，第一個(gè)是集群管理的問題，第二個(gè)是Agent遷移的問題，還有一個(gè)高可用管理的問題，所以設(shè)計(jì)了一套方案。

大家可以看一下示意圖，我們在進(jìn)行遷移的時(shí)候，定義了一下每一個(gè)Host它會(huì)有標(biāo)準(zhǔn)項(xiàng)和非標(biāo)準(zhǔn)項(xiàng)。標(biāo)準(zhǔn)項(xiàng)是那種配置了主機(jī)的自動(dòng)發(fā)現(xiàn)，在自動(dòng)發(fā)現(xiàn)的時(shí)候它會(huì)自動(dòng)關(guān)聯(lián)一些基礎(chǔ)模板，基礎(chǔ)模板主要是比如說CPU、內(nèi)存文件系統(tǒng)類似于這些標(biāo)準(zhǔn)的監(jiān)控，但是每一個(gè)主機(jī)它還有一些非標(biāo)準(zhǔn)的監(jiān)控，因?yàn)閆abbix它這種自定義監(jiān)控是很強(qiáng)大的，你可以在每個(gè)主機(jī)上配置很多那種自定義監(jiān)控，但自定義監(jiān)控你沒法用統(tǒng)一的那種策略管理去管理，你只能把它留在Zabbix上面。但當(dāng)你遷移的時(shí)候，你這種非標(biāo)準(zhǔn)的監(jiān)控項(xiàng)，你是不好遷移的。像示意圖一樣，你遷移的時(shí)候，我去改Agent的配置，把它Agent的Server的指向籌一套，指向另外一條的時(shí)候，那些標(biāo)準(zhǔn)的監(jiān)控項(xiàng)它會(huì)遷移，但是非標(biāo)準(zhǔn)的監(jiān)控項(xiàng)它會(huì)留在原來的地方。這時(shí)候就構(gòu)建了一套配置總庫，配置總庫它將每一套Zabbix所有的那些監(jiān)控配置數(shù)據(jù)都保存在一起，去配置總庫時(shí)，拿出這些非標(biāo)準(zhǔn)的監(jiān)控項(xiàng)也進(jìn)行遷移，這樣我就可以實(shí)現(xiàn)：

第一，Zabbix Agent在集群間自由遷移；

第二，我所有的配置數(shù)據(jù)都在配置總庫里面，雖然說每一套Zabbix是做了高可用的部署，比如說Zabbix server我是有組備的，Zabbix DB我也是有組備的，但是高可用這個(gè)東西，你多考慮一點(diǎn)總是沒錯(cuò)的。所以用了一個(gè)配置總庫去保存所有的配置。當(dāng)你一套可能面臨那種極端情況的下情況下，它所有的東西都丟了的時(shí)候，配置總庫也是可以去拿出它所有的那種配置信息，就實(shí)現(xiàn)了多套的Zabbix集群統(tǒng)一管理，也支持Zabbix的集群的水平擴(kuò)展，當(dāng)你一套掛了的時(shí)候，我可以快速將這一套的這些Agent，遷移到另外一套里面去。

關(guān)于配置總庫我詳細(xì)講一下。配置總庫構(gòu)建大部分是基于Zabbix原生的表結(jié)構(gòu)去構(gòu)建的，取數(shù)據(jù)是通過Circle 去每一套Zabbix上面取比較關(guān)鍵的這種監(jiān)控項(xiàng)，監(jiān)控的那些配置項(xiàng)，把它存到配置總庫里面去。在遷移的時(shí)候，標(biāo)準(zhǔn)項(xiàng)會(huì)對比一下類似于一些trigger的狀態(tài)，因?yàn)闃?biāo)準(zhǔn)模板里面也有一些trigger可能是會(huì)打開或者關(guān)閉。這種會(huì)去更新，標(biāo)準(zhǔn)里面就不去做增刪改。非標(biāo)準(zhǔn)項(xiàng)，通過從配置總庫里面拿出那些關(guān)鍵的監(jiān)控配置數(shù)據(jù)，通過Zabbix API在新的那一套Zabbix面把它給創(chuàng)建起來。

這里有一點(diǎn)也講一下，我們嘗試過，就用Circle去創(chuàng)建那些非標(biāo)準(zhǔn)項(xiàng)，因?yàn)槟阌肅ircle可以大批量創(chuàng)建，這樣效率會(huì)很高，但是梳理了一下，Zabbix創(chuàng)建新的item、trigger、host的操作，每個(gè)操作它的Circle大概都有100多個(gè)，100多個(gè)Circle，它中間有很多校驗(yàn)的過程，這樣的方式它會(huì)相對比較安全，但它很損耗性能。看到那100多個(gè)Circle也無從下手，就沒有通過那種Circle的方式去創(chuàng)建，通過Zabbix API的方式去創(chuàng)建,這里會(huì)導(dǎo)致性能會(huì)有點(diǎn)差.大規(guī)模遷移的時(shí)候會(huì)有點(diǎn)慢，這樣遷移標(biāo)準(zhǔn)項(xiàng)是可以遷移的，至少能保命，非標(biāo)準(zhǔn)項(xiàng)這樣在一段時(shí)間內(nèi)遷移過去，這樣也能接受。

還有一點(diǎn)剛才說的Zabbix API因?yàn)樗芏嗄欠N校驗(yàn)的Circle,導(dǎo)致性能很慢，在其它的場景下面遇到一個(gè)坑，當(dāng)數(shù)量上去之后，使用多線程去調(diào)Zabbix API來創(chuàng)建新的Host、item和trigge，r它因?yàn)橛行阅軉栴}，它可能會(huì)處理不過來。它有一個(gè)ID自增的表，里面會(huì)存一些ID數(shù)據(jù)，它跟實(shí)際的配置的表會(huì)對不上。比如說Agent表有一個(gè)Agent ID，它在自增ID的那張表里面，它會(huì)存一個(gè)10000，但是你多線程去調(diào)的時(shí)候，Agent表里面它的AgentID已經(jīng)到10,001了，你下一次調(diào)的時(shí)候，自增ID的數(shù)據(jù)它會(huì)增一，它會(huì)從10000增到10,001，你Agent表里面10,001已經(jīng)存在了，這個(gè)時(shí)候你就會(huì)操作不下去，它會(huì)報(bào)錯(cuò)。下一次調(diào)Zabbix API的時(shí)候就會(huì)報(bào)錯(cuò)，它永遠(yuǎn)會(huì)卡在那里，你永遠(yuǎn)創(chuàng)建不了新的，你也刪除不了老的。

這里沒有做太多的深入的研究，用了一個(gè)比較土的辦法，我定時(shí)在ID表里面做一個(gè)自偵，寫一個(gè)定時(shí)任務(wù)，做一個(gè)自偵。這樣就可以避免你在創(chuàng)建的時(shí)候?qū)е翴D一樣，你就創(chuàng)建不了新的，這個(gè)就是小小的吐槽一下。通過這樣一套，實(shí)現(xiàn)了Zabbix的水平遷移，還有高可用建設(shè)。

五? 數(shù)據(jù)實(shí)時(shí)消費(fèi)方案

接下來就講一下我們的一個(gè)數(shù)據(jù)實(shí)時(shí)消費(fèi)方案。就當(dāng)你把監(jiān)控布好之后，你的監(jiān)控?cái)?shù)據(jù)消費(fèi)肯定是一個(gè)大頭，包括用戶跟領(lǐng)導(dǎo)都希望監(jiān)控?cái)?shù)據(jù)能夠很實(shí)時(shí)的，最好你采集完你就能在頁面上給我展示出來其它頁面而不是Zabbix的頁面，針對這一個(gè)也搞了一套方案。因?yàn)閆abbix的數(shù)據(jù)本來是存在MySQL里面的，你如果直接對MySQL進(jìn)行大批量的消費(fèi)，它會(huì)影響性能。它的適用性可能沒有那么好，通用性沒那么好。

大家可以看一下這套方案，我們在左邊，有一秒級的監(jiān)控，可以實(shí)時(shí)監(jiān)控，監(jiān)控?cái)?shù)據(jù)采集完通過Zabbix發(fā)送到數(shù)據(jù)庫，數(shù)據(jù)庫它主從復(fù)制它會(huì)產(chǎn)生BinLog，BinLog里面記錄了一些新增的那些歷史數(shù)據(jù)，取出這些歷史數(shù)據(jù)來，在redis緩存了那些配置數(shù)據(jù)，把歷史數(shù)據(jù)跟配置數(shù)據(jù)一起結(jié)合，就生成了那種可供消費(fèi)的數(shù)據(jù)，它發(fā)送到Kafka，發(fā)送到Kafka之后，會(huì)用Flink做一些更高階的處理。

因?yàn)橐蟮氖歉叨葘?shí)時(shí)，F(xiàn)link它是一個(gè)流計(jì)算平臺(tái)，可以將數(shù)據(jù)做更高級的加工，發(fā)送到logstash、elastic search，通過實(shí)時(shí)管道，可以把整個(gè)耗時(shí)控制在5~10秒左右，數(shù)據(jù)送到elasticsearch之后，會(huì)提供API，供用戶去實(shí)施消費(fèi)。我們也會(huì)有頁面，供用戶實(shí)時(shí)消費(fèi)。像用戶可能在這里就只需要做一些很簡單的處理，它就可以在頁面展示出來。這樣整個(gè)數(shù)據(jù)從產(chǎn)生到展示，整條鏈路大概可以控制在10秒左右，這個(gè)時(shí)延是可以接受的，因?yàn)楫?dāng)量級大了之后，你是不可能做到那種特別實(shí)時(shí)的，有10秒左右是可以接受的。

這里分享一下我們的一個(gè)例子。每年在有一些展會(huì)上，會(huì)展示一個(gè)網(wǎng)口，在現(xiàn)場展示一個(gè)網(wǎng)口，上面有一個(gè)對應(yīng)的運(yùn)營頁面，你可以實(shí)時(shí)插拔網(wǎng)口，過一小會(huì)你就能看到運(yùn)營頁面上網(wǎng)口的狀態(tài)的變化，你把它拔出來，稍等一小會(huì)，運(yùn)營頁面上網(wǎng)口它就變紅了，你把它插上，過一小會(huì)它就變綠了。

這是一個(gè)很好的展示效果，也證明了數(shù)據(jù)實(shí)時(shí)消費(fèi)的能力，關(guān)于數(shù)據(jù)實(shí)時(shí)消費(fèi)詳細(xì)講一下。傳統(tǒng)的這種數(shù)據(jù)消費(fèi)方案可能是它采集器采到可消費(fèi)的數(shù)據(jù)，送到Mysql，通過API發(fā)送到Kafka，Zabbix數(shù)據(jù)是采集到原始數(shù)據(jù)，發(fā)送到Mysql，使用了一個(gè)轉(zhuǎn)換器，把它發(fā)送到Kafka，供用戶消費(fèi)。大家可以看一下轉(zhuǎn)換器，轉(zhuǎn)換器Zabbix Agent采集完數(shù)據(jù)之后，它會(huì)通過server發(fā)送到Mysql，主從復(fù)制它會(huì)產(chǎn)生BinLog。

BinLog里面會(huì)有幾張表，對那5張表進(jìn)行監(jiān)聽，只要那張表里面有數(shù)據(jù)更新，就把它采集出來，采集的原始數(shù)據(jù)類似于這種形式。item_ID、value還有時(shí)間戳，但這個(gè)數(shù)據(jù)你是沒法給用戶直接消費(fèi)的，因?yàn)橛脩羰遣焕斫膺@個(gè)東西是什么含義，這時(shí)候從Mysql 的存庫取一些那些配置數(shù)據(jù)，緩沖到redis里面，類似item ID, item key, host name, 通過ETL將這兩個(gè)數(shù)據(jù)通過item_ID整個(gè)結(jié)合起來，這樣它就具備了可消費(fèi)數(shù)據(jù)的那些基本的要素。

它可以有Item ID代表它的意義，host name代表它的對象，value代表它的值，時(shí)間戳代表它的時(shí)間，這樣整個(gè)它是變成可消費(fèi)的數(shù)據(jù)。整套方案它對數(shù)據(jù)庫的消耗是很小的，因?yàn)樽xBinLog，它對數(shù)據(jù)庫基本上影響很小，而且通過Mysql去Mysql的存庫里面讀配置數(shù)據(jù)影響也很小，而且它是高度實(shí)時(shí)的，因?yàn)閷?shí)時(shí)監(jiān)聽BinLog而且用了拉力式緩存，這種都是時(shí)延很小的，這樣就能實(shí)現(xiàn)整個(gè)鏈路的那種低時(shí)延的數(shù)據(jù)消費(fèi)。

六??網(wǎng)絡(luò)體驗(yàn)監(jiān)控方案

我介紹一下做的一個(gè)探索性工作就是網(wǎng)絡(luò)體驗(yàn)監(jiān)控。首先講一下，華為公司有一個(gè)比較偉大的愿景，把數(shù)字世界帶入每個(gè)人每個(gè)家庭每個(gè)組織，構(gòu)建萬物互聯(lián)的智能世界，這是一個(gè)很偉大的愿景。在公司內(nèi)部已經(jīng)實(shí)現(xiàn)了一個(gè)比較基礎(chǔ)的互聯(lián)世界，因?yàn)榇蠹叶际怯秒娮釉O(shè)備進(jìn)行辦公交流，所有的設(shè)備都是聯(lián)網(wǎng)的，這種是一個(gè)比較基礎(chǔ)的互聯(lián)的世界，但因?yàn)楣臼歉叨热蚧墓荆械娜硕挤植加谌颍敲磿?huì)面臨一個(gè)很重要的問題就是網(wǎng)絡(luò)問題。

網(wǎng)絡(luò)問題就是因?yàn)榫W(wǎng)絡(luò)線路會(huì)經(jīng)過很多地方，它可能會(huì)有一些時(shí)延，時(shí)延突變，丟包類似于這些動(dòng)作，它會(huì)影響到用戶的一個(gè)體驗(yàn)。比如說南非的同事在觀看東莞的直播的時(shí)候，可能因?yàn)橐粋€(gè)時(shí)延突變，它直播就卡頓了。比如說南非的同事在跟東莞的同事進(jìn)行會(huì)議，還有進(jìn)行投影類似于這樣，可能因?yàn)橐粋€(gè)丟包導(dǎo)致整個(gè)鏈路就斷了。這個(gè)時(shí)候網(wǎng)絡(luò)管理員感知不到的，因?yàn)榫W(wǎng)絡(luò)監(jiān)控大部分的監(jiān)控頻率不是很高，可能那種秒級的一秒級的那種時(shí)延突變，還有丟包，對于用戶來說影響是很不好的，就是我的體驗(yàn)很差.如果說我心情差的時(shí)候，我看了精彩直播，你給我卡頓一下，我都想拍桌子那些這樣，但是網(wǎng)絡(luò)管理員感受不到。這就是一個(gè)很大的問題。

為了解決這一個(gè)問題，就引入了那種網(wǎng)絡(luò)體驗(yàn)監(jiān)控，網(wǎng)絡(luò)體驗(yàn)監(jiān)控就是對用戶訪問應(yīng)用的網(wǎng)絡(luò)時(shí)延、丟包、時(shí)延突變等指標(biāo)進(jìn)行實(shí)時(shí)監(jiān)控，確保用戶擁有良好的體驗(yàn)。是很高度實(shí)時(shí)的，定義為一秒級，因?yàn)檫@樣才能協(xié)助網(wǎng)絡(luò)管理員去發(fā)現(xiàn)問題，后面才好針對這些指標(biāo)去進(jìn)行改進(jìn)。可以看一下用戶訪問我們應(yīng)用的示意圖，它中間會(huì)經(jīng)過很多的網(wǎng)絡(luò)設(shè)備，比如說用戶終端AP，AC還有數(shù)據(jù)中心，這里可以簡單介紹一下，像用戶終端可能就大家用的電腦手機(jī)，AP就是大家頭頂上的那種無線路由，AC可能是存在于每個(gè)辦公園區(qū)，或者說每個(gè)樓里面的一個(gè)網(wǎng)絡(luò)設(shè)備，數(shù)據(jù)中心大家應(yīng)該都知道，當(dāng)然了這只是一個(gè)比較簡化的示意圖，實(shí)際的網(wǎng)絡(luò)線路比這個(gè)要復(fù)雜。

也可以看到從用戶到應(yīng)用這一側(cè)，整個(gè)數(shù)量級別是在不斷降低的。用戶終端它可能是10萬級或者百萬級的，AP可能是萬級的，AC是千數(shù)量級的，數(shù)據(jù)中心可能是十?dāng)?shù)量級的。因?yàn)槲覀兪亲隽颂剿餍怨ぷ鳎x定了AC到數(shù)據(jù)中心的那一段，我們這棟樓的網(wǎng)絡(luò)到數(shù)據(jù)中心的那一段，因?yàn)橛脩舻紸P到AC到我們這棟樓的這種網(wǎng)絡(luò)還好，就是整個(gè)耗時(shí)還好，AC到數(shù)據(jù)中心是能夠比較接近真實(shí)場景的。

選定了這一段的時(shí)候會(huì)面臨一些問題，如果說所有的數(shù)據(jù)中心，對所有的那種AC點(diǎn)都進(jìn)行監(jiān)控，那種監(jiān)控?cái)?shù)據(jù)量會(huì)很大。這里做了一個(gè)模擬，比如說有1000個(gè)AC，有15個(gè)數(shù)據(jù)中心，有時(shí)延跟丟包兩個(gè)監(jiān)控指標(biāo)，因?yàn)閆abbix只支持時(shí)延跟丟包，時(shí)延突變可能后面我會(huì)講到，這樣每秒監(jiān)控?cái)?shù)據(jù)就有3萬，對應(yīng)Zabbix的NVPS是3萬，這樣它會(huì)很消耗那種監(jiān)控資源，可能你要搭多套來確保它的實(shí)時(shí)性，這個(gè)就很耗資源，它每天產(chǎn)生的監(jiān)控?cái)?shù)據(jù)大概是26億。對比一下生產(chǎn)環(huán)境的監(jiān)控業(yè)務(wù)量，生產(chǎn)環(huán)境監(jiān)控大概數(shù)10萬的監(jiān)控對象，每天的監(jiān)控?cái)?shù)據(jù)是數(shù)10億，這里如果只對1000個(gè)AC就進(jìn)行監(jiān)控，就產(chǎn)生這么多數(shù)據(jù)，它會(huì)帶來太多的問題了。不僅是監(jiān)控資源很高，整個(gè)數(shù)據(jù)管道，設(shè)備消耗也很高，包括數(shù)據(jù)湖所有的那些消耗資源都是恐怖的。

如果簡單的使用這種監(jiān)控方式，肯定是不行的，那么就想到其它辦法，其它辦法就是發(fā)現(xiàn)網(wǎng)絡(luò)是有拓樸的，網(wǎng)絡(luò)的拓樸它跟那種地理拓樸是接近的，而且網(wǎng)絡(luò)訪問它都是就近訪問的。比如說南非辦公園區(qū)的一位同事訪問東莞的應(yīng)用，那么肯定是先訪問南非的AC點(diǎn)，南非的AC點(diǎn)接入到南非的數(shù)據(jù)中心，南非的數(shù)據(jù)中心在接入東莞的數(shù)據(jù)中心，這樣可以把整條鏈路拆分一下，進(jìn)行分段監(jiān)控，再把數(shù)據(jù)加核做一個(gè)處理。

為了構(gòu)建網(wǎng)絡(luò)拓補(bǔ)，使用了一個(gè)低頻監(jiān)控的一個(gè)方式，比如說我有一個(gè)AC點(diǎn)，所有的數(shù)據(jù)中心都會(huì)對它進(jìn)行一個(gè)時(shí)延監(jiān)控，比較低頻的。取它時(shí)延最小的值將AC歸屬到數(shù)據(jù)中心上，這樣就能夠構(gòu)建一個(gè)網(wǎng)絡(luò)拓?fù)洹１热缯fAC點(diǎn)是南非的，那么它到南非的數(shù)據(jù)中心，網(wǎng)絡(luò)時(shí)延肯定是最低的，它到其它的數(shù)據(jù)中心時(shí)延肯定更高，我可以把這個(gè)AC點(diǎn)歸屬到南非的數(shù)據(jù)中心，我們的網(wǎng)絡(luò)拓?fù)溥@樣就能構(gòu)建出來。

只需要每個(gè)數(shù)據(jù)中心對歸屬于它的AC點(diǎn)進(jìn)行實(shí)時(shí)監(jiān)控，每個(gè)數(shù)據(jù)中心之間進(jìn)行實(shí)時(shí)監(jiān)控，這樣我就可以極大的減少監(jiān)控?cái)?shù)據(jù)量。而且如果說我要知道就是一條AC，到比如說東莞的AC到南非數(shù)據(jù)中心的時(shí)延，可以通過兩者求和得到，丟包也可以通過一些計(jì)算得到，這樣就極大的降低了監(jiān)控?cái)?shù)據(jù)量。還是以數(shù)據(jù)為例，比如說有1000個(gè)AC，15個(gè)數(shù)據(jù)中心，監(jiān)控指標(biāo)是2000，每秒的監(jiān)控?cái)?shù)據(jù)從3萬可以降低到2000，每天的監(jiān)控?cái)?shù)據(jù)量可以從26億降低到大概1.7億，這種倍數(shù)是降了很多的，而且實(shí)際AC數(shù)量會(huì)比高，數(shù)據(jù)中心數(shù)量也會(huì)比高，實(shí)際降低的監(jiān)控?cái)?shù)量其實(shí)很多的，這樣可以減少很多的那種資源消耗。

這里還得講一下監(jiān)控指標(biāo)這一塊，因?yàn)閆abbix原生只支持那個(gè)時(shí)延跟丟包，那么時(shí)延突變是引入了那種實(shí)時(shí)計(jì)算的Flink平臺(tái)，做一個(gè)取最近100次的時(shí)延值，求個(gè)平均，跟當(dāng)前值做一個(gè)對比。這樣就可以得到以時(shí)延突變的一個(gè)指標(biāo)。還有丟包，也是做了一個(gè)簡單的處理的。取最近100次的丟包，通過Flink就做一個(gè)平均值計(jì)算，這樣你就可以看到一條比較光滑的丟包曲線，這樣就是用戶體驗(yàn)比較好。

七 經(jīng)驗(yàn)分享

講完這些方案之后最后講一些小提示，在做的過程的要點(diǎn)：

就是數(shù)據(jù)庫一定要分區(qū)，可能大家應(yīng)該都是常識(shí)了。

“和大家分享華為對Zabbix的三個(gè)探索實(shí)踐，為了解決集群管理、Agent遷移、高可用管理問題，設(shè)計(jì)了水平擴(kuò)展方案。為了實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)實(shí)時(shí)呈現(xiàn)，設(shè)計(jì)了數(shù)據(jù)實(shí)時(shí)消費(fèi)方案，還有為了構(gòu)建萬物互聯(lián)的智能世界，設(shè)計(jì)了網(wǎng)絡(luò)的體驗(yàn)監(jiān)控方案。

——肖駿,?華為技術(shù)有限公司，SRE

本文整理自肖駿在2020Zabbix中國峰會(huì)的演講，ppt可在網(wǎng)盤獲取:https://pan.baidu.com/s/1KL58mpRWcYl4UmBtJbvFDg ?密碼:ew3p。更多演講視頻可關(guān)注官方Bilibili賬號主頁（ID：Zabbix中國）。

一 Zabbix在華為的實(shí)踐歷程

首先介紹華為IT生產(chǎn)環(huán)境，華為IT是內(nèi)部支撐的IT，人數(shù)龐大，它對應(yīng)的IT系統(tǒng)也很龐大，主要包括辦公系統(tǒng)、HR系統(tǒng)、財(cái)經(jīng)系統(tǒng)，還有運(yùn)營商系統(tǒng)等等。

我現(xiàn)在負(fù)責(zé)華為的全鏈路壓測服務(wù)，今天分享的內(nèi)容包括：Zabbix建設(shè)歷程，業(yè)務(wù)體量，架構(gòu)設(shè)計(jì)，后面我會(huì)分享我們做的三個(gè)探索實(shí)踐。主要是水平擴(kuò)展，數(shù)據(jù)實(shí)時(shí)消費(fèi)，還有網(wǎng)絡(luò)的體驗(yàn)監(jiān)控。

首先看一下華為的一個(gè)Zabbix的實(shí)踐歷程，在2015年，華為商城引入了Zabbix，當(dāng)時(shí)使用的Zabbix2.2版本，主要是監(jiān)控VMall公有云的主機(jī)，中間件數(shù)據(jù)庫等，在2016年看到在VMall試點(diǎn)很成功之后，在內(nèi)網(wǎng)也引入了Zabbix，引入的是3.0版本，覆蓋的是主機(jī)中間件數(shù)據(jù)庫監(jiān)控，在2016年試點(diǎn)完之后，在2017年在內(nèi)網(wǎng)全部鋪開了，將ZabbixAgent作為主機(jī)監(jiān)控的標(biāo)準(zhǔn)Agent，存量機(jī)器也全部覆蓋了。

在全部覆蓋之后，在2017年和2018年替換掉原來的Patrol監(jiān)控，Patrol監(jiān)控是一個(gè)比較老的軟件，它面臨一些問題，它的監(jiān)控配置是需要人工手工去上面配的，每新加一個(gè)監(jiān)控項(xiàng)，或者說修改一個(gè)監(jiān)控項(xiàng)。都得上Patrol的界面，去每一個(gè)Agent的上面配一下，太影響效率了，而且它的監(jiān)控?cái)?shù)據(jù)不能實(shí)時(shí)消費(fèi)，也是比較影響監(jiān)控效率的，用Zabbix把Patrol替換掉之后，可以實(shí)現(xiàn)監(jiān)控策略的自動(dòng)下發(fā)，監(jiān)控?cái)?shù)據(jù)是可以實(shí)時(shí)消費(fèi)的，就極大地提升了監(jiān)控效率。

在2017~2018的時(shí)候，嘗試了做一些網(wǎng)絡(luò)體驗(yàn)監(jiān)控，在華為的市場大會(huì)都有做的網(wǎng)絡(luò)設(shè)備的監(jiān)控，在那種運(yùn)營大屏上展示，當(dāng)大規(guī)模展開之后，單靠Zabbix是滿足不了需求的，就得搭很多套的Zabbix，就會(huì)有一個(gè)Zabbix集群。在2018年做了一個(gè)探索，做了一個(gè)高可用建設(shè)，實(shí)現(xiàn)了多套Zabbix的集中管理,就是說Agent可以在集群間自由遷移。

二 業(yè)務(wù)體量

接下來看一下我們的業(yè)務(wù)體量，我們的業(yè)務(wù)范圍主要分為三大塊，第一塊主要是主機(jī)/中間件監(jiān)控，第二塊主要是端口撥測監(jiān)控，第三塊是網(wǎng)絡(luò)監(jiān)控。其中主機(jī)/中間件監(jiān)控主要使用的是Zabbix Agent功能，端口波次監(jiān)控和網(wǎng)絡(luò)監(jiān)控使用的是Zabbix proxy ping監(jiān)控能力。

大家可以看一下我們的數(shù)量級，主要的監(jiān)控?cái)?shù)量級都是10萬級以上的，這種規(guī)模還比較大，監(jiān)控頻率主要都是按需，有的是分鐘級，有的是一分鐘級，那種要求最高的是網(wǎng)絡(luò)體驗(yàn)監(jiān)控，是一秒級。我在后面會(huì)講到。

三? 架構(gòu)設(shè)計(jì)

接下來講一下我們監(jiān)控的整體架構(gòu)，監(jiān)控的覆蓋范圍是很廣的，它覆蓋了I層P層S層的監(jiān)控，左邊可以看我們的業(yè)務(wù)范圍是很廣的。為了做這些監(jiān)控，有一個(gè)監(jiān)控策略，統(tǒng)一管理平臺(tái)，類似于對標(biāo)Zabbix 的trigger，但是它肯定不只，就是說Zabbix因?yàn)橛泻芏嗟谋O(jiān)控工具，它其實(shí)就是一個(gè)告警閾值項(xiàng)。在監(jiān)控策略管理平臺(tái)上統(tǒng)一管理，監(jiān)控策略會(huì)下發(fā)到監(jiān)控探針，由所有的探針去做數(shù)據(jù)采集，并且做告警，我們的Zabbix就在監(jiān)控探針這一層。當(dāng)監(jiān)控探針采集完數(shù)據(jù)之后，會(huì)把監(jiān)控?cái)?shù)據(jù)受到一個(gè)監(jiān)控?cái)?shù)據(jù)底座中做一些更高階的處理，包括一些實(shí)時(shí)計(jì)算、聚合分析，把它生成那種更高階的一些運(yùn)營數(shù)據(jù)，供用戶和領(lǐng)導(dǎo)查看。

我們的告警數(shù)據(jù)走的是另外一條路，有一個(gè)統(tǒng)一告警平臺(tái)，會(huì)做一些 告警的處理，包括它會(huì)生成事件，給到指定的責(zé)任人去進(jìn)行處理，會(huì)跟自動(dòng)化平臺(tái)做結(jié)合，做治愈處理。就是監(jiān)控?cái)?shù)據(jù)跟告警數(shù)據(jù)都會(huì)統(tǒng)一匯聚在用戶入口。有一個(gè)IT Monitor門戶網(wǎng)站，用戶可以在這個(gè)門戶網(wǎng)站上進(jìn)行查看，也提供標(biāo)準(zhǔn)的消費(fèi)API,監(jiān)控?cái)?shù)據(jù)跟告警數(shù)據(jù)都是可以通過API實(shí)時(shí)消費(fèi)出去的，就從監(jiān)控?cái)?shù)據(jù)的生產(chǎn)到加工，到消費(fèi)到展示整個(gè)一條鏈路都拉通了。

講完監(jiān)控的整體架構(gòu)之后，講一下Zabbix的整個(gè)架構(gòu)，從下往上看，Zabbix就分為Agent層，Proxy層，Server層，因?yàn)槭侨蚍植际降囊粋€(gè)公司，我們的Agent跟Proxy都是分布于全球的，Server可能主要集中在我們的數(shù)據(jù)中心，東莞的數(shù)據(jù)中心上，為了管理這么多的集群，在上面還有一個(gè)數(shù)據(jù)跟服務(wù)層，這數(shù)據(jù)跟服務(wù)層它主要有一個(gè)就是Zabbix高可用管理，因?yàn)槟氵@么多集群它是要管理的。

還有一個(gè)監(jiān)控策略管理，也就是剛才我說到的監(jiān)控策略統(tǒng)一管理平臺(tái)，還有監(jiān)控?cái)?shù)據(jù)的存儲(chǔ)分析和處理，這種是監(jiān)控?cái)?shù)據(jù)的一個(gè)更高階的分析功能。還有告警信息處理，在數(shù)據(jù)跟服務(wù)層上面還有一個(gè)可視層，給用戶去查看，做一些操作，還有告警的通知和自動(dòng)修復(fù)，類似于這樣一些功能。

四? 水平擴(kuò)展方案

講完架構(gòu)之后，后面就講幾個(gè)我們自己做的一些探索。當(dāng)Zabbix Agent的數(shù)量多了之后，那么就會(huì)面臨問題，就是一套Zabbix Agent是滿足不了我們的情況的。在2017年的時(shí)候做了一下調(diào)研，發(fā)現(xiàn)業(yè)界最佳實(shí)踐一套Zabbix監(jiān)控的主機(jī)數(shù)量大概是2萬左右。昨天在這里會(huì)議交流的時(shí)候，發(fā)現(xiàn)好像有公司能把一套Zabbix的NVPS做到6萬，是比較厲害的，待會(huì)應(yīng)該會(huì)有講師會(huì)講到，也想學(xué)習(xí)一下。

這里我先講一下我們的一個(gè)解決方案。因?yàn)閆abbix的瓶頸是在數(shù)據(jù)庫上，就在MySQL那一層做了一些優(yōu)化，用物理機(jī)加上存儲(chǔ)的方案提升數(shù)據(jù)庫的性能，這樣可以將單套Zabbix的監(jiān)控?cái)?shù)量從2萬提升到4萬，但是4萬這個(gè)量級還是不能滿足需求。

因此就必須要構(gòu)建多套Zabbix，但它會(huì)帶來一個(gè)集群管理的困難，你有單套的時(shí)候你比較好看，你每天上班去一套Zabbix上面點(diǎn)一點(diǎn)，你就知道整個(gè)情況。當(dāng)你數(shù)量很多的時(shí)候，你就沒法說我上班的時(shí)候我這一套點(diǎn)一點(diǎn)，那一套點(diǎn)一點(diǎn)，你就點(diǎn)了很多，希望有一個(gè)統(tǒng)一管理的頁面去看所有Zabbix性能情況。

第二個(gè)問題，當(dāng)你多套Zabbix的時(shí)候，Agent是打到標(biāo)準(zhǔn)鏡像里面去，新增一臺(tái)主機(jī)，Agent會(huì)自動(dòng)連到一套Zabbix。比如說Zabbix01上，業(yè)務(wù)規(guī)模擴(kuò)大很大，Agent真的很多，所有的Agent的都會(huì)往Zabbix01上面擠，這樣Zabbix01是永遠(yuǎn)就面臨它的性能瓶頸問題的。這時(shí)候就需要有一個(gè)水平遷移的功能，將Zabbix01上面的Agent無損地遷移到另外一套Zabbix去，就保持所有的監(jiān)控都不丟。

還有一個(gè)問題，Zabbix它作為生長環(huán)境的主要監(jiān)控工具之后，它的重要性是日益提升的，你每一套Zabbix都不能出問題，因?yàn)槟阋怀鰡栴}，就會(huì)有很多機(jī)器的基礎(chǔ)建構(gòu)是失效的，這種風(fēng)險(xiǎn)是很高的。Zabbix的高可用也提上了日程。

為了解決上面三個(gè)問題，第一個(gè)是集群管理的問題，第二個(gè)是Agent遷移的問題，還有一個(gè)高可用管理的問題，所以設(shè)計(jì)了一套方案。

大家可以看一下示意圖，我們在進(jìn)行遷移的時(shí)候，定義了一下每一個(gè)Host它會(huì)有標(biāo)準(zhǔn)項(xiàng)和非標(biāo)準(zhǔn)項(xiàng)。標(biāo)準(zhǔn)項(xiàng)是那種配置了主機(jī)的自動(dòng)發(fā)現(xiàn)，在自動(dòng)發(fā)現(xiàn)的時(shí)候它會(huì)自動(dòng)關(guān)聯(lián)一些基礎(chǔ)模板，基礎(chǔ)模板主要是比如說CPU、內(nèi)存文件系統(tǒng)類似于這些標(biāo)準(zhǔn)的監(jiān)控，但是每一個(gè)主機(jī)它還有一些非標(biāo)準(zhǔn)的監(jiān)控，因?yàn)閆abbix它這種自定義監(jiān)控是很強(qiáng)大的，你可以在每個(gè)主機(jī)上配置很多那種自定義監(jiān)控，但自定義監(jiān)控你沒法用統(tǒng)一的那種策略管理去管理，你只能把它留在Zabbix上面。但當(dāng)你遷移的時(shí)候，你這種非標(biāo)準(zhǔn)的監(jiān)控項(xiàng)，你是不好遷移的。像示意圖一樣，你遷移的時(shí)候，我去改Agent的配置，把它Agent的Server的指向籌一套，指向另外一條的時(shí)候，那些標(biāo)準(zhǔn)的監(jiān)控項(xiàng)它會(huì)遷移，但是非標(biāo)準(zhǔn)的監(jiān)控項(xiàng)它會(huì)留在原來的地方。這時(shí)候就構(gòu)建了一套配置總庫，配置總庫它將每一套Zabbix所有的那些監(jiān)控配置數(shù)據(jù)都保存在一起，去配置總庫時(shí)，拿出這些非標(biāo)準(zhǔn)的監(jiān)控項(xiàng)也進(jìn)行遷移，這樣我就可以實(shí)現(xiàn)：

第一，Zabbix Agent在集群間自由遷移；

第二，我所有的配置數(shù)據(jù)都在配置總庫里面，雖然說每一套Zabbix是做了高可用的部署，比如說Zabbix server我是有組備的，Zabbix DB我也是有組備的，但是高可用這個(gè)東西，你多考慮一點(diǎn)總是沒錯(cuò)的。所以用了一個(gè)配置總庫去保存所有的配置。當(dāng)你一套可能面臨那種極端情況的下情況下，它所有的東西都丟了的時(shí)候，配置總庫也是可以去拿出它所有的那種配置信息，就實(shí)現(xiàn)了多套的Zabbix集群統(tǒng)一管理，也支持Zabbix的集群的水平擴(kuò)展，當(dāng)你一套掛了的時(shí)候，我可以快速將這一套的這些Agent，遷移到另外一套里面去。

關(guān)于配置總庫我詳細(xì)講一下。配置總庫構(gòu)建大部分是基于Zabbix原生的表結(jié)構(gòu)去構(gòu)建的，取數(shù)據(jù)是通過Circle 去每一套Zabbix上面取比較關(guān)鍵的這種監(jiān)控項(xiàng)，監(jiān)控的那些配置項(xiàng)，把它存到配置總庫里面去。在遷移的時(shí)候，標(biāo)準(zhǔn)項(xiàng)會(huì)對比一下類似于一些trigger的狀態(tài)，因?yàn)闃?biāo)準(zhǔn)模板里面也有一些trigger可能是會(huì)打開或者關(guān)閉。這種會(huì)去更新，標(biāo)準(zhǔn)里面就不去做增刪改。非標(biāo)準(zhǔn)項(xiàng)，通過從配置總庫里面拿出那些關(guān)鍵的監(jiān)控配置數(shù)據(jù)，通過Zabbix API在新的那一套Zabbix面把它給創(chuàng)建起來。

這里有一點(diǎn)也講一下，我們嘗試過，就用Circle去創(chuàng)建那些非標(biāo)準(zhǔn)項(xiàng)，因?yàn)槟阌肅ircle可以大批量創(chuàng)建，這樣效率會(huì)很高，但是梳理了一下，Zabbix創(chuàng)建新的item、trigger、host的操作，每個(gè)操作它的Circle大概都有100多個(gè)，100多個(gè)Circle，它中間有很多校驗(yàn)的過程，這樣的方式它會(huì)相對比較安全，但它很損耗性能。看到那100多個(gè)Circle也無從下手，就沒有通過那種Circle的方式去創(chuàng)建，通過Zabbix API的方式去創(chuàng)建,這里會(huì)導(dǎo)致性能會(huì)有點(diǎn)差.大規(guī)模遷移的時(shí)候會(huì)有點(diǎn)慢，這樣遷移標(biāo)準(zhǔn)項(xiàng)是可以遷移的，至少能保命，非標(biāo)準(zhǔn)項(xiàng)這樣在一段時(shí)間內(nèi)遷移過去，這樣也能接受。

還有一點(diǎn)剛才說的Zabbix API因?yàn)樗芏嗄欠N校驗(yàn)的Circle,導(dǎo)致性能很慢，在其它的場景下面遇到一個(gè)坑，當(dāng)數(shù)量上去之后，使用多線程去調(diào)Zabbix API來創(chuàng)建新的Host、item和trigge，r它因?yàn)橛行阅軉栴}，它可能會(huì)處理不過來。它有一個(gè)ID自增的表，里面會(huì)存一些ID數(shù)據(jù)，它跟實(shí)際的配置的表會(huì)對不上。比如說Agent表有一個(gè)Agent ID，它在自增ID的那張表里面，它會(huì)存一個(gè)10000，但是你多線程去調(diào)的時(shí)候，Agent表里面它的AgentID已經(jīng)到10,001了，你下一次調(diào)的時(shí)候，自增ID的數(shù)據(jù)它會(huì)增一，它會(huì)從10000增到10,001，你Agent表里面10,001已經(jīng)存在了，這個(gè)時(shí)候你就會(huì)操作不下去，它會(huì)報(bào)錯(cuò)。下一次調(diào)Zabbix API的時(shí)候就會(huì)報(bào)錯(cuò)，它永遠(yuǎn)會(huì)卡在那里，你永遠(yuǎn)創(chuàng)建不了新的，你也刪除不了老的。

這里沒有做太多的深入的研究，用了一個(gè)比較土的辦法，我定時(shí)在ID表里面做一個(gè)自偵，寫一個(gè)定時(shí)任務(wù)，做一個(gè)自偵。這樣就可以避免你在創(chuàng)建的時(shí)候?qū)е翴D一樣，你就創(chuàng)建不了新的，這個(gè)就是小小的吐槽一下。通過這樣一套，實(shí)現(xiàn)了Zabbix的水平遷移，還有高可用建設(shè)。

五? 數(shù)據(jù)實(shí)時(shí)消費(fèi)方案

接下來就講一下我們的一個(gè)數(shù)據(jù)實(shí)時(shí)消費(fèi)方案。就當(dāng)你把監(jiān)控布好之后，你的監(jiān)控?cái)?shù)據(jù)消費(fèi)肯定是一個(gè)大頭，包括用戶跟領(lǐng)導(dǎo)都希望監(jiān)控?cái)?shù)據(jù)能夠很實(shí)時(shí)的，最好你采集完你就能在頁面上給我展示出來其它頁面而不是Zabbix的頁面，針對這一個(gè)也搞了一套方案。因?yàn)閆abbix的數(shù)據(jù)本來是存在MySQL里面的，你如果直接對MySQL進(jìn)行大批量的消費(fèi)，它會(huì)影響性能。它的適用性可能沒有那么好，通用性沒那么好。

大家可以看一下這套方案，我們在左邊，有一秒級的監(jiān)控，可以實(shí)時(shí)監(jiān)控，監(jiān)控?cái)?shù)據(jù)采集完通過Zabbix發(fā)送到數(shù)據(jù)庫，數(shù)據(jù)庫它主從復(fù)制它會(huì)產(chǎn)生BinLog，BinLog里面記錄了一些新增的那些歷史數(shù)據(jù)，取出這些歷史數(shù)據(jù)來，在redis緩存了那些配置數(shù)據(jù)，把歷史數(shù)據(jù)跟配置數(shù)據(jù)一起結(jié)合，就生成了那種可供消費(fèi)的數(shù)據(jù)，它發(fā)送到Kafka，發(fā)送到Kafka之后，會(huì)用Flink做一些更高階的處理。

因?yàn)橐蟮氖歉叨葘?shí)時(shí)，F(xiàn)link它是一個(gè)流計(jì)算平臺(tái)，可以將數(shù)據(jù)做更高級的加工，發(fā)送到logstash、elastic search，通過實(shí)時(shí)管道，可以把整個(gè)耗時(shí)控制在5~10秒左右，數(shù)據(jù)送到elasticsearch之后，會(huì)提供API，供用戶去實(shí)施消費(fèi)。我們也會(huì)有頁面，供用戶實(shí)時(shí)消費(fèi)。像用戶可能在這里就只需要做一些很簡單的處理，它就可以在頁面展示出來。這樣整個(gè)數(shù)據(jù)從產(chǎn)生到展示，整條鏈路大概可以控制在10秒左右，這個(gè)時(shí)延是可以接受的，因?yàn)楫?dāng)量級大了之后，你是不可能做到那種特別實(shí)時(shí)的，有10秒左右是可以接受的。

這里分享一下我們的一個(gè)例子。每年在有一些展會(huì)上，會(huì)展示一個(gè)網(wǎng)口，在現(xiàn)場展示一個(gè)網(wǎng)口，上面有一個(gè)對應(yīng)的運(yùn)營頁面，你可以實(shí)時(shí)插拔網(wǎng)口，過一小會(huì)你就能看到運(yùn)營頁面上網(wǎng)口的狀態(tài)的變化，你把它拔出來，稍等一小會(huì)，運(yùn)營頁面上網(wǎng)口它就變紅了，你把它插上，過一小會(huì)它就變綠了。

這是一個(gè)很好的展示效果，也證明了數(shù)據(jù)實(shí)時(shí)消費(fèi)的能力，關(guān)于數(shù)據(jù)實(shí)時(shí)消費(fèi)詳細(xì)講一下。傳統(tǒng)的這種數(shù)據(jù)消費(fèi)方案可能是它采集器采到可消費(fèi)的數(shù)據(jù)，送到Mysql，通過API發(fā)送到Kafka，Zabbix數(shù)據(jù)是采集到原始數(shù)據(jù)，發(fā)送到Mysql，使用了一個(gè)轉(zhuǎn)換器，把它發(fā)送到Kafka，供用戶消費(fèi)。大家可以看一下轉(zhuǎn)換器，轉(zhuǎn)換器Zabbix Agent采集完數(shù)據(jù)之后，它會(huì)通過server發(fā)送到Mysql，主從復(fù)制它會(huì)產(chǎn)生BinLog。

BinLog里面會(huì)有幾張表，對那5張表進(jìn)行監(jiān)聽，只要那張表里面有數(shù)據(jù)更新，就把它采集出來，采集的原始數(shù)據(jù)類似于這種形式。item_ID、value還有時(shí)間戳，但這個(gè)數(shù)據(jù)你是沒法給用戶直接消費(fèi)的，因?yàn)橛脩羰遣焕斫膺@個(gè)東西是什么含義，這時(shí)候從Mysql 的存庫取一些那些配置數(shù)據(jù)，緩沖到redis里面，類似item ID, item key, host name, 通過ETL將這兩個(gè)數(shù)據(jù)通過item_ID整個(gè)結(jié)合起來，這樣它就具備了可消費(fèi)數(shù)據(jù)的那些基本的要素。

它可以有Item ID代表它的意義，host name代表它的對象，value代表它的值，時(shí)間戳代表它的時(shí)間，這樣整個(gè)它是變成可消費(fèi)的數(shù)據(jù)。整套方案它對數(shù)據(jù)庫的消耗是很小的，因?yàn)樽xBinLog，它對數(shù)據(jù)庫基本上影響很小，而且通過Mysql去Mysql的存庫里面讀配置數(shù)據(jù)影響也很小，而且它是高度實(shí)時(shí)的，因?yàn)閷?shí)時(shí)監(jiān)聽BinLog而且用了拉力式緩存，這種都是時(shí)延很小的，這樣就能實(shí)現(xiàn)整個(gè)鏈路的那種低時(shí)延的數(shù)據(jù)消費(fèi)。

六??網(wǎng)絡(luò)體驗(yàn)監(jiān)控方案

我介紹一下做的一個(gè)探索性工作就是網(wǎng)絡(luò)體驗(yàn)監(jiān)控。首先講一下，華為公司有一個(gè)比較偉大的愿景，把數(shù)字世界帶入每個(gè)人每個(gè)家庭每個(gè)組織，構(gòu)建萬物互聯(lián)的智能世界，這是一個(gè)很偉大的愿景。在公司內(nèi)部已經(jīng)實(shí)現(xiàn)了一個(gè)比較基礎(chǔ)的互聯(lián)世界，因?yàn)榇蠹叶际怯秒娮釉O(shè)備進(jìn)行辦公交流，所有的設(shè)備都是聯(lián)網(wǎng)的，這種是一個(gè)比較基礎(chǔ)的互聯(lián)的世界，但因?yàn)楣臼歉叨热蚧墓荆械娜硕挤植加谌颍敲磿?huì)面臨一個(gè)很重要的問題就是網(wǎng)絡(luò)問題。

網(wǎng)絡(luò)問題就是因?yàn)榫W(wǎng)絡(luò)線路會(huì)經(jīng)過很多地方，它可能會(huì)有一些時(shí)延，時(shí)延突變，丟包類似于這些動(dòng)作，它會(huì)影響到用戶的一個(gè)體驗(yàn)。比如說南非的同事在觀看東莞的直播的時(shí)候，可能因?yàn)橐粋€(gè)時(shí)延突變，它直播就卡頓了。比如說南非的同事在跟東莞的同事進(jìn)行會(huì)議，還有進(jìn)行投影類似于這樣，可能因?yàn)橐粋€(gè)丟包導(dǎo)致整個(gè)鏈路就斷了。這個(gè)時(shí)候網(wǎng)絡(luò)管理員感知不到的，因?yàn)榫W(wǎng)絡(luò)監(jiān)控大部分的監(jiān)控頻率不是很高，可能那種秒級的一秒級的那種時(shí)延突變，還有丟包，對于用戶來說影響是很不好的，就是我的體驗(yàn)很差.如果說我心情差的時(shí)候，我看了精彩直播，你給我卡頓一下，我都想拍桌子那些這樣，但是網(wǎng)絡(luò)管理員感受不到。這就是一個(gè)很大的問題。

為了解決這一個(gè)問題，就引入了那種網(wǎng)絡(luò)體驗(yàn)監(jiān)控，網(wǎng)絡(luò)體驗(yàn)監(jiān)控就是對用戶訪問應(yīng)用的網(wǎng)絡(luò)時(shí)延、丟包、時(shí)延突變等指標(biāo)進(jìn)行實(shí)時(shí)監(jiān)控，確保用戶擁有良好的體驗(yàn)。是很高度實(shí)時(shí)的，定義為一秒級，因?yàn)檫@樣才能協(xié)助網(wǎng)絡(luò)管理員去發(fā)現(xiàn)問題，后面才好針對這些指標(biāo)去進(jìn)行改進(jìn)。可以看一下用戶訪問我們應(yīng)用的示意圖，它中間會(huì)經(jīng)過很多的網(wǎng)絡(luò)設(shè)備，比如說用戶終端AP，AC還有數(shù)據(jù)中心，這里可以簡單介紹一下，像用戶終端可能就大家用的電腦手機(jī)，AP就是大家頭頂上的那種無線路由，AC可能是存在于每個(gè)辦公園區(qū)，或者說每個(gè)樓里面的一個(gè)網(wǎng)絡(luò)設(shè)備，數(shù)據(jù)中心大家應(yīng)該都知道，當(dāng)然了這只是一個(gè)比較簡化的示意圖，實(shí)際的網(wǎng)絡(luò)線路比這個(gè)要復(fù)雜。

也可以看到從用戶到應(yīng)用這一側(cè)，整個(gè)數(shù)量級別是在不斷降低的。用戶終端它可能是10萬級或者百萬級的，AP可能是萬級的，AC是千數(shù)量級的，數(shù)據(jù)中心可能是十?dāng)?shù)量級的。因?yàn)槲覀兪亲隽颂剿餍怨ぷ鳎x定了AC到數(shù)據(jù)中心的那一段，我們這棟樓的網(wǎng)絡(luò)到數(shù)據(jù)中心的那一段，因?yàn)橛脩舻紸P到AC到我們這棟樓的這種網(wǎng)絡(luò)還好，就是整個(gè)耗時(shí)還好，AC到數(shù)據(jù)中心是能夠比較接近真實(shí)場景的。

選定了這一段的時(shí)候會(huì)面臨一些問題，如果說所有的數(shù)據(jù)中心，對所有的那種AC點(diǎn)都進(jìn)行監(jiān)控，那種監(jiān)控?cái)?shù)據(jù)量會(huì)很大。這里做了一個(gè)模擬，比如說有1000個(gè)AC，有15個(gè)數(shù)據(jù)中心，有時(shí)延跟丟包兩個(gè)監(jiān)控指標(biāo)，因?yàn)閆abbix只支持時(shí)延跟丟包，時(shí)延突變可能后面我會(huì)講到，這樣每秒監(jiān)控?cái)?shù)據(jù)就有3萬，對應(yīng)Zabbix的NVPS是3萬，這樣它會(huì)很消耗那種監(jiān)控資源，可能你要搭多套來確保它的實(shí)時(shí)性，這個(gè)就很耗資源，它每天產(chǎn)生的監(jiān)控?cái)?shù)據(jù)大概是26億。對比一下生產(chǎn)環(huán)境的監(jiān)控業(yè)務(wù)量，生產(chǎn)環(huán)境監(jiān)控大概數(shù)10萬的監(jiān)控對象，每天的監(jiān)控?cái)?shù)據(jù)是數(shù)10億，這里如果只對1000個(gè)AC就進(jìn)行監(jiān)控，就產(chǎn)生這么多數(shù)據(jù)，它會(huì)帶來太多的問題了。不僅是監(jiān)控資源很高，整個(gè)數(shù)據(jù)管道，設(shè)備消耗也很高，包括數(shù)據(jù)湖所有的那些消耗資源都是恐怖的。

如果簡單的使用這種監(jiān)控方式，肯定是不行的，那么就想到其它辦法，其它辦法就是發(fā)現(xiàn)網(wǎng)絡(luò)是有拓樸的，網(wǎng)絡(luò)的拓樸它跟那種地理拓樸是接近的，而且網(wǎng)絡(luò)訪問它都是就近訪問的。比如說南非辦公園區(qū)的一位同事訪問東莞的應(yīng)用，那么肯定是先訪問南非的AC點(diǎn)，南非的AC點(diǎn)接入到南非的數(shù)據(jù)中心，南非的數(shù)據(jù)中心在接入東莞的數(shù)據(jù)中心，這樣可以把整條鏈路拆分一下，進(jìn)行分段監(jiān)控，再把數(shù)據(jù)加核做一個(gè)處理。

為了構(gòu)建網(wǎng)絡(luò)拓補(bǔ)，使用了一個(gè)低頻監(jiān)控的一個(gè)方式，比如說我有一個(gè)AC點(diǎn)，所有的數(shù)據(jù)中心都會(huì)對它進(jìn)行一個(gè)時(shí)延監(jiān)控，比較低頻的。取它時(shí)延最小的值將AC歸屬到數(shù)據(jù)中心上，這樣就能夠構(gòu)建一個(gè)網(wǎng)絡(luò)拓?fù)洹１热缯fAC點(diǎn)是南非的，那么它到南非的數(shù)據(jù)中心，網(wǎng)絡(luò)時(shí)延肯定是最低的，它到其它的數(shù)據(jù)中心時(shí)延肯定更高，我可以把這個(gè)AC點(diǎn)歸屬到南非的數(shù)據(jù)中心，我們的網(wǎng)絡(luò)拓?fù)溥@樣就能構(gòu)建出來。

只需要每個(gè)數(shù)據(jù)中心對歸屬于它的AC點(diǎn)進(jìn)行實(shí)時(shí)監(jiān)控，每個(gè)數(shù)據(jù)中心之間進(jìn)行實(shí)時(shí)監(jiān)控，這樣我就可以極大的減少監(jiān)控?cái)?shù)據(jù)量。而且如果說我要知道就是一條AC，到比如說東莞的AC到南非數(shù)據(jù)中心的時(shí)延，可以通過兩者求和得到，丟包也可以通過一些計(jì)算得到，這樣就極大的降低了監(jiān)控?cái)?shù)據(jù)量。還是以數(shù)據(jù)為例，比如說有1000個(gè)AC，15個(gè)數(shù)據(jù)中心，監(jiān)控指標(biāo)是2000，每秒的監(jiān)控?cái)?shù)據(jù)從3萬可以降低到2000，每天的監(jiān)控?cái)?shù)據(jù)量可以從26億降低到大概1.7億，這種倍數(shù)是降了很多的，而且實(shí)際AC數(shù)量會(huì)比高，數(shù)據(jù)中心數(shù)量也會(huì)比高，實(shí)際降低的監(jiān)控?cái)?shù)量其實(shí)很多的，這樣可以減少很多的那種資源消耗。

這里還得講一下監(jiān)控指標(biāo)這一塊，因?yàn)閆abbix原生只支持那個(gè)時(shí)延跟丟包，那么時(shí)延突變是引入了那種實(shí)時(shí)計(jì)算的Flink平臺(tái)，做一個(gè)取最近100次的時(shí)延值，求個(gè)平均，跟當(dāng)前值做一個(gè)對比。這樣就可以得到以時(shí)延突變的一個(gè)指標(biāo)。還有丟包，也是做了一個(gè)簡單的處理的。取最近100次的丟包，通過Flink就做一個(gè)平均值計(jì)算，這樣你就可以看到一條比較光滑的丟包曲線，這樣就是用戶體驗(yàn)比較好。

七 經(jīng)驗(yàn)分享

講完這些方案之后最后講一些小提示，在做的過程的要點(diǎn)：

就是數(shù)據(jù)庫一定要分區(qū)，可能大家應(yīng)該都是常識(shí)了。

Proxy可以打入到Docker里面，在Docker里面便于安裝好。這樣在擴(kuò)展的時(shí)候就比較方便。因?yàn)閜roxy很多，之前裝的時(shí)候，每次我都要去編譯安裝一次，這樣太耗時(shí)了，而且可能有一些組件裝的還比較麻煩，我把它打入到Docker里面，這樣就很方便的擴(kuò)展。

面對防火墻的問題，可以將proxy前置，去解決大量防火墻的問題。

可以使用過濾功能去除掉無效的監(jiān)控項(xiàng)，我們購買了Zabbix的高級維保服務(wù)，會(huì)有老師上門服務(wù)。去年周松老師上門服務(wù)，就發(fā)現(xiàn)有一套Zabbix，性能異常的高，NVPS異常的高，就一直在排查，發(fā)現(xiàn)有一個(gè)網(wǎng)絡(luò)自動(dòng)發(fā)現(xiàn)的監(jiān)控，有很多無效的網(wǎng)卡，在一直監(jiān)控采集數(shù)據(jù)，導(dǎo)致NVPS異常的高。在自動(dòng)發(fā)現(xiàn)那里加了一個(gè)過濾的功能之后，過濾了大概100萬的監(jiān)控項(xiàng)，整個(gè)NVPS就降低了，跟其它的一些在別時(shí)性能基本上是一致的。

我今天分享就到這里，謝謝各位。

ppt可在網(wǎng)盤獲取https://pan.baidu.com/s/1KL58mpRWcYl4UmBtJbvFDg 密碼:ew3p

Zabbix 運(yùn)維

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

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