本文轉載自：https://blog.csdn.net/moonpure/article/details/78633668

為了調研市場，從而做出更好的監控工具，David Gildeh 曾採訪了超過60家歐美線上服務提供廠商，大到英國廣播公司(BBC)這類線上服務巨擘，小到倫敦和美國的小型創業公司。發現大多數服務都是執行在公共雲基礎設施之上(像 AWS)，並且採取 DevOps 實踐方案。

越來越多的企業使用雲服務，和嘗試建立 DevOps 環境，雲監控已經成為一種剛需。

想開發出更好的監控工具，我們必須先回答倆個問題：

1. 企業目前在用的監控工具是什麼，他們有多少伺服器；

2. 這些監控工具為他們解決了什麼問題，與伺服器數量和部署環境有何關係。

在 David Gildeh 的調查結果中，我們瞭解到兩件事。

• 首先，在某些方面，監測仍然很糟糕，這一點將在下文進行更詳細的解釋。

• 第二個方面，由於越來越多的公司開始轉向微服務（microservices），監控仍然是個難題。

企業正在使用哪些監控工具？

雖然自 2011 年以來，市場上也湧現了很多新工具，但是很多「老牌」的開源工具，比如 Nagios、Zabbix 等仍然在市場中佔據主導地位。採訪發現，70%的公司仍在使用這些傳統工具進行核心系統監控和告警(見圖1)。來自 DZone 的資料顯示，該網站的企業級開發使用者中，43%都使用過 Nagios、Zabbix 或者 Ichinga。此外，Nagios 是最受歡迎的監控工具之一，甚至佔據了29%的市場份額[1]。

資料統計，大約 70% 的公司會同時使用多個監控工具，很多公司都是使用兩個或兩個以上的產品。當然，在歐美市場中，Nagios 和 Graphite 配置是最常見的。據小編了解，國內擁有大量使用 Zabbix+Grafana 的使用者。而對於一些付費的效能監控工具，如 New Relic，出於價格因素考慮，大多數使用者都不願意從免費版升級到付費版本。

不過，市場上還存在很多「新潮」的監控工具 ，面向的使用者主要是創業公司，這類工具包括一些較新的 SaaS 監控工具，比如 Cloud Insight(系統監控平臺)、Application Insight（應用效能監控平臺）

上圖為 Cloud Insight Hostmap 功能的效果圖。

企業有多少伺服器被監控？

如果檢視工具使用情況和公司管理的伺服器數量(規模從少於20臺伺服器的初創公司的服務，到多於1000臺伺服器的大型線上服務)，會發現老式的開源工具（比如 Nagios）以及付費的本地化工具，往往在服務規模較大的公司佔據較大比重，而服務規模較小的公司則更願意使用以開發為重點的工具，例如 Graphite，LogStash 和 OneAPM 等。

另一方面，小型團隊往往沒有踐行 DevOps，公司也沒有專門的運維人員，所以開發者傾向於使用簡單、安裝方便的 SaaS 監視工具或在開發者社群較為流行的工具，例如 Cloud Insight 等。當公司的伺服器數量達到 50 到 100 之間的某個臨界點時，他們往往會有能力引進 DevOps/運維人員或團隊，繼而開始使用歷經時間考驗、擁有廣泛使用者基礎的監視工具，像 Nagios 和 Zabbix。

主要趨勢

基於接受採訪的60多個線上服務公司對監控策略的意見，David Gildeh 總結了如下四個主要趨勢。

1. 構建和擴張

78%的線上服務執行著自己的開源監控解決方案，許多公司會花4到6個月時間，使用開源的元件構建監控解決方案，然後調優到相應的工作環境。關鍵問題是許多工具最初是在10到15年前設計的，遠遠早於雲架構、DevOps 和微服務（microservices）的出現。所以，企業需要耗費大量的時間調整這些老式工具，使它們兼容於當今的動態環境(十分累人)。

企業完成構建並優化監測體系之後，隨著業務的增長，他們需要更多的時間來修改監測系統，以使其處理日益增長的資料量。例如，一個大型的線上服務，在 AWS 上有超過1000個例項，後臺 MySQL 資料庫 2Tb 的資料填滿後，Zabbix 伺服器不幸宕機。最終，他們只是不斷重啟資料庫，卻不嘗試為 Zabbix 擴容。

2. 垃圾警報

接受採訪的公司都在抱怨同一個問題——過度的告警提醒。很明顯，所有工具，即便是聲稱具備先進的機器學習演算法的監控工具，卻無法解決告警疲勞問題。由於企業不斷增加伺服器，在持續變化的雲環境上執行微服務，該問題只會進一步惡化。儘管許多企業在營銷時大放厥詞，但在實踐中，這些用於異常檢測或告警預測的機器學習演算法並沒有真的如人們所願。這意味著，想要這些工具在監測中自動過濾掉告警噪聲，還有很長的路要走。

在某個公司，他們每天會收到大約5000封郵件提醒。這樣龐大的郵件數量使得告警逐漸淪為噪音，大多數團隊只會把這些告警過濾到一個資料夾中或者乾脆自動刪除告警。

3. 資料孤島

我們採訪的很多公司都在收集實時資料。這些資料來源包括業務指標，如註冊、付款的數量，或收入資料，團隊用這些資料來進一步瞭解公司的服務情況。然而，他們所使用的大多數監視工具，都有可用性差、UI 過時等問題，所以所收集的資料是孤立的，不能為運營團隊所用。所以對其他利益相關者來說，也不太容易瞭解這些實時資料的價值。

但也有一些服務通過建立自定義儀表板，在辦公室的電視中進行展示或通過 URL 進行共享，來解決資料孤島問題。比如 Cloud Insight，採取「DevOps +協作」的理念，擁有 API 和 SDK 功能，可以自定義儀表盤上傳包括效能資料、業務資料、運營資料在內的種種資料，通過多種形式（折現圖、柱圖、餅圖…）進行一體化實時展示。而即將推出的儀表盤分享功能將支援儀表盤實時共享。這幾乎是一個共識，如果公司裡的監測資料很容易共享，在不同團隊的協作過程中，監控工具就能體現其價值，譬如確定亟待改進的區域，實現跨業務間的實時效能可見性等。

這會不會是系統監控的下一個趨勢？我們拭目以待。

4. 微服務

線上服務的關鍵趨勢是微服務部署模型，其中包括獨立的跨職能的開發團隊在生產過程中部署並支援自己的服務。這一戰略使一個大型的複雜應用程式具備高度的可伸縮性。然而，這大大增加了 DevOps/運維團隊需要支援的伺服器和服務數量，所以只有在出現問題時，開發團隊即變為一線支援，這種部署模型才管用。

在本模型中，運維人員成為一個「平臺」團隊，為開發團隊提供通用的工具和流程。這一運維提供的平臺包括自助監測，即開發者必須能夠自主新增監測，並建立自己的儀表板和告警。

對於那些易於共享監測資料的公司，監控工具變成了更具價值的工具。

跟上微服務模型中的高速部署以及瞬息萬變的例項，對於老式的監視工具來說是一項巨大的挑戰。同時，對 Zabbix 和 Nagios 本身來說，實現各種服務間複雜任務流的視覺化並處理高度動態的擴充套件，也非易事。雪上加霜的是，顯然，目前的監控工具並不是圍繞微服務模型設計的，並且大多數的可用性都比較差，在運維團隊之外的採用率也較低。

因此，新的監控模式和工具成為需求，需要新的專門針對微服務的監控工具，以便運維和開發團隊圍繞同一性能資料來源開展合作，而不是開發人員使用自己的工具(比如 New Relic 或 OneAPM)，而運維也用自己的工具(比如 Nagios 和 Zabbix)，互為孤島。

結論

在「#monitoringsucks」事件之後的這四年，出現了種類繁多的監視工具。但 David Gildeh 的研究和我們自己的調研通通表明，許多公司仍在監控領域苦苦掙扎。我們認為，主要原因在於很多新的監控工具往往只重視技術方面的監控，還不足以推動在運維團隊以外的採用。而我們相信，連線開發、運維甚至其他部門，通過可靠的監控讓企業中的每個人都可以基於資料做出決策，是未來 IT 團隊選擇監控產品的趨勢。