誰會是 Zabbix 和 Nagios 的繼任者？

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

####爲何監控仍是一塌糊塗？

爲了調研市場，從而作出更好的監控工具，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（應用性能監控平臺） 和 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. 微服務

在線服務的關鍵趨勢是微服務部署模型，其中包括獨立的跨職能的開發團隊在生產過程當中部署並支持本身的服務。這一戰略使一個大型的複雜應用程序具有高度的可伸縮性。然而，這大大增長了 DevOps/運維團隊須要支持的服務器和服務數量，因此只有在出現問題時，開發團隊即變爲一線支持，這種部署模型才管用。

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

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

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

所以，新的監控模式和工具成爲需求，須要新的專門針對微服務的監控工具，以便運維和開發團隊圍繞同一性能數據源開展合做，而不是開發人員使用本身的工具(好比 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 官方博客