誰會是 Zabbix 和 Nagios 的繼任者？

標籤：

【編者按】本文根據 Dataloop.IO 的創始人兼 CEO David Gildeh 對監控工具市場的現狀分析以及對未來發展趨勢的展望，展開拓展討論。

為什麼監控還是一塌糊塗？

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

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

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

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（應用效能監控平台） 和 Browser Insight（前端效能監控平台）。老式的開源工具，例如 Cacti 和 Munin，也這個群體的傑出代表。這類工具成本更低，例如免費版本基本可以滿足要求的 Cloud Insight，對於創業公司和中小型團隊來說十分適用，可以極大地節省營運的人力和時間成本，因為部署和學習容易，相較 Zabbix 來說更靈活，又因為視覺效果出眾，在 10-40 台伺服器的中小型團隊中很受歡迎。

為 Cloud Insight Hostmap 功能的。

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

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

另一方面，小型團隊往往沒有踐行 DevOps，公司也沒有專門的營運人員，所以開發人員傾向於使用簡單、安裝方便的 SaaS 監視工具或在開發人員社區較為流行的工具，例如 [Cloud Insight](http://docs-ci.oneapm.com）（中國）、Datadog（歐美） 和 LogStash 等。當公司的伺服器數量達到 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. 微服務

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

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

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

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

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

結論

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

[1] 2015 DZone Performance & Monitoring Survey

[2] http://www.slideshare.net/adriancockcroft/software-architecture-monitoring-microservices-a-challenge

Cloud Insight 集監控、管理、計算、協作、可視化於一身，協助所有 IT 公司尤其中小型團隊，減少在系統監控上的人力和時間成本投入，更簡單的部署、更全面的資料、更好的可視化，讓營運工作更加高效、簡單。

本文轉自 OneAPM 官方部落格

誰會是 Zabbix 和 Nagios 的繼任者？