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