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