1. 兩者適用于多大規(guī)模的監(jiān)控場景？超過5000以上監(jiān)控節(jié)點時怎么辦？高可用怎么解決？

2. 兩者怎么解決存儲問題？對于監(jiān)控信息是否有歷史存儲和分析，能從歷史信息中挖掘到哪些有價值的信息？

3. 兩者怎么應(yīng)對告警風(fēng)暴和誤報？

4. 在智能監(jiān)控和自動治愈方面是否有可借鑒的實踐？基于什么算法或策略？怎么進行故障預(yù)判和預(yù)處理？

5. 監(jiān)控大屏是怎么設(shè)計的？

6. 自動化運維管理是兩者同時使用還是二選一更合適？

7. 兩者在配合使用時，應(yīng)該怎么分工？怎么落地？

8. 如果已經(jīng)部署了Zabbix，怎么平穩(wěn)過渡到Prometheus？

9. 分布式鏈路的可觀測性和端到端診斷怎么做？

10. 大規(guī)模場景下，兩者的性能和成本哪個比較低？

監(jiān)控，為什么總讓我們頭痛

監(jiān)控一直都是運維工作中不可或缺的部分，一個高效、契合的監(jiān)控系統(tǒng)是服務(wù)賴以健康穩(wěn)定的基石。隨著業(yè)務(wù)規(guī)模的增長、技術(shù)的發(fā)展、行業(yè)的變革，企業(yè)對用戶體驗越來越重視，監(jiān)控的需求發(fā)生著日新月異的變化，相應(yīng)的監(jiān)控工具和解決方案也層出不窮。其中，Zabbix和Prometheus就是兩款非常典型的監(jiān)控工具，應(yīng)用頗為廣泛。

說起來，監(jiān)控在不同的團隊和公司之間，可能會存在各種差異化的需求。如何基于開源產(chǎn)品打造一個符合自己業(yè)務(wù)場景的監(jiān)控體系，并且持續(xù)迭代？這成為了大家無法繞開的課題。

比如說，如何選擇監(jiān)控方案和開源工具？如何為自己的業(yè)務(wù)場景做定制化適配？如何實現(xiàn)端到端的全鏈路監(jiān)控？如何讓業(yè)務(wù)方以更低成本接入到這個系統(tǒng)中？如何做監(jiān)控的自動化？如何做異常告警的路由、分發(fā)、收斂和抑制？如何做統(tǒng)一化的監(jiān)控大屏、Dashboard等等……這些都是我們在構(gòu)建監(jiān)控系統(tǒng)中可能會面臨的問題。

圍繞這些問題，dbaplus社群特別邀請到美圖SRE負責(zé)人-石鵬(東方德勝)作為主持人、招商銀行技術(shù)經(jīng)理-蔡翔華作為Zabbix使用方、甜橙金融基礎(chǔ)技術(shù)架構(gòu)師-劉宇作為Prometheus使用方，針對Zabbix和Prometheus展開實用選型探討。

十問十答，監(jiān)控工具怎么選

蔡翔華：我們和Zabbix官方其實有溝通過，業(yè)內(nèi)他們有一些監(jiān)控到了40萬以上的節(jié)點數(shù)，當(dāng)然這個節(jié)點數(shù)也要根據(jù)你每個節(jié)點上監(jiān)控多少東西。Zabbix其實有一個指標(biāo)叫做NVPS（New Value Per Second），也就是每秒新增的值的指標(biāo)，來判斷你的監(jiān)控規(guī)模是不是合適的。

那么對于5000個節(jié)點以上的場景來說，其實Zabbix還是OK的，你可以通過多布署一些Proxy，去對后臺數(shù)據(jù)庫做一些性能調(diào)優(yōu)等等，以這些方式去提高整個監(jiān)控平臺的可承受、負載的性能。

另外關(guān)于高可用，我們的數(shù)據(jù)庫端是會有Mycat或者HAProxy高可用，但服務(wù)器端本身它其實沒有高可用，那么我們可以依賴于虛擬化平臺，或者是比如像我們有Vmotion等熱遷移這些技術(shù)。另外，在未來的5.x版本或者6版本以上的話，官方已經(jīng)將原生的高可用納入到Zabbix的Roadmap里面了，大家可以期待一下。

石鵬：好的，蔡老師的核心觀點其實就是我們需要關(guān)注核心的指標(biāo)，也就是NVPS，這個值是比較關(guān)鍵的。然后蔡老師之前您在實際的應(yīng)用中，見過這個系統(tǒng)的峰值可以達到多少嗎？是否可以給大家做個參考？

蔡翔華：在我們自己的環(huán)境里面，NVPS峰值達到過6000以上，但我們后面其實也做了一些優(yōu)化，把它調(diào)整到3000左右。主要目的是，因為一開始我們做的時候是希望做到大而全，什么都監(jiān)控，但最后發(fā)現(xiàn)其實大而全不一定有用，因為很多監(jiān)控即使它是問題，你也不會care它。

劉宇：是的，蔡老師已經(jīng)講得比較詳細了，其實以多大的規(guī)模是取決于你的監(jiān)控目標(biāo)，還有就是采集的間隔，比如說5秒采集一次和1分鐘采集一次，這個規(guī)模都是支持著不一樣的目標(biāo)，所以還是要根據(jù)你的需求。

一般來說，我們會配置成30秒或者是一分鐘；如果是對于高頻的，會15秒。因為單個Prometheus性能已經(jīng)比較強了，一般來說，它每秒百萬個指標(biāo)都是沒什么問題的。Prometheus會根據(jù)你的指標(biāo)來計算，就是看你一個監(jiān)控點上有多少個指標(biāo)，這樣來換算。

如果你單個Prometheus的性能達不到它的要求時，也可以去做一些拆分，比如說我們把Prometheus根據(jù)它的功能來做區(qū)分，這個去監(jiān)控node exporter，那個去監(jiān)控Redis，這樣來做區(qū)分。

當(dāng)然，如果你單個的性能還是不夠的話，可以用分區(qū)，即用hash mod去多分幾個Prometheus來做監(jiān)控。

然后關(guān)于高可用這塊，其實社區(qū)Prometheus這部分做得也不是特別好，會用兩個Prometheus來同時監(jiān)控同樣的一個目標(biāo)，這樣來做到一個高可用。當(dāng)然，在容器環(huán)境，你也可以去通過K8S的deployment這種方式，來把高可用維護起來。

蔡翔華：的確，存儲這個問題因為監(jiān)控寫的東西最多就是寫到存儲里面去，Zabbix以前被吐槽最多的就是它不支持時序數(shù)據(jù)庫TSDB。其實在4.2以后，它就已經(jīng)開始支持TSDB了，當(dāng)然可能還沒有Prometheus那么成熟，它主要的數(shù)據(jù)庫還是MySQL為主。

如果就存儲問題的話，一方面你可以去嘗試TSDB的這種方式；另外一方面的話，你可以去通過增加SSD，或者說數(shù)據(jù)庫層面的一些性能提升，去解決它的問題。包括數(shù)據(jù)庫本身可以去分庫分表，去拆分一下，然后對歷史數(shù)據(jù)做一個歸檔……就是通過數(shù)據(jù)庫層面的優(yōu)化，來解決這個問題。

那么對于歷史存儲和分析這些信息，Zabbix提供了兩個維度，一個叫history，一個叫trend，也就是一個歷史數(shù)據(jù)和趨勢數(shù)據(jù)。它具體數(shù)值是可以自己設(shè)定的，它的邏輯是說，如果超過history的保留期限，比如說30天，它自動會把數(shù)據(jù)歸檔成trend的數(shù)據(jù)，trend的數(shù)據(jù)就會只會保留最大值、最小值和平均值這三個指標(biāo)，而并不能像history數(shù)據(jù)可以看到每一秒鐘，甚至說每一個輪巡周期的指標(biāo)。

我們實際場景應(yīng)用的話，主要是用于我們的性能分析，因為我們有很多互聯(lián)網(wǎng)應(yīng)用，會看一下這個業(yè)務(wù)增長對我平臺的要求，會不會CPU比較緊張、內(nèi)存比較緊張等等。另外，我們會根據(jù)這些數(shù)據(jù)做一個分析，為我們后期的擴容、決策提供一些參考性的依據(jù)。比方說我現(xiàn)在看到今年整體的使用率在多少，我們每年的增長量是在20%還是30%，這樣我們后續(xù)做一些決策的時候，是需要多少的資源、多少的預(yù)算，就比較能有參考價值。

劉宇：Prometheus本身存儲如果存在本地的話，大概只能存15天，最多你也只能放到30天這樣子。官方其實也不建議你把所有的監(jiān)控數(shù)據(jù)都存在Prometheus的一個本地的數(shù)據(jù)庫里。所以我在案例分享中也提到了一個遠端存儲的技術(shù)（案例分享內(nèi)容請關(guān)注dbaplus社群后續(xù)文章發(fā)布）。

我們是存在InfluxDB的，也有一些是可以存在比如說ES，通過remote_write的功能去存到ES或者是其它時序數(shù)據(jù)庫中，或者是比如說HBase這種大數(shù)據(jù)的也可以存。

石鵬：好的了解，其實關(guān)于存儲這個問題，我們還是更多應(yīng)該從需求出發(fā)。整體來看有一些比較通用的思路，最典型的就是這兩種：

第一種是數(shù)據(jù)的轉(zhuǎn)儲。比如像Prometheus，我們在本地只存2周或者4周的數(shù)據(jù)，然后更多的話，就把它寫到遠端。

第二種思路是做數(shù)據(jù)采樣。其實在很多監(jiān)控系統(tǒng)里面，是一個比較常規(guī)的思路，就像在Zabbix里的history、trend，開始可能是每30秒一個點，然后數(shù)據(jù)采樣之后，可能是每5分鐘一個點。就用這樣的方式，把這個數(shù)據(jù)量級減小，然后以此來做存儲問題的優(yōu)化。

蔡翔華：首先誤報這個事情，其實在我理解里是不存在的。也就是說，之所以我們會覺得很多有誤報的東西存在，是因為我們對于規(guī)則，比方說我監(jiān)控東西或者是我配置觸發(fā)器，本身是有問題的。

我碰到很多人說，打算監(jiān)控它的CPU使用率，很多人會直接記錄usage，它的使用率，也有很多人會監(jiān)控它的free的這個space。但有時候會由于配置錯誤，導(dǎo)致原本監(jiān)控cpu usage的使用了cpu free的指標(biāo)。所以說，其實很多時候報警之所以會產(chǎn)生誤報，是因為配置本身不是很正確。

Zabbix的工作機制很簡單：我去收集數(shù)據(jù)，去根據(jù)這個處罰規(guī)則去做比較，然后去發(fā)報警。當(dāng)中所有的邏輯其實本身是不會出任何問題，除非說收集數(shù)據(jù)配錯了、觸發(fā)規(guī)則配錯了、報警機制配錯了……這些其實更多是人為的因素在里面。

所以說，更多的是要通過這種檢查來判斷一下你是否有配錯。

另外一個減少誤報的方式是通過模板化。因為我們只要配置一次模板，那我把所有的Linux機型的監(jiān)控模板都統(tǒng)一起來，對于所有監(jiān)控Linux都套用同一個模板，那么就可以在一定程度上降低誤報。關(guān)鍵還是在于人的問題。

關(guān)于告警風(fēng)暴，其實Zabbix里有一個特性叫做依賴項目。就比方說我現(xiàn)在有一臺機器宕機，那么它可能里面的端口都會不通，然后ping也ping不通，CPU可能也拿不到，可能會有一堆的報警。那么我們可以把所有的這種依賴項關(guān)聯(lián)到ping上，一旦ping的機器都死了，上面肯定東西都是宕掉了，這樣子的話，它只會報ping的這一個問題，而不會把這堆機器上所有的東西都給報出來。就好比一個人如果死了，你跟他說這里有問題那里有問題，其實沒有任何意義。它就只會把你最終的Root Cause（根因）給報出來，去防范這種告警風(fēng)暴。

劉宇：是的，誤報我其實跟蔡老師的觀點是很像的，就是告警中其實是存在一個誤報率的，如果你的誤報率很高的話，運維人員就很疲勞了，可能大家都會覺得狼來了，沒有辦法信任你的那種告警，反而你真正發(fā)生故障的告警就會被忽略掉。所以制定告警的規(guī)則就非常重要，需要想辦法把誤報率給它降低。

那這種規(guī)則的制定其實就比較不是那么具體，會比較抽象，可能比如說把必須要人工介入處理的這種，才把它定為告警；然后如果系統(tǒng)可以自己處理掉，就不要把它告出來，或者只是在后面做一個每天發(fā)一次的報告也就行了。這是我對誤報的一個看法。

關(guān)于告警風(fēng)暴，在Prometheus中，對告警風(fēng)暴的處理方式是這樣：可以通過靜默告警解決，或者是可以加入維護組，或者是也可以做一個聚合，也就是把告警給聚集，然后同類的告警合并，這樣來減少告警的條數(shù)，主要是這樣來做的。

當(dāng)然如果你有些機器需要維護，它也是可以支持的，就是可以把一些告警直接靜默掉。當(dāng)然還有就是測試環(huán)境，比如說這種告警，你就可以完全忽略掉，我覺得可以這樣來解決。

石鵬：好的，我總結(jié)一下，關(guān)于誤報這個問題，兩位老師的意見是比較一致的，我也是比較贊同的。誤報其實最根本的原因就是可能你的使用不合理，不管是你的配置還是說你的各種姿勢可能不合理，才會導(dǎo)致誤報。

然后針對告警風(fēng)暴，其實Zabbix和Prometheus也就是alert manager，它們都有提供一些相應(yīng)的功能、特性。在Zabbix這邊的話，可以像蔡老師說的用依賴項，然后也是可以加維護，也可以規(guī)避一些告警；然后Prometheus這邊是alert manager它里面有silent這個靜默規(guī)則，也是可以去做一些規(guī)避告警這種東西。

可能在很多公司，他們除了監(jiān)控平臺本身去做告警風(fēng)暴的抑制，還會有另外一層。比如說我們公司這邊是這樣：

我們有一個告警平臺，所有的告警都會匯集到這個告警平臺里，然后這個告警平臺會去做一層合并、收斂和抑制。這樣的話，就可以不用特別依賴監(jiān)控平臺本身來提供這些特性，而是由一個統(tǒng)一的平臺，在做最后發(fā)送動作的時候，再來做一層cover?？赡茉诹考壌蟮膱鼍跋拢@種是比較推薦的一種思路。

蔡翔華：是的，因為真正的監(jiān)控當(dāng)中，其實還會納入很多比方說ES等其它監(jiān)控平臺，甚至是一些業(yè)務(wù)告警。當(dāng)平臺很多的時候，其實你需要有一層聚合的方式，去把告警做一個聚合收斂，然后通過在聚合平臺里配置一定規(guī)則之后，再去做后續(xù)的一些報警。

石鵬：沒錯，并且你有這個平臺之后，就可以把一些告警的規(guī)則和策略做得更統(tǒng)一，這樣的話，給用戶的界面和體驗也會更好。

蔡翔華：對，所以說其實看公司規(guī)模，因為這一塊會涉及到一些二次開發(fā)，如果公司沒有這個能力，那就可以把Zabbix全套或Prometheus全套都用上；如果后續(xù)有能力去做這種聚合的話，其實Zabbix也好，Prometheus也好，更多的角色定位會變成一個收集器的角色。然后后面的邏輯其實都交給事件管理平臺或聚合平臺去做。

劉宇：沒錯，這里Zabbix其實也可以把它的報警發(fā)送到alert manager里，也可以做一些靜默處理，因為Zabbix本身它的靜默功能確實不是特別多，還是alert manager會做的更好一點。所以兩個工具其實可以結(jié)合起來使用。

蔡翔華：首先我們是有嘗試過智能監(jiān)控，但是包括我看到的很多書籍里面，包括Prometheus的一些書籍里面，也說設(shè)這種固定的預(yù)知是一個很蠢的方法。

根據(jù)我這邊實際的應(yīng)用，其實你要做到智能監(jiān)控，肯定要有一些大數(shù)據(jù)的東西，比方說我有這種規(guī)律：

例如，按照我們的實際操作里有很多互聯(lián)網(wǎng)的應(yīng)用，有些東西它就是會有高并發(fā)高搶購，可能每個月固定的時候，比如每個月10號放一個活動，活動時它的量是平時的10倍甚至100倍；但也可能有時候，業(yè)務(wù)會不停地在不同的時間放，你很難去判斷這個點到底是不是一個故障點。

也就是說，你用戶數(shù)從10變成了1萬，這1萬到底是因為故障了，還是說是因為業(yè)務(wù)的一些邏輯導(dǎo)致的，很難判斷。所以目前來說，我們嘗試以后，還是用了一些比較固定的報警預(yù)知去做。

那么回到這個話題，Zabbix本身它提供了一些預(yù)測的功能，它會預(yù)測現(xiàn)在我的磁盤消耗大約什么時候會消耗到20%以下，或某個閾值以下，它本身是提供了這個功能的。還有一些內(nèi)置函數(shù)可以去做這個計算。但是目前來說，我個人還是建議使用一個比較固定的閾值，可以方便我們有一個明確判斷，否則你早期會有很多的誤報，甚至可能你都會覺得這東西很正常。

預(yù)測的數(shù)據(jù)也是基于現(xiàn)狀的，如果可以對預(yù)測數(shù)據(jù)進行判斷報警，理論上，也可以針對現(xiàn)有的數(shù)據(jù)進行判斷報警。

劉宇：這塊我們實踐的案例倒不是特別多，我主要還是對數(shù)據(jù)庫的監(jiān)控比較熟，所以就說一下我們在數(shù)據(jù)庫的自動治愈上是怎么實現(xiàn)的吧。

比如說告警，它發(fā)送出來的同時，也會發(fā)送給數(shù)據(jù)庫的一個自動化平臺，這個平臺會有一個程序根據(jù)告警內(nèi)容來調(diào)一些自動治愈的程序來處理這種簡單的故障。但這個其實做的也比較有限，就是說我的這種能夠自愈的程序，都是根據(jù)具體場景的，并不是所有的東西都可以做。比如說清理日志、殺讀庫大查詢，以及需要加一些表空間這些場景，類似這種比較固定的會采用自愈來做，其他的嘗試倒不是太多。

石鵬：嗯嗯，這個問題其實比較前沿，并且涉獵的范圍是比較廣的。像自動治愈，其實Zabbix也有一些相關(guān)的功能，它可以去配置action，當(dāng)發(fā)現(xiàn)告警，有問題，我就可以綁定腳本去做一下處理。

但這個東西要做到什么程度，或者說要用什么技術(shù)來打造這個底座，可能都會有些差別。

蔡翔華：是的，因為我覺得Prometheus和Zabbix或者說其他平臺，都支持調(diào)action、調(diào)腳本去做一些重啟，但是我覺得關(guān)鍵問題的點是在于你敢不敢做這個事情。

因為我們知道我們的環(huán)境其實是很復(fù)雜的。比方說，我發(fā)覺數(shù)據(jù)庫宕了，服務(wù)停了，我敢不敢通過這個服務(wù)自己切過去。因為很多時候并不是數(shù)據(jù)庫本身的問題，是網(wǎng)絡(luò)的問題，網(wǎng)絡(luò)抖動了，監(jiān)控數(shù)據(jù)拿不到了。這個是非常依賴于整個整體環(huán)境的，你可能要想到方方面面，這個規(guī)則會非常復(fù)雜。你可能在做服務(wù)自愈的時候，還要去對其他的東西做一個完全的檢查，確保其他東西是沒有問題的。

所以不說服務(wù)自愈，哪怕在我們?nèi)粘５墓收咸幚懋?dāng)中，也很依賴于經(jīng)驗。就是說這個東西是能做的，但是我們不太敢，因為要考慮的要素很多，就不太敢去直接做自愈這一塊。

石鵬：沒錯，本身其實它是一個體系化的工程，不僅僅是跟監(jiān)控相關(guān)。我這邊的一個想法是這樣，關(guān)于自動治愈這塊，我們可能還是要更多去依靠業(yè)務(wù)側(cè)的能力。就是說，業(yè)務(wù)側(cè)要具備一些這種架構(gòu)設(shè)計上的考量，比如說架構(gòu)的柔性，可以自己去做限流、降級、做熔斷，這要求業(yè)務(wù)側(cè)有這樣的能力才可以，而不是說僅僅依靠監(jiān)控系統(tǒng)去做某些動作觸發(fā)。

至于說一些算法和策略的話，之前美圖這邊也是有過一些簡單的嘗試，應(yīng)用不算非常廣泛。但業(yè)界的話，DataOps、AIOps的概念也是比較火熱，這些東西在像BAT這些公司其實也有一些實際的應(yīng)用已經(jīng)在落地了。

之前我們做的話，有做這么幾個小東西，關(guān)于故障預(yù)測是有這么幾個算法：有同期的數(shù)據(jù)比較、同期的振幅比較、有一個移動平均算法、然后再有一個變點監(jiān)測。然后這幾個的話，可以簡單說一下思路，其實也比較好理解。

• 同期數(shù)據(jù)，是我按照周期，比如說今天某個時間點這個數(shù)據(jù)，我去比較昨天這個點是什么樣子的，去比較數(shù)據(jù)；

• 振幅，其實它就相對更柔性一點，里面會給你加上一個權(quán)重，加上一個比例，比如正態(tài)分布里邊的3-sigma，作為振幅系數(shù)去比較同期的數(shù)據(jù)，看在算上振幅之后，你是不是已經(jīng)超出了，去做一個預(yù)測；

• 變點監(jiān)測，就是說我整體的數(shù)據(jù)曲線是什么樣子的，突然出現(xiàn)了一個離我正常預(yù)測曲線偏離非常遠的一個點，這種的話會有一個這樣的算法來做這個事情。

然后這塊相對比較成熟的工具的話，像騰訊之前有開源的運維學(xué)件METIS，它里面集成了非常多的算法模型，這個有興趣的同學(xué)可以去做一些了解。

蔡翔華：首先從技術(shù)本身來說，5.0版本可以看到Zabbix的UI都很不錯，可以很多的組、主機都往大屏里面去拖。大屏的話，我們大概會分幾塊：

第一塊是整個系統(tǒng)運行狀態(tài)。我可能整個系統(tǒng)有從用戶登錄到用戶支付，包括到購物車等等，有一個鏈路。我對于每個鏈路其實都會有一個監(jiān)控，它每一個S組 Service的組，那么Service的組里面包括它的應(yīng)用、數(shù)據(jù)庫緩存、應(yīng)用系統(tǒng)甚至硬件服務(wù)器，一旦這里有任何東西出問題之后，直接會在大屏上顯示一個警告，那么我就會知道現(xiàn)在整個生產(chǎn)環(huán)節(jié)哪個系統(tǒng)是有問題的。

那么另外就是一個summary，一個overview的全局的導(dǎo)覽，因為一旦我知道這個有問題，我就希望更加細化知道這個東西哪里有問題。那么在下面就會有一個trigger list的問題列表，就是說有哪些觸發(fā)器被觸發(fā)了，我會看到比方說，數(shù)據(jù)庫端口不通了，還是說磁盤空間已經(jīng)滿了。下面會有trigger list，然后這個trigger list會按照故障等級是disaster還是warning，同時對應(yīng)的管理員或者運維人員也會收到這個短信，就知道要立即去處理了。

所以我們盡可能就在大屏里從兩方面來把控，一方面從大的來講，有一個over view看到全局，從小的來講，我要知道我的故障發(fā)生在哪里。基本上保證這兩個要素在大屏里面就OK了。

劉宇：我們這邊大屏其實主要還是應(yīng)用的維度以及網(wǎng)絡(luò)流量的維度為主。比如說從公網(wǎng)的一個出口和入口的流量來看會不會有大面積的一個問題。如果發(fā)現(xiàn)已經(jīng)達到外面防火墻或者它流量的一個閾值了，就可以迅速定位問題。

如果是細節(jié)的話，我們會在大型活動前夕，梳理活動鏈路上的所有應(yīng)用，根據(jù)應(yīng)用的維度來設(shè)計這樣一個大屏。大屏可以看到鏈路上所有應(yīng)用、數(shù)據(jù)庫或者是中間件的情況，一旦哪個應(yīng)用的QPS高了，或者是其他壓力的情況，就可以第一時間定位到問題出現(xiàn)在哪里，是這樣一個思路來做。

石鵬：監(jiān)控大屏做得好，確實可以輔助我們技術(shù)同學(xué)去更快地定位和排查問題，還有一個比較重要的點，我是這么想的，就是老板會關(guān)注。有些公司會把大屏設(shè)計得非常有科技感，讓老板看的話，可能老板也覺得我的技術(shù)團隊還挺牛的。當(dāng)然這是一個題外話。

前面蔡老師和劉老師都給了一些建設(shè)上的思路，就是你應(yīng)該去包含哪些數(shù)據(jù)，應(yīng)該怎么去做。這方面的話，我的一個思考是你可能要去做服務(wù)的梳理，然后可以以分塊、分業(yè)務(wù)或者說按照分層的方式來做。

分塊的話，就是你按照業(yè)務(wù)線來分。你公司可能有很多塊業(yè)務(wù)，然后按照不同的業(yè)務(wù)去提供一個視角。在每個業(yè)務(wù)里，你可以去做分層，分層的意思就是說可以把整個鏈路，從客戶端一直到CDN、 DNS鏈路，然后到LB入口層，以及應(yīng)用這一層是什么樣的，再關(guān)聯(lián)到后面的一些后端資源，像數(shù)據(jù)庫、緩存這些東西，還有一些其他的周邊依賴，按照這樣分層的方式來做。

具體實踐的話，可以跟大家做個預(yù)告，最近我們美圖有一些實踐經(jīng)驗可以分享，近期會把一些完整的設(shè)計思路和細節(jié)放出來，大家可以期待一下，持續(xù)關(guān)注dbaplus社群的發(fā)文。

關(guān)于技術(shù)實現(xiàn)方面，我簡單贅述兩句。我們公司的監(jiān)控大屏是用了Grafana來做的，Grafana可能已經(jīng)成為了事實上的監(jiān)控UI、數(shù)據(jù)可視化的標(biāo)準(zhǔn)了，它可以后面去接各種各樣的數(shù)據(jù)源，然后你各個監(jiān)控系統(tǒng)、各種數(shù)據(jù)原理的數(shù)據(jù)可以統(tǒng)一來展示。

這里需要感謝一個社區(qū)的插件，叫Flow Charting，這個插件可以非常好地去做監(jiān)控鏈路的事情，就是你可以用這個插件去把整個鏈路關(guān)鍵環(huán)節(jié)，以這種圖的方式繪制出來，然后給每一個點、每一條線綁定上監(jiān)控數(shù)據(jù)，最后生成的圖就動起來了，就可以看到一個全局性的鏈路狀態(tài)：從入口一直到后端資源，包括各種依賴，當(dāng)前它的狀態(tài)是什么樣子的。

當(dāng)然這個前提是，你整個鏈路的監(jiān)控數(shù)據(jù)是要完備的，然后你才可以借助這個插件去把它呈現(xiàn)出來，大概是這個樣子的，在這個圖上就一目了然了。

蔡翔華：如果是個純?nèi)萜骰?，就說你環(huán)境里面全是Docker，那么說實話我也不推薦你去使用Zabbix。

因為Zabbix對容器的監(jiān)控，雖然官方已經(jīng)開始重視了，甚至說現(xiàn)在也支持了Prometheus的很多metrics和exporter這種方式去做監(jiān)控，就是它也可以原生的去支持Prometheus這些東西，但相對來說，Prometheus在容器化監(jiān)控這邊還是會更好一些。

如果你的監(jiān)控需求是又要監(jiān)控硬件服務(wù)器，又要監(jiān)控中間件，又要監(jiān)控業(yè)務(wù)指標(biāo)，那么我推薦使用Zabbix，因為Zabbix覆蓋的面會更廣一些。

的確我覺得任何需求Zabbix和Prometheus都可以去做，但是從實現(xiàn)成本來說，相對于Prometheus，你的服務(wù)環(huán)境越復(fù)雜，Zabbix可能就越適合這種比較復(fù)雜的異構(gòu)的環(huán)境。

劉宇：我們目前公司情況是兩個都在用，的確是偏容器的會往Prometheus優(yōu)先考慮，如果是舊的，比如說是有偏服務(wù)化的這種監(jiān)控，也會慢慢地往Prometheus做一些遷移。

如果你的環(huán)境是一種就可以滿足的話，建議還是一種，因為畢竟只需要維護一種技術(shù)棧就可以了?；蛘呤悄憧梢宰鲆恍┢兀热缯f把一些不變的放在一種上面，經(jīng)常會變的放在另外一種上面。盡量去減少你維護的技術(shù)棧。如果你的環(huán)境比較簡單的話，只用一種，當(dāng)然是最好了。

石鵬：其實還是看場景，美圖跟劉老師這邊比較類似，我們也是多種監(jiān)控工具在用，不過我們現(xiàn)在沒有在用Zabbix，是用了Open-Falcon、Prometheus、InfluxDB，還有很多基于大數(shù)據(jù)的一些流式處理的組件，我們都是混合在用。

主要還是看你具體的需求和場景，沒有銀彈，沒有說一個工具可以非常合適去搞定所有事情。當(dāng)然它有可能有能力，但是它并不一定特別合適。至于具體的選擇上，還是要看具體場景。比較明確的一個思路可能就是要看你的監(jiān)控對象到底是容器還是非容器，它是這種易變的還是比較穩(wěn)定態(tài)的。這兩個思路的話，也是跟蔡老師和劉老師比較一致的。

蔡翔華：其實從場景來說，Prometheus更適合容器。你可以看一下整個環(huán)境里，容器和Zabbix的占比，像剛才劉老師說的，這兩者數(shù)據(jù)其實是可以互相使用、互相監(jiān)控甚至是互相觸發(fā)報警，那么在Zabbix現(xiàn)在其實已經(jīng)原生支持了Prometheus的這些exporter的功能，即使你沒有Prometheus后端，Zabbix也可以直接去exporter上拿一些數(shù)據(jù)，通過Zabbix的一些邏輯和機制去報警。那么相同的，Zabbix也可以通過action把這些數(shù)據(jù)扔給Prometheus。

也就是說，你可以把它們兩者當(dāng)中的一個作為數(shù)據(jù)的采集器，另外一個作為整個數(shù)據(jù)的邏輯處理的功能，類似于alert manager或者是在zabbix server一樣，這樣做的好處就是說，收集數(shù)據(jù)會非常方便，比方說Prometheus不能收集硬件數(shù)據(jù)，但Zabbix可以收集，我們就用Zabbix收集，同時把它的數(shù)據(jù)扔給Prometheus，做一個統(tǒng)一的報警。這樣的確還是要維護兩個平臺，但是相對來說，維護成本會有所降低，不需要對Zabbix那邊做太多的模板，它其實只是一個數(shù)據(jù)采集器。

那么穩(wěn)定性、可用性、性能及監(jiān)控這些東西，其實也基本上可以基于Prometheus現(xiàn)成的這些規(guī)則、Zabbix現(xiàn)成的這些模板來做。其實Zabbix社區(qū)里面也有很多模板可以提供到。

關(guān)鍵我覺得有一點就是，我們要思考它模板里面提供的東西，是否是我真的需要的，因為很多時候大家覺得我啥都要監(jiān)控，但事實上不是這樣子，只有真正需要關(guān)注的點，才是需要監(jiān)控的東西。所以說大家在部署監(jiān)控之前，要先思考一下監(jiān)控的目的是什么。

劉宇：我的看法其實還是這樣，比如說偏基礎(chǔ)的，像主機、網(wǎng)絡(luò)這種可以用Zabbix來監(jiān)控，偏服務(wù)類的和容器的，就用Prometheus來做監(jiān)控。

我們監(jiān)控Redis的一個集群，在以前沒有Grafana或者Prometheus的情況下，用Zabbix去看集群的整體情況就會比較麻煩，因為Zabbix依賴的監(jiān)控的一個點還是以host為基礎(chǔ)的，所以你去看整個服務(wù)的話會比較麻煩。而Prometheus因為它是時序的數(shù)據(jù)，可以方便地去打一些你想要的標(biāo)簽，這樣就可以比較方便地監(jiān)控單個服務(wù)上一個整體的情況，所以服務(wù)這塊來說，還是Prometheus比較方便。而前面其他蔡老師也說了，比如說硬件這種還是Zabbix比較好用。

石鵬：OK，這個點上我們理解還是非常一致的。像現(xiàn)在美圖這邊，就單講Prometheus和Open-Falcon，我們基礎(chǔ)的這些監(jiān)控都是在Open-Falcon里，然后容器會在Prometheus里。

這里需要補充一下我們的環(huán)境，現(xiàn)在我們所有業(yè)務(wù)都是基于云上來做的，業(yè)務(wù)容器化程度的話，應(yīng)該是只有個別服務(wù)沒有容器化，整個比例應(yīng)該95%以上都是容器化的。但即使是這樣，我們也沒有完全摒棄掉Open-Falcon。

我們在這個容器里，容器層的這些服務(wù)，像servive、pod這些監(jiān)控，比如說業(yè)務(wù)上暴露出來的metrics，這些東西我們都是用Prometheus來做的。但是像k8s node節(jié)點、ECS，它本身的一些監(jiān)控，包括一些網(wǎng)絡(luò)質(zhì)量的監(jiān)控，還是要有一個更適合做這種基礎(chǔ)監(jiān)控的平臺來做。我們就是在Open-Falcon里做的。

所以主要還是看場景，怎么去側(cè)重就是看你具體的需求了。

蔡翔華：如果已經(jīng)部署了Zabbix，我估計你直接通過數(shù)據(jù)庫去導(dǎo)入這種方式會很難做，因為它的表結(jié)構(gòu)，包括一個是時序數(shù)據(jù)庫，一個是TSDB，就沒辦法直接做。

我建議如果真的要過渡到Prometheus的話，可以仍然使用Zabbix agent，在數(shù)據(jù)采樣完之后，把它扔到Prometheus，觸發(fā)一些action去提供給Prometheus。這是一種中轉(zhuǎn)方式。

另外一種方式，我會通過一些ansible去部署一些Prometheus expoter到那些機器上去，把這些數(shù)據(jù)扔給Prometheus。其實也就回到剛才那個問題，我這邊所有的數(shù)據(jù)都可以扔給Prometheus使用，去觸發(fā)報警，這都OK的。

劉宇：如果真的要把Zabbix遷移到Prometheus，就是涉及到一個監(jiān)控遷移的過程。我這邊的建議還是按照Zabbix先模塊劃分，比如說其中一個模塊準(zhǔn)備遷到Prometheus，然后首先會把這個模塊Prometheus的監(jiān)控也加上，會把兩邊的監(jiān)控進行一個比較，至少Prometheus能把原來Zabbix的監(jiān)控都能覆蓋掉，不僅是監(jiān)控的覆蓋，還有告警覆蓋，這樣一個并行的過程。

最終完全能夠達到一樣的效果，我就可以把原來Zabbix相關(guān)模塊的監(jiān)控給下掉，是這樣一個建議的路徑。

蔡翔華：對，而且其實Prometheus和Zabbix同時存在并不沖突，并不是說兩者只能選其一。其實可以說，我先把Prometheus的exporter規(guī)則都配上去，兩邊同時監(jiān)控，然后再根據(jù)需求，把Zabbix給下了，也OK，這是不存在沖突的。

石鵬：沒錯，既然你要平滑，那兩邊同時有，這應(yīng)該是最平滑的。我們之前是有從Zabbix遷到了Open-Falcon，遷移經(jīng)過了一個比較長的耗時，大概用了一年多的時間。其實就是你把另一邊的監(jiān)控也布起來，同時監(jiān)控，然后逐步去下舊監(jiān)控。在這個過程里，你還可以去比較兩者之間是不是有差異，是不是都能滿足需求，這樣的話應(yīng)該是比較平滑的。

蔡翔華：分布式鏈路其實我們沒有用Zabbix，因為分布式鏈路要考慮上下游的關(guān)系，所以我們會基于APM去做?，F(xiàn)在像業(yè)內(nèi)比較流行的CAT，可以參考這些去做。

端到端的偵測的話，其實Zabbix也支持，它支持兩種方式：

一個是它可以在本地跑一些腳本去做，就是說我這個檢測是從Zabbix某個Agen端出發(fā)，到另外一臺目標(biāo)機器，而不是通過Zabbix server去做檢測。所以說這是Zabbix 提供的另外一種方式，Zabbix active的一種方式，它可以去實現(xiàn)這種端到端的偵測。Zabbix active的監(jiān)控方式也是比較好的一種方式，可以減輕Zabbix server端的壓力，或proxy端的壓力，能提供更豐富的一些監(jiān)控。

劉宇：這塊因為Prometheus是一個基于數(shù)值的監(jiān)控，對于這種全鏈路的話，一般不太會用Prometheus來做，基本上會用APM的一些分布式鏈路追蹤的工具，比如skywalking等來做。

還會通過一些日志系統(tǒng)來做分布式的監(jiān)控，在鏈路上，提前寫入一些標(biāo)簽，這樣從始至終都可以拿到整個鏈路上的一個關(guān)系，就可以做一些分布式鏈路上的監(jiān)控的東西。

石鵬：是的，這也就回到我們前面討論的，沒有銀彈，沒有一種技術(shù)?？梢越鉀Q所有需求的。包括Zabbix和Prometheus，其實更關(guān)注的還是在偏服務(wù)端，如果是應(yīng)用端的話，其實還是要依賴一些APM的工具。就像劉老師說的Apache的skywalking，還有像鷹眼、基于open tracing的其他工具。這些東西其實都是一種思路。

還有一些有技術(shù)能力的公司，會選擇自研一些APM工具，需要自己去開發(fā)各種SDK，然后需要遷到客戶端，去上報數(shù)據(jù)，是這個樣子的。

其實端到端整體的建設(shè)思路應(yīng)該是分段的，客戶端的是一段，中間鏈路是一段，服務(wù)端又是另外一側(cè)。所以想做端到端，很難說用一個工具就可以完全覆蓋起來。

現(xiàn)在基于云原生、微服務(wù)這些發(fā)展的比較火熱，可能會有一些各個服務(wù)之間調(diào)用鏈路的服務(wù)治理相關(guān)的監(jiān)控需求，可能也不是說通過Prometheus或Zabbix就可以很好地去完成。還是要看需求場景，選擇更合適的工具，并且組合起來使用。

蔡翔華：首先我覺得還是看應(yīng)用場景，因為大規(guī)模場景下，要看這個場景是容器多還是非容器環(huán)境多，這是一個主要依據(jù)。

Zabbix性能的話，其實瓶頸主要是在數(shù)據(jù)庫，只要把數(shù)據(jù)庫的優(yōu)化做得足夠好，其實開頭也說了，業(yè)內(nèi)也有做到40萬NVPS的這種案例，已經(jīng)是比較變態(tài)了。那無非就是說，去做數(shù)據(jù)庫分區(qū)分庫拆表、加SSD存儲，通過這種方式。

成本的話，我個人覺得在底層資源滿足的前提下，成本應(yīng)該都OK。因為Prometheus是基于exporter，Zabbix是基于Agent，通過Zabbix agent，配合自動發(fā)現(xiàn)和低級別發(fā)現(xiàn)的這種方式去實現(xiàn)自動化。

配置成本可能Zabbix會低很多，因為都是基于UI去做，而Prometheus是基于配置文件去做，這個可能Zabbix會更好些。所以我綜合成本，覺得Zabbix稍微會好一些，但還是取決于你的場景里有多少虛擬化。

劉宇：我覺得如果是性能的話，通過一些分區(qū)的手段都能解決。但如果是非常大的規(guī)模，通過Zabbix，其實它的數(shù)據(jù)庫瓶頸還是比較嚴重的，這塊還是需要一些比較好優(yōu)化手段才能解決。

監(jiān)控采集的agent的方式而言，我覺得Prometheus的exporter做得非常全面，像我們以前用Zabbix，基本上有很多東西監(jiān)控都是自己去開發(fā)的；而現(xiàn)在用Prometheus，基本上對于這種采集器的開發(fā)都沒有了，用社區(qū)的就可以全部解決了。所以在采集的層面上，去實現(xiàn)它最底層和服務(wù)的一個數(shù)據(jù)采集，我感覺Prometheus的成本會更低一點。

當(dāng)然因為Prometheus相對來說還是一個微服務(wù)的架構(gòu)，它的所有組件都是分開的，在搭建成本、學(xué)習(xí)成本會稍微高一點。

石鵬：其實還是要針對個性化的場景去做一些選擇。成本的話，如果說你的環(huán)境是一個比較純粹的，要么是全容器，要么是虛擬化或者物理環(huán)境，你就選一種就好了。如果說你是異構(gòu)的話，可能就不可避免的要選兩種同時維護。這兩種里如果有所側(cè)重的話，成本其實就會有所側(cè)重，所以還是看你的具體需求。

選型，在于抓住監(jiān)控的核心

對于大家比較關(guān)注的監(jiān)控工具選型，用一句話來概括就是：沒有最好的，只有最適合的，要具體場景具體分析。

總的來講，如果是比較純粹的環(huán)境，比如是純物理機、純虛擬機，更關(guān)注一些偏基礎(chǔ)設(shè)施層面的需求的話，Zabbix會是一個非常不錯的選項；如果是容器化場景，Prometheus的適應(yīng)性會更好；如果是異構(gòu)的話，建議兩者或更多其它工具結(jié)合起來使用。

縱觀整個監(jiān)控發(fā)展史，其實監(jiān)控方案一直是跟隨著行業(yè)技術(shù)、業(yè)務(wù)發(fā)展不斷變化的。到現(xiàn)在，比較火熱的技術(shù)像5G互聯(lián)、物聯(lián)網(wǎng)、人工智能……各種技術(shù)層出不窮，我們需要去監(jiān)控的目標(biāo)對象也一直發(fā)生著變化。隨著多云、混合云架構(gòu)在更多行業(yè)里持續(xù)落地開花，容器、云原生等各種技術(shù)的蓬勃發(fā)展，對監(jiān)控系統(tǒng)其實也提出了新的需求。

技術(shù)更新迭代速度越來越快，很多同學(xué)難免會有一些焦慮的情緒。這種焦慮是不可避免的，我們應(yīng)該做的還是要去抓住事物的本質(zhì)。

針對監(jiān)控這個需求，也就是說監(jiān)控的核心是什么？

監(jiān)控在高度抽象之后，無非可以這么來分：監(jiān)控數(shù)據(jù)的暴露、數(shù)據(jù)的采集和傳輸、監(jiān)控數(shù)據(jù)的存儲和處理……這個過程里，包括各種優(yōu)化、各種格式化處理等；最后是我們怎么去用好監(jiān)控數(shù)據(jù)，把監(jiān)控數(shù)據(jù)的價值最大化，比如說我們?nèi)プ鰣蟊碚故?、做?shù)據(jù)分析，像前面講到的用一些DataOps、AIOps的算法、能力介入，把監(jiān)控數(shù)據(jù)的價值挖掘出來。

這其實就是監(jiān)控系統(tǒng)所要承載的功能，我們要做的就是抓住這些核心路徑里的原理，然后掌握它，其實也就OK了。

另外，我們需要保持對這些新鮮事物的熱忱，保持對技術(shù)的敏銳，要有行業(yè)發(fā)展趨勢的感知能力。比如企業(yè)上云，其實從行業(yè)報告來看，從去年就已經(jīng)過了上云的拐點，會有越來越多公司選擇把服務(wù)遷移到云上；再看容器和云原生，會有越來越多的周邊生態(tài)完善起來。我們要有這樣的感知能力，要能夠感受到這個行業(yè)發(fā)展的脈搏，然后做好相應(yīng)的技術(shù)儲備，只有這樣，我們才可能在技術(shù)的浪潮里做到從容不迫，才能夠乘風(fēng)破浪。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝