本文摘自于《Prometheus 監控技術與實戰》一書，從云計算時代的業務特點出發，探討了云計算監控的目標和挑戰，梳理了云資源監控的范圍及監控系統實現的一般方式。接著從開源監控軟件的演進出發，簡單介紹了 Zabbix、OpenTSDB 等常用監控系統。最后詳細介紹 Prometheus 云原生監控系統的產生、發展、特點，以及成功部署可獲得的運營優勢。
1
云計算監控的目標和挑戰
1.1
云計算監控目標
監控系統的目標是：提供對復雜信息系統的全面監控，反映云資源池的健康狀況和可用性情況，得到一個可控制、可預測的云環境，支持云業務安全、穩定、高效、持續地運行；同時，有效地控制管理成本，規范管理工作，實現運行管理的智能化和高效性，提高整體的維護水平；及時掌握各種資源現狀和運行信息，為決策提供支持。
監控是運維團隊眼睛的延伸。監控系統應當解決三個問題：“出問題了嗎？”“哪里出了問題？”“是什么問題？”
在《SRE：google 運維解密》一書中指出，監控系統需要有效地支持白盒監控和黑盒監控。通過白盒監控能夠了解其內部的實際運行狀態，觀察監控指標能夠預判可能出現的問題，從而對潛在的不確定因素進行優化。而黑盒監控，常見的如 HTTP 探針、TCP 探針等，可以在系統或者服務發生故障時快速通知相關人員進行處理。通過建立完善的監控體系，可以達到以下目的。
長期趨勢分析：通過對監控樣本數據的持續收集和統計，對監控指標進行長期趨勢分析。例如，通過對磁盤空間增長率的判斷，我們可以提前預測在未來什么時間節點上需要對資源進行擴容。
對照分析：兩個版本的系統運行資源使用情況的差異如何？在不同容量情況下系統的并發和負載變化如何？通過監控能夠方便地對系統進行跟蹤和比較。
告警：當系統出現或者即將出現故障時，監控系統需要迅速反應并通知管理員，從而能夠對問題進行快速處理或者提前預防問題的發生，避免對業務產生影響。
故障分析與定位：當問題發生后，需要對問題進行調查和處理。通過對比分析不同監控數據與歷史數據，能夠找到并解決根源問題。
數據可視化：通過可視化儀表盤能夠直接獲取系統的運行狀態、資源使用情況，以及服務運行狀態等直觀的信息。
網站可靠性工程師 SRE（Site Reliability Engineer）的終極責任是確保該服務可以正常運轉。為達成這個目標，SRE 定義了一套服務可靠性層級模型，需要完成開發監控系統、規劃容量、處理緊急事件、確保事故根源被跟蹤修復等一系列工作。
服務可靠性層級模型
監控系統是服務可靠性層級中的最底層。離開了監控系統，就沒有能力辨別一個系統是否在正常提供服務。沒有一套設計周全的監控體系就如同蒙著眼睛狂奔。作為一個合格的系統運維人員，需要先于用戶發現系統中存在的問題。沒有監控的支持，上層應急事件處理、事后總結/問題根因分析、測試+發布、容量規劃、軟件開發、產品設計也就沒有了根基。
1.2
云計算監控挑戰
要對基于現代基礎設施的應用系統進行監控，將面臨 DevOps 實踐和基礎架構代碼化，監控系統將會迎接若干重大挑戰。
挑戰 1：持續變更
在運維中需要監測偏離正常行為的信號，這里所說的“正常行為”是假設系統已經穩定運行了很長時間。然而，在一個大型復雜環境中，變更是常態。這些變更來自于：
云計算的彈性，使得基礎設施資源變得更靈活。
自動化的 DevOps 運維，觸發很多零散的運維操作（例如升級、重配置、備份），零散的運維、持續部署和部署實踐使得軟件變更更加頻繁。
持續變更中，監控的參數頻繁變更，監控系統參數也經常需要隨著變更。
系統基礎設施和系統本身的持續變更使得監控參數的設置變得復雜。即使向相同的虛擬機提交請求，仍然存在巨大的性能差別。這些差別來自于你無法控制的因素，如你得到的 CPU 的類型。你的監控可能需要調整以適應這種變化，或者你可以配置縮放控制器，以便用新的虛擬機來代替性能下降或提升的虛擬機。
自動化設置警報、告警和閾值。監控配置過程是另一個 DevOps 過程，應該實現自動化。當提供一臺新服務器時，應該在監控系統中自動注冊這臺服務器；當服務器停止使用時，應該自動觸發注銷流程。
挑戰 2：自下而上還是自上而下
監控的主要目的是盡可能快地發現缺陷、錯誤或小規模的故障，以便能夠盡早做出反應。我們很自然地采用了自下而上的方式進行監控：根據聚合值，低層中的錯誤和單個模塊中的錯誤，可以在它們傳播和影響到上層應用服務器或者應用本身之前被發現。這里要面臨兩個挑戰：
需要監控越來越多的模塊級別和其他低級別的內容。一個應用由多個組件組成，可能部署在上百臺服務器上，依賴于網絡和存儲組件的支持。在實際環境中，把這些監控信息相關聯并找到根源是非常困難的。
在云中，低層基礎設施和服務器之間有正常和異常的分配，例如，服務器漂移的終止操作、伸縮以及滾動升級，或者實例失效或者資源共享不穩定等，導致監控服務器非常復雜。
采取自上而下的方法來監控基于云的和高度復雜的系統是解決以上問題的一種嘗試，通過監控上層或者聚合數據，從頂層問題出發再以智能的方式深入低層數據。仍然必須收集低層數據，但不會系統化地監控錯誤。這種方式也面臨挑戰：
發現問題時可能為時已晚。當在上層注意到有錯誤時，阻止影響的擴大可能已經來不及了。
如何深入到低層數據。現代分布式系統有內置的容錯機制來掩蓋故障和錯誤，防止在系統層面出現問題直接影響用戶體驗，因此，檢測到上層問題距離低層根本故障原因出現，可能已經過去相當長的一段時間了。
從最初發生故障到擴散到整個系統并變得明顯，可能需要經過很長一段時間。不能簡單地依賴上層錯誤檢測的時間戳，也不能假設與原始問題相關的指標和日志還仍然存在，很可能隨著網絡的僵死一起消失。
挑戰 3：復雜的微服務架構
在云環境中監控系統面臨另一個挑戰是對微服務架構的監控。每個微服務組件可能是一個獨立部署，每個外部請求都可能要穿越大量內部服務才能得到響應。如果一個服務響應變慢，那么整個響應時間就會拉長。在微服務中識別并修復響應慢的節點，對于偶爾發生的性能問題。很難做到盡早確定。在具有大量節點的微服務架構中，如何在這些仍然工作的節點中找出響應慢的節點？如何定義“慢”？如何選擇合適的閾值？
挑戰 4：大容量的分布式數據
在大型系統中，監控每件事情會引入性能、傳輸和存儲方面的巨大開銷。一個大型系統很容易生成數百萬個事件以及指標數據，每秒都會產生大量的日志。處理龐大的數據會面臨如下挑戰：
在時間間隔很小的范圍內收集指標，性能開銷是巨大的。根據系統當前的狀態，運維應該使用變化的和可調節的時間間隔，而不是一些固定的時間間隔。如有產生異常的跡象或者當出現了一個偶爾發生的操作時，能用細粒度監控；當情況解決或操作結束時再返回到大的時間間隔。
應該使用現代分布式日志或消息系統來進行數據收集，而不是自己構建一個。分布式日志系統（如 Logstash）能收集所有種類的日志，并在數據運輸前進行大量的本地處理。這種類型的系統允許你減少性能開銷、消除噪聲，甚至在本地識別錯誤。
應該使用高級機器學習算法來處理噪聲、不一致性和大容量數據。
2
云計算監控的范圍和架構
2.1
監控管理的范圍
在《The Art of Monitoring》一書中，James Turnbull 描述了一種現代的監控體系架構，由大型互聯網公司（例如谷歌、亞馬遜、Facebook 等）的運維工程師開發和使用。該架構通常是由很多開源工具構成的，例如 NagIOS 和 Zenoss 等，用這些工具定制和部署所能達到的監控規模是同類商業軟件很難實現的。
在業務邏輯、應用程序和運行環境層級上收集數據，在每一層，以事件、日志和指標為監控對象。可以在所有服務器上使用特定文件來存儲日志，但最好將所有日志發送到公共日志服務中，這樣更利于聚合、查詢和清除。此外，在應用程序棧的所有層級中收集指標，能更好地了解系統的活動狀態。在操作系統級別，可以收集 CPU、內存、磁盤或網絡的使用率等。
事件路由器負責事件的存儲和轉發：支持監控可視化、趨勢分析、告警、異常檢測等。通過采集、存儲和聚合所有監控信息，能實現更深入的分析和健康檢查。事件路由器用于存儲與服務（和它們支持的應用程序與運行環境）有關的配置，可以實現基于閾值的告警和健康檢查。
監控體系架構
（來源：The Art of Monitoring，James Turnbull，June 11，2016）
監控管理的范圍包括構成資源服務的所有 IT 資源，云計算環境下的監控對象除了包括傳統的資源，還包括對虛擬化資源的監控。
2.2
監控系統的基本架構
被監控的系統可以是獨立的應用程序或服務的集合，也可以是單獨的應用程序。如果系統主動地提供了被監控的數據，那么監控是入侵式的且影響系統設計；如果系統不主動提供被監控的數據，那么監控是非入侵的。外部系統可以通過健康檢查、性能或事務監控來監控系統或者應用級別的狀態。
通過代理或者非代理收集的數據最后都發送到監控中心數據庫中。一般來說這個中心數據庫是分布式的，是邏輯上的中心而不是物理上的中心。數據從初始收集到中心數據庫的每一步都可以進行過濾和聚合。判斷過濾和聚合量的條件包括：生產數據的大小、本地節點的潛在故障和必要通信的傳輸粒度。因為本地節點可能發生故障且數據變得不可用，所以從本地節點獲取數據并監控是重要的。將所有數據直接發送到中心數據庫可能會導致網絡阻塞，因此，在設計監控架構時，選擇從本地節點到中心數據庫之間的中間步驟以及在每一步過濾和聚合數據是重要的架構決策。
監控系統的基本架構
一旦監控數據被收集起來，就可以做很多事情。可以配置報警來觸發警告以通知運維人員或其他系統。使用圖形化和儀表盤，可以將系統狀態的變化可視化地展現給運維人員。監控系統也允許運維人員得到詳細的監控數據和日志，這對錯誤診斷、根本原因分析和確定解決問題的最佳方案具有重要的作用。
由于監控數據的使用需求不斷增長，所以很多公司開始對監控系統和整體應用系統采用統一的日志和以指標為中心的“發布-訂閱”架構。越來越多的數據類型，包括非傳統日志和指標數據，都放入統一的數據庫中，各種其他系統（不管是否與監控相關）都可以訂閱其感興趣的數據。
3
百花齊放的開源監控軟件工具
前面簡單介紹了監控系統的基本架構，與之相關的解決方案已經有很多。
3.1
監控系統成熟度
監控系統有 4 個發展階段，也是度量監控系統的方法，以及對監控改進的指南，可用于評估當前監控系統的成熟度級別以及可采用的改進步驟。第 1 級是組件監控，可以反映每個組件的狀態并根據策略進行警報通知。第 2 級是對各層級進行監控，從各個層級、角度收集運行信息，包括各種指標度量值、輸出日志、服務追蹤信息等。第 3 級不僅查看所有的狀態、事件和度量，還查看依賴關系并跟蹤動態變更情況，數據用可視化工具展現，以實時洞察整個系統的總體運行情況。第 4 級是智能化，是更遠大愿景的一部分，能夠在發生故障之前發送警報，通過擴展或重路由服務來實現自我治愈、異常檢測等。
監控系統成熟度
當從監控成熟度第 1 級晉升到第 2 級，將獲得對系統更深入的洞察力，將更好地理解服務的可用性和性能。從第 2 級到第 3 級，將可以在整個 IT 系統中獲得全棧的可見性，并精確地理解業務流程、應用程序和基礎架構之間的依賴關系。無論是云計算、應用程序、還是基礎設施，都可以采用更加主動的監控方法來支持數字企業的需求。最后進入第 4 級時，將獲得預測分析能力，這將幫助企業預測可能發生的問題、指出可能的原因，IT 維護更智能、敏捷、高效。
對于監控系統軟件，開源的解決方案有流量監控（MRTG、Cacti、Smokeping、Graphite 等）和性能告警（Nagios、Zabbix、Zenoss Core、Ganglia、OpenTSDB 等），每種軟件都有自己的特點和功能，有各自的側重點和目標，然而，在設計理念和實現方法上都大同小異，具有共同特征。例如，都具有采集數據、分析展示、告警以及簡單的故障自動處理等環節。下面簡單介紹監控系統發展演進過程中出現的兩個最常用的開源軟件。
3.2
Zabbix
Zabbix 是一個基于 Web 界面的提供分布式系統監視以及網絡監視功能的企業級開源解決方案。
Zabbix 工作數據流
Zabbix 能監視各種網絡參數，保證服務系統的安全運營，并提供良好的通知機制使系統管理員能夠快速定位/解決存在的各種問題。Zabbix 由兩部分構成—Zabbix server 與可選組件 Zabbix agent。Zabbix server 可以單獨監視遠程服務器的服務狀態；同時也可以與 Zabbix agent 配合，可以輪詢 Zabbix agent 主動接收監視數據，還可被動接收 Zabbix agent 發送的數據。另外，Zabbix server 支持 SNMP、IPMI、JMX、Telnet、SSH 等多種協議，將采集到的數據存放到數據庫，然后對其進行分析整理，若達到條件觸發則告警。Zabbix 支持二次開發，其靈活的擴展性和豐富的功能是其他監控系統所不能比擬的，相對來說，它的總體功能做得非常優秀。
3.3
OpenTSDB
OpenTSDB 通過 HBase 存儲所有的時序（無須采樣）來構建一個分布式、可伸縮的時間序列數據庫。它支持秒級數據采集所有指標，支持永久存儲，可以做容量規劃，并可很容易地接入現有的報警系統。OpenTSDB 可以從大規模的集群（包括集群中的網絡設備、操作系統、應用程序）中獲取相應的指標，并進行存儲、索引以及服務，從而使這些數據更容易被人理解，如 Web 化、圖形化等。
在對實時性要求比較高的場景中，OpenTSDB 是一個很好的選擇。它支持秒級的數據采集，這是之前其他監控系統很難實現的。因得益于其存儲系統的選擇，它支持大數據分析，在大型的基礎設施監控中也得到較為廣泛的使用。
OpenTSDB 的數據流圖
4
Prometheus 監控系統
Prometheus（普羅米修斯，有時簡稱 Prom）是一個開源的容器和微服務監測和預警工具集。Prometheus 是為提供豐富度量指標、又不影響目標系統性能而設計的、高度可定制的云原生監控系統。Prometheus 已經成為主流開源的監測工具，受到了廣大用戶的歡迎，對于那些嚴重依賴容器和微服務的人來說，Prometheus 是他們最佳的選擇。Prometheus 適用于各種規模、各個行業。Prometheus 已經具備完整的生態，包括與監控密切關聯的報警系統，也非常方便與第三方的監控系統集成，成為監控報警平臺。Prometheus 為現代 DevOps 工作流提供了關鍵組件，監視云原生應用程序和基礎設施，并與 CNCF 另一個流行的項目 Kubernetes 完美協同。
4.1
應運而生，茁壯成長
1. Prometheus 簡史
Prometheus 是由 SoundCloud 開發的開源監控報警系統和時序數據庫（Time Series Database，TSDB）。Prometheus 受 Google 的 Brogmon 監控系統的啟發（Kubernetes 是從 Google 的 Brog 系統演變而來的），從 2012 年開始由前 Google 工程師在 SoundCloud 以開源軟件的形式進行研發，并且于 2015 年初對外發布早期版本。2016 年 5 月繼 Kubernetes 之后成為第二個正式加入 CNCF 基金會的項目，同年 6 月正式發布 1.0 版本。2017 年底發布了基于全新存儲層的 2.0 版本，能更好地與容器平臺、云平臺配合。2018 年 8 月，Prometheus 已成為 CNCF 歷史上第二個“畢業”的項目。
Prometheus 歷史故事
從前，在加利福尼亞州山景城有一家公司，名為 Google。該公司經營著一系列產品，最著名的是廣告 ERM 搜索引擎平臺。為了運行這些不同的產品，公司構建了一個名為 Borg 的平臺。Borg 系統是“一個集群管理器，它運行數十萬個作業，來自數千個不同的應用程序跨越多個集群，每個集群都有多達數萬臺機器”。開源容器管理器 Kubernetes 的大部分遺產都歸功于 Borg。Borg 在 Google 部署后不久，人們就意識到，若要應對這種復雜性，則需要一個類似功能的監控系統。Google 建立了這個系統并命名為 Borgmon。（備注：Borg 和 Borgmon 都從未公開過。直到最近，人們才了解它們是如何工作的）。
Prometheus 的靈感來自 Google 的 Borgmon。Matt T. Proud（前 Google 員工）最初將其作為研究項目開發的。在 Proud 加入 SoundCloud 之后，他與另一位工程師 Julius Volz 合作，開發 Prometheus。后來其他開發者也加入了進來，并在 SoundCloud 內部繼續研發，最終在 2015 年 1 月發布了公開版本。
與 Borgmon 一樣，Prometheus 主要對基于云和基于容器的動態微服務、服務和應用程序提供近實時監控。SoundCloud 是這些架構模式的較早使用者。現在，Prometheus 被很多公司采納，通常用于類似的監控，但也用于監控更傳統的體系結構。
2. 成為開源社區熱點、監控主流
Prometheus 使用開源的 Go 語言編寫，并且在 Apache 2.0 許可下授權，該項目有著非常活躍的開發者和用戶社區。現在已經成為一個獨立的開源項目核，并且獨立于任何公司。
Prometheus 作為新一代的云原生監控系統，目前 GitHub 上已超過 2 萬顆星。超過 650 多位貢獻者參與到 Prometheus 的研發工作上，并且有 120 多項的第三方集成。從 2012 年 11 月開始至今，Prometheus 持續成為監控領域的熱點。
在 2016 年之后，Prometheus 綜合排名持續提升，且速度最快。Prometheus 很有活力，開發者可以自己寫導出器（exporter），每個監控參數都可控，并能很快定位到問題。
3. Prometheus 設計理念
Prometheus 能抓取或拉取應用程序導出的時間序列數據。應用程序本身經常通過客戶端函數庫或導出器（導出程序，作為 HTTP 端點）呈現出時間序列數據。導出器和客戶端函數庫可用于多種語言、框架和開源應用程序，例如用于 Apache、Nginx 等 Web 服務器以及 MySQL 等數據庫。
Prometheus 關注的是近期發生的事情，而不是跟蹤數周或數月的數據。因為大多數監視查詢和警報都是從最近的（通常不到一天的）數據生成的。Prometheus 假設用戶試圖修復的問題是最近的，因此最有用的數據是最近的數據。Prometheus 監控數據默認保留 15 天。
Prometheus 設計理念
Prometheus 還有一個推送網關，可以用來接收少量數據，例如獲取不能被直接抓取的監控目標的指標數據。
4.2
功能完善、監控所有層級指標
傳統的監控解決方案需要多種監控工具組合。
傳統復雜的多種監控手段組合
和其他監控系統相比，Prometheus 功能強大，可以監控所有層級的指標（見表 1），簡化了監控復雜度。
表 1 Prometheus 監控所有層級指標
Prometheus 監控解決方案，簡化系統部署
4.3
開放、高效、易用的完整解決方案
Prometheus 是一個開源的完整監控解決方案，對傳統監控系統的測試和告警模型進行了徹底的顛覆，形成了基于集中化的規則計算、統一分析和告警管理的新模型。相比于傳統監控系統，Prometheus 具有大量優點。
1. 易管理性
Prometheus 核心部分只有一個單獨的二進制文件，不存在任何的第三方依賴（數據庫、緩存等）。唯一需要的就是本地磁盤，因此不會有潛在關聯的故障風險。Prometheus 基于 Pull 模型的架構方式，可以在任何環境（本地主機、開發環境、測試環境等）搭建監控系統。對于一些復雜的情況，還可以結合 Prometheus 的服務發現能力動態地管理監控目標。
2. 更契合的架構
采用 Push 模型的監控系統，客戶端需要在服務端上進行注冊及監控數據推送；而在 Prometheus 采用的 Pull 模型架構里，具體的數據拉取行為是完全由服務端決定的。服務端可以基于某種服務發現機制自動發現監控對象，多個服務端之間能夠通過集群機制實現數據分片。Push 模型想要實現相同的功能，通常需要客戶端進行配合，而這在微服務架構里是比較困難的。Prometheus 建議用戶監控服務的內部狀態，可以基于 Prometheus 提供的豐富 Client 庫，很容易地在應用程序中添加支持 Prometheus 的監控指標，用戶可以獲取服務和應用內部真正的運行狀態信息。
3. 靈活的數據模型
在 Prometheus 里，監控數據是由值、時間戳和標簽表組成的，其中，監控數據的源信息完全記錄在標簽表里；同時，Prometheus 支持在監控數據采集階段對監控數據的標簽表進行修改，這使其具備強大的擴展能力。
4. 良好的性能，強大的查詢能力
在監控系統中大量的監控任務必然產生大量的數據，Prometheus 不僅可以高效地處理這些數據，還提供了 PromBench 基準測試。在硬件資源滿足的情況下，對于單實例 Prometheus 可以處理數以百萬的監控指標以及數十萬個數據點。
Prometheus 內置了一套強大的數據查詢語言 PromQL。PromQL 提供了大量的數據計算函數，大部分情況下用戶都可以直接通過 PromQL 從 Prometheus 里查詢到需要的聚合數據。PromQL 也可應用于數據可視化（如 Grafana）以及事件告警。
5. 可擴展性
Prometheus 架構非常簡單，可以在每個數據中心、每個團隊中運行獨立的 Prometheus 服務器實例。對于大型環境，Prometheus 支持聯邦（federation）集群方式，把多個 Prometheus 實例集成單個邏輯集群。當單個 Prometheus 服務器實例處理的任務量過大時，通過功能分區（sharding）結合聯邦集群可以對其進行擴展。
6. 健全的生態，開放、易于與第三方系統集成
使用 Prometheus 可以快速搭建監控服務，并且可以方便地在應用程序中進行集成。目前已支持 JAVA、JMX、Python、Go、Ruby、.Net、Node.js 等語言的客戶端軟件開發工具（SDK），基于這些 SDK 可以很容易地將應用程序納入到 Prometheus 的監控中，或者開發自己的監控數據收集程序。同時，Prometheus 還支持與其他監控系統進行集成，如 Graphite、Statsd、Collected、Scollector、muini、Nagios 等。甚至可以在不使用 Prometheus 的情況下，采用 Prometheus 的 client library 使應用程序支持監控數據采集。
Prometheus 社區提供了大量第三方實現的監控數據采集支持，如 JMX、CloudWatch、EC2、MySQL、PostgresSQL、Haskell、Bash、SNMP、Consul、Haproxy、Mesos、Bind、CouchDB、Django、Memcached、RabbitMQ、redis、RethinkDB、Rsyslog 等。
7. 可視化
Prometheus 服務器中自帶了一個 Prometheus UI，通過這個 UI 可以方便地對數據進行查詢，并且支持直接以圖形化的形式展示數據。最新的 Grafana 可視化工具已經完美支持 Prometheus，基于 Grafana 可以創建精美、炫酷的監控視圖。基于 Prometheus 提供的 API，還可以實現自己的監控可視化 UI。
Prometheus 雖然具有上述優勢，但其仍然無法滿足微服務監控的所有需求，具體的不足之處有：
• 僅適用于監控維度，要用于日志監控、分布式追蹤等還有待完善。
• 告警規則和告警聯系人僅支持靜態文件配置。
• 原生支持的數據聚合函數有限，且不支持擴展。
想對監控 Prometheus 技術有更深入的了解，推薦閱讀《Prometheus 監控技術與實戰》。
