萬字談監控:解答Zabbix與Prometheus選型疑難

本文由 dbaplus 社羣授權轉載。

Zabbix與Prometheus

  1. 兩者適用於多大規模的監控場景?超過5000以上監控節點時怎麼辦?高可用怎麼解決?
  2. 兩者怎麼解決存儲問題?對於監控信息是否有歷史存儲和分析,能從歷史信息中挖掘到哪些有價值的信息?
  3. 兩者怎麼應對告警風暴和誤報?
  4. 在智能監控和自動治癒方面是否有可借鑑的實踐?基於什麼算法或策略?怎麼進行故障預判和預處理?
  5. 監控大屏是怎麼設計的?
  6. 自動化運維管理是兩者同時使用還是二選一更合適?
  7. 兩者在配合使用時,應該怎麼分工?怎麼落地?
  8. 如果已經部署了Zabbix,怎麼平穩過渡到Prometheus?
  9. 分佈式鏈路的可觀測性和端到端診斷怎麼做?
  10. 大規模場景下,兩者的性能和成本哪個比較低?

監控,爲什麼總讓我們頭痛

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

說起來,監控在不同的團隊和公司之間,可能會存在各種差異化的需求。如何基於開源產品打造一個符合自己業務場景的監控體系,並且持續迭代?這成爲了大家無法繞開的課題。

比如說,如何選擇監控方案和開源工具?如何爲自己的業務場景做定製化適配?如何實現端到端的全鏈路監控?如何讓業務方以更低成本接入到這個系統中?如何做監控的自動化?如何做異常告警的路由、分發、收斂和抑制?如何做統一化的監控大屏、Dashboard等等……這些都是我們在構建監控系統中可能會面臨的問題。

圍繞這些問題,dbaplus社羣特別邀請到 美圖SRE負責人-石鵬(東方德勝) 作爲主持人、 招商銀行技術經理-蔡翔華 作爲Zabbix使用方、 甜橙金融基礎技術架構師-劉宇 作爲Prometheus使用方,針對Zabbix和Prometheus展開實用選型探討。

十問十答,監控工具怎麼選

Q1Zabbix和Prometheus分別適用於多大規模的監控場景?超過5000以上監控節點時怎麼辦?高可用怎麼解決?

蔡翔華: 我們和Zabbix官方其實有溝通過,業內他們有一些監控到了40萬以上的節點數,當然這個節點數也要根據你每個節點上監控多少東西。Zabbix其實有一個指標叫做NVPS(New Value Per Second),也就是每秒新增的值的指標,來判斷你的監控規模是不是合適的。

那麼對於5000個節點以上的場景來說,其實Zabbix還是OK的,你可以通過多佈署一些Proxy,去對後臺數據庫做一些性能調優等等,以這些方式去提高整個監控平臺的可承受、負載的性能。

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

石鵬: 好的,蔡老師的核心觀點其實就是我們需要關注核心的指標,也就是NVPS,這個值是比較關鍵的。然後蔡老師之前您在實際的應用中,見過這個系統的峯值可以達到多少嗎?是否可以給大家做個參考?

蔡翔華: 在我們自己的環境裏面,NVPS峯值達到過6000以上,但我們後面其實也做了一些優化,把它調整到3000左右。主要目的是,因爲一開始我們做的時候是希望做到大而全,什麼都監控,但最後發現其實大而全不一定有用,因爲很多監控即使它是問題,你也不會care它。

劉宇: 是的,蔡老師已經講得比較詳細了,其實以多大的規模是取決於你的監控目標,還有就是採集的間隔,比如說5秒採集一次和1分鐘採集一次,這個規模都是支持着不一樣的目標,所以還是要根據你的需求。

一般來說,我們會配置成30秒或者是一分鐘;如果是對於高頻的,會15秒。因爲單個Prometheus性能已經比較強了,一般來說,它每秒百萬個指標都是沒什麼問題的。Prometheus會根據你的指標來計算,就是看你一個監控點上有多少個指標,這樣來換算。

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

當然,如果你單個的性能還是不夠的話,可以用分區,即用hash mod去多分幾個Prometheus來做監控。

然後關於高可用這塊,其實社區Prometheus這部分做得也不是特別好,會用兩個Prometheus來同時監控同樣的一個目標,這樣來做到一個高可用。當然,在容器環境,你也可以去通過K8S的deployment這種方式,來把高可用維護起來。

Q2Zabbix和Prometheus怎麼解決存儲問題?對於監控信息是否有歷史存儲和分析,能從歷史信息中挖掘到哪些有價值的信息?

蔡翔華: 的確,存儲這個問題因爲監控寫的東西最多就是寫到存儲裏面去,Zabbix以前被吐槽最多的就是它不支持時序數據庫TSDB。其實在4.2以後,它就已經開始支持TSDB了,當然可能還沒有Prometheus那麼成熟,它主要的數據庫還是MySQL爲主。

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

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

我們實際場景應用的話,主要是用於我們的性能分析,因爲我們有很多互聯網應用,會看一下這個業務增長對我平臺的要求,會不會CPU比較緊張、內存比較緊張等等。另外,我們會根據這些數據做一個分析,爲我們後期的擴容、決策提供一些參考性的依據。比方說我現在看到今年整體的使用率在多少,我們每年的增長量是在20%還是30%,這樣我們後續做一些決策的時候,是需要多少的資源、多少的預算,就比較能有參考價值。

劉宇: Prometheus本身存儲如果存在本地的話,大概只能存15天,最多你也只能放到30天這樣子。官方其實也不建議你把所有的監控數據都存在Prometheus的一個本地的數據庫裏。所以我在案例分享中也提到了一個遠端存儲的技術(案例分享內容請關注dbaplus社羣后續文章發佈)。

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

石鵬: 好的瞭解,其實關於存儲這個問題,我們還是更多應該從需求出發。整體來看有一些比較通用的思路,最典型的就是這兩種:

第一種是數據的轉儲。比如像Prometheus,我們在本地只存2周或者4周的數據,然後更多的話,就把它寫到遠端。

第二種思路是做數據採樣。其實在很多監控系統裏面,是一個比較常規的思路,就像在Zabbix裏的history、trend,開始可能是每30秒一個點,然後數據採樣之後,可能是每5分鐘一個點。就用這樣的方式,把這個數據量級減小,然後以此來做存儲問題的優化。

Q3Zabbix和Prometheus怎麼應對告警風暴和誤報?

蔡翔華: 首先誤報這個事情,其實在我理解裏是不存在的。也就是說,之所以我們會覺得很多有誤報的東西存在,是因爲我們對於規則,比方說我監控東西或者是我配置觸發器,本身是有問題的。

我碰到很多人說,打算監控它的CPU使用率,很多人會直接記錄usage,它的使用率,也有很多人會監控它的free的這個space。但有時候會由於配置錯誤,導致原本監控cpu usage的使用了cpu free的指標。所以說,其實很多時候報警之所以會產生誤報,是因爲配置本身不是很正確。

Zabbix的工作機制很簡單:我去收集數據,去根據這個處罰規則去做比較,然後去發報警。當中所有的邏輯其實本身是不會出任何問題,除非說收集數據配錯了、觸發規則配錯了、報警機制配錯了……這些其實更多是人爲的因素在裏面。

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

另外一個減少誤報的方式是通過模板化。因爲我們只要配置一次模板,那我把所有的Linux機型的監控模板都統一起來,對於所有監控Linux都套用同一個模板,那麼就可以在一定程度上降低誤報。關鍵還是在於人的問題。

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

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

那這種規則的制定其實就比較不是那麼具體,會比較抽象,可能比如說把必須要人工介入處理的這種,才把它定爲告警;然後如果系統可以自己處理掉,就不要把它告出來,或者只是在後面做一個每天發一次的報告也就行了。這是我對誤報的一個看法。

關於告警風暴,在Prometheus中,對告警風暴的處理方式是這樣:可以通過靜默告警解決,或者是可以加入維護組,或者是也可以做一個聚合,也就是把告警給聚集,然後同類的告警合併,這樣來減少告警的條數,主要是這樣來做的。

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

石鵬: 好的,我總結一下,關於誤報這個問題,兩位老師的意見是比較一致的,我也是比較贊同的。誤報其實最根本的原因就是可能你的使用不合理,不管是你的配置還是說你的各種姿勢可能不合理,纔會導致誤報。

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

可能在很多公司,他們除了監控平臺本身去做告警風暴的抑制,還會有另外一層。比如說我們公司這邊是這樣:

我們有一個告警平臺,所有的告警都會彙集到這個告警平臺裏,然後這個告警平臺會去做一層合併、收斂和抑制。這樣的話,就可以不用特別依賴監控平臺本身來提供這些特性,而是由一個統一的平臺,在做最後發送動作的時候,再來做一層cover。可能在量級大的場景下,這種是比較推薦的一種思路。

蔡翔華: 是的,因爲真正的監控當中,其實還會納入很多比方說ES等其它監控平臺,甚至是一些業務告警。當平臺很多的時候,其實你需要有一層聚合的方式,去把告警做一個聚合收斂,然後通過在聚合平臺裏配置一定規則之後,再去做後續的一些報警。

石鵬: 沒錯,並且你有這個平臺之後,就可以把一些告警的規則和策略做得更統一,這樣的話,給用戶的界面和體驗也會更好。

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

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

Q4在智能監控和自動治癒方面是否有可借鑑的實踐?基於什麼算法或策略?怎麼進行故障預判和預處理?

蔡翔華: 首先我們是有嘗試過智能監控,但是包括我看到的很多書籍裏面,包括Prometheus的一些書籍裏面,也說設這種固定的預知是一個很蠢的方法。

根據我這邊實際的應用,其實你要做到智能監控,肯定要有一些大數據的東西,比方說我有這種規律:

例如,按照我們的實際操作裏有很多互聯網的應用,有些東西它就是會有高併發高搶購,可能每個月固定的時候,比如每個月10號放一個活動,活動時它的量是平時的10倍甚至100倍;但也可能有時候,業務會不停地在不同的時間放,你很難去判斷這個點到底是不是一個故障點。

也就是說,你用戶數從10變成了1萬,這1萬到底是因爲故障了,還是說是因爲業務的一些邏輯導致的,很難判斷。所以目前來說,我們嘗試以後,還是用了一些比較固定的報警預知去做。

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

預測的數據也是基於現狀的,如果可以對預測數據進行判斷報警,理論上,也可以針對現有的數據進行判斷報警。

劉宇: 這塊我們實踐的案例倒不是特別多,我主要還是對數據庫的監控比較熟,所以就說一下我們在數據庫的自動治癒上是怎麼實現的吧。

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

石鵬: 嗯嗯,這個問題其實比較前沿,並且涉獵的範圍是比較廣的。像自動治癒,其實Zabbix也有一些相關的功能,它可以去配置action,當發現告警,有問題,我就可以綁定腳本去做一下處理。

但這個東西要做到什麼程度,或者說要用什麼技術來打造這個底座,可能都會有些差別。

蔡翔華: 是的,因爲我覺得Prometheus和Zabbix或者說其他平臺,都支持調action、調腳本去做一些重啓,但是我覺得關鍵問題的點是在於你敢不敢做這個事情。

因爲我們知道我們的環境其實是很複雜的。比方說,我發覺數據庫宕了,服務停了,我敢不敢通過這個服務自己切過去。因爲很多時候並不是數據庫本身的問題,是網絡的問題,網絡抖動了,監控數據拿不到了。這個是非常依賴於整個整體環境的,你可能要想到方方面面,這個規則會非常複雜。你可能在做服務自愈的時候,還要去對其他的東西做一個完全的檢查,確保其他東西是沒有問題的。

所以不說服務自愈,哪怕在我們日常的故障處理當中,也很依賴於經驗。就是說這個東西是能做的,但是我們不太敢,因爲要考慮的要素很多,就不太敢去直接做自愈這一塊。

石鵬: 沒錯,本身其實它是一個體系化的工程,不僅僅是跟監控相關。我這邊的一個想法是這樣,關於自動治癒這塊,我們可能還是要更多去依靠業務側的能力。就是說,業務側要具備一些這種架構設計上的考量,比如說架構的柔性,可以自己去做限流、降級、做熔斷,這要求業務側有這樣的能力纔可以,而不是說僅僅依靠監控系統去做某些動作觸發。

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

之前我們做的話,有做這麼幾個小東西,關於故障預測是有這麼幾個算法:有同期的數據比較、同期的振幅比較、有一個移動平均算法、然後再有一個變點監測。然後這幾個的話,可以簡單說一下思路,其實也比較好理解。

  • 同期數據,是我按照週期,比如說今天某個時間點這個數據,我去比較昨天這個點是什麼樣子的,去比較數據;
  • 振幅,其實它就相對更柔性一點,裏面會給你加上一個權重,加上一個比例,比如正態分佈裏邊的3-sigma,作爲振幅係數去比較同期的數據,看在算上振幅之後,你是不是已經超出了,去做一個預測;
  • 變點監測,就是說我整體的數據曲線是什麼樣子的,突然出現了一個離我正常預測曲線偏離非常遠的一個點,這種的話會有一個這樣的算法來做這個事情。

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

Q5監控大屏是怎麼設計的?

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

第一塊是整個系統運行狀態。我可能整個系統有從用戶登錄到用戶支付,包括到購物車等等,有一個鏈路。我對於每個鏈路其實都會有一個監控,它每一個S組 Service的組,那麼Service的組裏麪包括它的應用、數據庫緩存、應用系統甚至硬件服務器,一旦這裏有任何東西出問題之後,直接會在大屏上顯示一個警告,那麼我就會知道現在整個生產環節哪個系統是有問題的。

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

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

劉宇: 我們這邊大屏其實主要還是應用的維度以及網絡流量的維度爲主。比如說從公網的一個出口和入口的流量來看會不會有大面積的一個問題。如果發現已經達到外面防火牆或者它流量的一個閾值了,就可以迅速定位問題。

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

石鵬: 監控大屏做得好,確實可以輔助我們技術同學去更快地定位和排查問題,還有一個比較重要的點,我是這麼想的,就是老闆會關注。有些公司會把大屏設計得非常有科技感,讓老闆看的話,可能老闆也覺得我的技術團隊還挺牛的。當然這是一個題外話。

前面蔡老師和劉老師都給了一些建設上的思路,就是你應該去包含哪些數據,應該怎麼去做。這方面的話,我的一個思考是你可能要去做服務的梳理,然後可以以分塊、分業務或者說按照分層的方式來做。

分塊的話,就是你按照業務線來分。你公司可能有很多塊業務,然後按照不同的業務去提供一個視角。在每個業務裏,你可以去做分層,分層的意思就是說可以把整個鏈路,從客戶端一直到CDN、 DNS鏈路,然後到LB入口層,以及應用這一層是什麼樣的,再關聯到後面的一些後端資源,像數據庫、緩存這些東西,還有一些其他的周邊依賴,按照這樣分層的方式來做。

具體實踐的話,可以跟大家做個預告,最近我們美圖有一些實踐經驗可以分享,近期會把一些完整的設計思路和細節放出來,大家可以期待一下,持續關注dbaplus社羣的發文。

關於技術實現方面,我簡單贅述兩句。我們公司的監控大屏是用了Grafana來做的,Grafana可能已經成爲了事實上的監控UI、數據可視化的標準了,它可以後面去接各種各樣的數據源,然後你各個監控系統、各種數據原理的數據可以統一來展示。

這裏需要感謝一個社區的插件,叫Flow Charting,這個插件可以非常好地去做監控鏈路的事情,就是你可以用這個插件去把整個鏈路關鍵環節,以這種圖的方式繪製出來,然後給每一個點、每一條線綁定上監控數據,最後生成的圖就動起來了,就可以看到一個全局性的鏈路狀態:從入口一直到後端資源,包括各種依賴,當前它的狀態是什麼樣子的。

當然這個前提是,你整個鏈路的監控數據是要完備的,然後你纔可以藉助這個插件去把它呈現出來,大概是這個樣子的,在這個圖上就一目瞭然了。

Q6自動化運維管理是Zabbix和Prometheus同時使用還是二選一更合適?

蔡翔華: 如果是個純容器化的,就說你環境裏面全是Docker,那麼說實話我也不推薦你去使用Zabbix。

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

如果你的監控需求是又要監控硬件服務器,又要監控中間件,又要監控業務指標,那麼我推薦使用Zabbix,因爲Zabbix覆蓋的面會更廣一些。

的確我覺得任何需求Zabbix和Prometheus都可以去做,但是從實現成本來說,相對於Prometheus,你的服務環境越複雜,Zabbix可能就越適合這種比較複雜的異構的環境。

劉宇: 我們目前公司情況是兩個都在用,的確是偏容器的會往Prometheus優先考慮,如果是舊的,比如說是有偏服務化的這種監控,也會慢慢地往Prometheus做一些遷移。

如果你的環境是一種就可以滿足的話,建議還是一種,因爲畢竟只需要維護一種技術棧就可以了。或者是你可以做一些偏重,比如說把一些不變的放在一種上面,經常會變的放在另外一種上面。儘量去減少你維護的技術棧。如果你的環境比較簡單的話,只用一種,當然是最好了。

石鵬: 其實還是看場景,美圖跟劉老師這邊比較類似,我們也是多種監控工具在用,不過我們現在沒有在用Zabbix,是用了Open-Falcon、Prometheus、InfluxDB,還有很多基於大數據的一些流式處理的組件,我們都是混合在用。

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

Q7在配合使用時,應該怎麼分工?怎麼落地?

蔡翔華: 其實從場景來說,Prometheus更適合容器。你可以看一下整個環境裏,容器和Zabbix的佔比,像剛纔劉老師說的,這兩者數據其實是可以互相使用、互相監控甚至是互相觸發報警,那麼在Zabbix現在其實已經原生支持了Prometheus的這些exporter的功能,即使你沒有Prometheus後端,Zabbix也可以直接去exporter上拿一些數據,通過Zabbix的一些邏輯和機制去報警。那麼相同的,Zabbix也可以通過action把這些數據扔給Prometheus。

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

那麼穩定性、可用性、性能及監控這些東西,其實也基本上可以基於Prometheus現成的這些規則、Zabbix現成的這些模板來做。其實Zabbix社區裏面也有很多模板可以提供到。

關鍵我覺得有一點就是,我們要思考它模板裏面提供的東西,是否是我真的需要的,因爲很多時候大家覺得我啥都要監控,但事實上不是這樣子,只有真正需要關注的點,纔是需要監控的東西。所以說大家在部署監控之前,要先思考一下監控的目的是什麼。

劉宇: 我的看法其實還是這樣,比如說偏基礎的,像主機、網絡這種可以用Zabbix來監控,偏服務類的和容器的,就用Prometheus來做監控。

我們監控Redis的一個集羣,在以前沒有Grafana或者Prometheus的情況下,用Zabbix去看集羣的整體情況就會比較麻煩,因爲Zabbix依賴的監控的一個點還是以host爲基礎的,所以你去看整個服務的話會比較麻煩。而Prometheus因爲它是時序的數據,可以方便地去打一些你想要的標籤,這樣就可以比較方便地監控單個服務上一個整體的情況,所以服務這塊來說,還是Prometheus比較方便。而前面其他蔡老師也說了,比如說硬件這種還是Zabbix比較好用。

石鵬: OK,這個點上我們理解還是非常一致的。像現在美圖這邊,就單講Prometheus和Open-Falcon,我們基礎的這些監控都是在Open-Falcon裏,然後容器會在Prometheus裏。

這裏需要補充一下我們的環境,現在我們所有業務都是基於雲上來做的,業務容器化程度的話,應該是隻有個別服務沒有容器化,整個比例應該95%以上都是容器化的。但即使是這樣,我們也沒有完全摒棄掉Open-Falcon。

我們在這個容器裏,容器層的這些服務,像servive、pod這些監控,比如說業務上暴露出來的metrics,這些東西我們都是用Prometheus來做的。但是像k8s node節點、ECS,它本身的一些監控,包括一些網絡質量的監控,還是要有一個更適合做這種基礎監控的平臺來做。我們就是在Open-Falcon裏做的。

所以主要還是看場景,怎麼去側重就是看你具體的需求了。

Q8如果已經部署了Zabbix,怎麼平穩過渡到Prometheus?

蔡翔華: 如果已經部署了Zabbix,我估計你直接通過數據庫去導入這種方式會很難做,因爲它的表結構,包括一個是時序數據庫,一個是TSDB,就沒辦法直接做。

我建議如果真的要過渡到Prometheus的話,可以仍然使用Zabbix agent,在數據採樣完之後,把它扔到Prometheus,觸發一些action去提供給Prometheus。這是一種中轉方式。

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

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

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

蔡翔華: 對,而且其實Prometheus和Zabbix同時存在並不衝突,並不是說兩者只能選其一。其實可以說,我先把Prometheus的exporter規則都配上去,兩邊同時監控,然後再根據需求,把Zabbix給下了,也OK,這是不存在衝突的。

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

Q9分佈式鏈路的可觀測性和端到端診斷怎麼做?

蔡翔華: 分佈式鏈路其實我們沒有用Zabbix,因爲分佈式鏈路要考慮上下游的關係,所以我們會基於APM去做。現在像業內比較流行的CAT,可以參考這些去做。

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

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

劉宇: 這塊因爲Prometheus是一個基於數值的監控,對於這種全鏈路的話,一般不太會用Prometheus來做,基本上會用APM的一些分佈式鏈路追蹤的工具,比如skywalking等來做。

還會通過一些日誌系統來做分佈式的監控,在鏈路上,提前寫入一些標籤,這樣從始至終都可以拿到整個鏈路上的一個關係,就可以做一些分佈式鏈路上的監控的東西。

石鵬: 是的,這也就回到我們前面討論的,沒有銀彈,沒有一種技術棧可以解決所有需求的。包括Zabbix和Prometheus,其實更關注的還是在偏服務端,如果是應用端的話,其實還是要依賴一些APM的工具。就像劉老師說的Apache的skywalking,還有像鷹眼、基於open tracing的其他工具。這些東西其實都是一種思路。

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

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

現在基於雲原生、微服務這些發展的比較火熱,可能會有一些各個服務之間調用鏈路的服務治理相關的監控需求,可能也不是說通過Prometheus或Zabbix就可以很好地去完成。還是要看需求場景,選擇更合適的工具,並且組合起來使用。

Q10大規模場景下,Prometheus和Zabbix的性能和成本哪個比較低?

蔡翔華: 首先我覺得還是看應用場景,因爲大規模場景下,要看這個場景是容器多還是非容器環境多,這是一個主要依據。

Zabbix性能的話,其實瓶頸主要是在數據庫,只要把數據庫的優化做得足夠好,其實開頭也說了,業內也有做到40萬NVPS的這種案例,已經是比較變態了。那無非就是說,去做數據庫分區分庫拆表、加SSD存儲,通過這種方式。

成本的話,我個人覺得在底層資源滿足的前提下,成本應該都OK。因爲Prometheus是基於exporter,Zabbix是基於Agent,通過Zabbix agent,配合自動發現和低級別發現的這種方式去實現自動化。

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

劉宇: 我覺得如果是性能的話,通過一些分區的手段都能解決。但如果是非常大的規模,通過Zabbix,其實它的數據庫瓶頸還是比較嚴重的,這塊還是需要一些比較好優化手段才能解決。

監控採集的agent的方式而言,我覺得Prometheus的exporter做得非常全面,像我們以前用Zabbix,基本上有很多東西監控都是自己去開發的;而現在用Prometheus,基本上對於這種採集器的開發都沒有了,用社區的就可以全部解決了。所以在採集的層面上,去實現它最底層和服務的一個數據採集,我感覺Prometheus的成本會更低一點。

當然因爲Prometheus相對來說還是一個微服務的架構,它的所有組件都是分開的,在搭建成本、學習成本會稍微高一點。

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

選型,在於抓住監控的核心

對於大家比較關注的監控工具選型,用一句話來概括就是:沒有最好的,只有最適合的,要具體場景具體分析。

總的來講,如果是比較純粹的環境,比如是純物理機、純虛擬機,更關注一些偏基礎設施層面的需求的話,Zabbix會是一個非常不錯的選項;如果是容器化場景,Prometheus的適應性會更好;如果是異構的話,建議兩者或更多其它工具結合起來使用。

縱觀整個監控發展史,其實監控方案一直是跟隨着行業技術、業務發展不斷變化的。到現在,比較火熱的技術像5G互聯、物聯網、人工智能……各種技術層出不窮,我們需要去監控的目標對象也一直髮生着變化。隨着多雲、混合雲架構在更多行業裏持續落地開花,容器、雲原生等各種技術的蓬勃發展,對監控系統其實也提出了新的需求。

技術更新迭代速度越來越快,很多同學難免會有一些焦慮的情緒。這種焦慮是不可避免的,我們應該做的還是要去抓住事物的本質。

針對監控這個需求,也就是說監控的核心是什麼?

監控在高度抽象之後,無非可以這麼來分:監控數據的暴露、數據的採集和傳輸、監控數據的存儲和處理……這個過程裏,包括各種優化、各種格式化處理等;最後是我們怎麼去用好監控數據,把監控數據的價值最大化,比如說我們去做報表展示、做數據分析,像前面講到的用一些DataOps、AIOps的算法、能力介入,把監控數據的價值挖掘出來。

這其實就是監控系統所要承載的功能,我們要做的就是抓住這些核心路徑裏的原理,然後掌握它,其實也就OK了。

另外,我們需要保持對這些新鮮事物的熱忱,保持對技術的敏銳,要有行業發展趨勢的感知能力。比如企業上雲,其實從行業報告來看,從去年就已經過了上雲的拐點,會有越來越多公司選擇把服務遷移到雲上;再看容器和雲原生,會有越來越多的周邊生態完善起來。我們要有這樣的感知能力,要能夠感受到這個行業發展的脈搏,然後做好相應的技術儲備,只有這樣,我們纔可能在技術的浪潮裏做到從容不迫,才能夠乘風破浪。

原文鏈接

萬字談監控:解答Zabbix與Prometheus選型疑難

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章