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

 

    Zabbix與Prometheus     讀完本文，你將收穫    

1. 二者適用於多大規模的監控場景？超過5000以上監控節點時怎麼辦？高可用怎麼解決？

2. 二者怎麼解決存儲問題？對於監控信息是否有歷史存儲和分析，能從歷史信息中挖掘到哪些有價值的信息？

3. 二者怎麼應對告警風暴和誤報？

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

5. 監控大屏是怎麼設計的？

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

7. 二者在配合使用時，應該怎麼分工？怎麼落地？

8. 若是已經部署了Zabbix，怎麼平穩過渡到Prometheus？

9. 分佈式鏈路的可觀測性和端到端診斷怎麼作？

10. 大規模場景下，二者的性能和成本哪一個比較低？

 

監控，爲何總讓咱們頭痛

 

監控一直都是運維工做中不可或缺的部分，一個高效、契合的監控系統是服務賴以健康穩定的基石。隨着業務規模的增加、技術的發展、行業的變革，企業對用戶體驗愈來愈重視，監控的需求發生着突飛猛進的變化，相應的監控工具和解決方案也層出不窮。其中，Zabbix和Prometheus就是兩款很是典型的監控工具，應用頗爲普遍。

 

提及來，監控在不一樣的團隊和公司之間，可能會存在各類差別化的需求。如何基於開源產品打造一個符合本身業務場景的監控體系，而且持續迭代？這成爲了你們沒法繞開的課題。

 

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

 

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

 

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

 

Q1：Zabbix和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這種方式，來把高可用維護起來。

 

Q2：Zabbix和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分鐘一個點。就用這樣的方式，把這個數據量級減少，而後以此來作存儲問題的優化。

 

Q3：Zabbix和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：Zabbix和Prometheus在配合使用時，應該怎麼分工？怎麼落地？

 

蔡翔華：其實從場景來講，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     讀完本文，你將收穫    

1. 二者適用於多大規模的監控場景？超過5000以上監控節點時怎麼辦？高可用怎麼解決？

2. 二者怎麼解決存儲問題？對於監控信息是否有歷史存儲和分析，能從歷史信息中挖掘到哪些有價值的信息？

3. 二者怎麼應對告警風暴和誤報？

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

5. 監控大屏是怎麼設計的？

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

7. 二者在配合使用時，應該怎麼分工？怎麼落地？

8. 若是已經部署了Zabbix，怎麼平穩過渡到Prometheus？

9. 分佈式鏈路的可觀測性和端到端診斷怎麼作？

10. 大規模場景下，二者的性能和成本哪一個比較低？

 

監控，爲何總讓咱們頭痛

 

監控一直都是運維工做中不可或缺的部分，一個高效、契合的監控系統是服務賴以健康穩定的基石。隨着業務規模的增加、技術的發展、行業的變革，企業對用戶體驗愈來愈重視，監控的需求發生着突飛猛進的變化，相應的監控工具和解決方案也層出不窮。其中，Zabbix和Prometheus就是兩款很是典型的監控工具，應用頗爲普遍。

 

提及來，監控在不一樣的團隊和公司之間，可能會存在各類差別化的需求。如何基於開源產品打造一個符合本身業務場景的監控體系，而且持續迭代？這成爲了你們沒法繞開的課題。

 

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

 

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

 

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

 

Q1：Zabbix和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這種方式，來把高可用維護起來。

 

Q2：Zabbix和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分鐘一個點。就用這樣的方式，把這個數據量級減少，而後以此來作存儲問題的優化。

 

Q3：Zabbix和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：Zabbix和Prometheus在配合使用時，應該怎麼分工？怎麼落地？

 

蔡翔華：其實從場景來講，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了。

 

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