第一部分概述第1章云計算時代的監控系統1.2云計算監控的目標和挑戰1.6本章小結第2章Prometheus基本概念及部署2.2Prometheus快速部署2.5本章小結第二部分Prometheus技術基礎第3章Exporter3.5Prometheus之黑盒監控第4章服務發現4.1基于文件的服務發現4.2基于Consul的服務發現4.4Relabelling4.5本章小結5.1時序數據庫5.3PromQL聚合操作5.6PromQL查詢分析5.7本章小結第6章告警處理6.7本章小結第7章可視化7.7本章小結第三部分監控綜合實踐第9章OpenStack云計算監控9.2OpenStackExp9.4本章小結第10章Docker容器監控第11章Kubernetes監控11.3通過Operator方式部署Prometheus11.5監控對象11.8本章小結第12章微服務及業務監控12.4在SpringBoot自定義Metrics第13章日志監控的設計與實現13.3Fluentd日志監控第一部分概述■第1章云計算時代的監控系統■第2章Prometheus基本概念及部署第1章云計算時代的監控系統過去的十年里，我國云計算、大數據、人工智能等IT技術迅速發展，數字技術呈指數級增長，技術創新和商業創新呈現大爆炸的形態。容器、微服務、DevOps等技術不斷推動著云計算的變革。云計算的應用已經深入到政府、金融、工業、交通、物流、醫療健康等傳統行業。隨之而來的挑戰是如何管理好這些新型的IT基礎環境，特別是如何實時掌握云環境下業務的運行狀態及達到服務保障等級。企業需要考慮：本章將從云計算時代的應用特點入手，分析云計算環境下監控面臨的挑戰，提出需要什么樣的監控。接著簡要介紹監控的成熟度，并回顧開源監控軟件的演進歷史。最后重點介紹順應云時代的云原生監控系統——Prometheus誕生及其解決方案的特點。1.1云計算時代的應用系統云計算時代的應用系統首先是大量企業通過“IT云化”實現數字轉型，之后達到敏捷1.1.1企業“IT云化”實現數字化轉型中國已是最大的數字化消費市場，崛起的新興數字行業、企業在金融服務、通訊、出行和物流等領域對傳統的市場規則和經營方式形成巨大沖擊，數字化所帶來的新理念和商業·企業“IT云化”實現數字化轉型是時代發展之大勢，發展空間云計算發展已步入第二個十年，全球云計算市場趨于穩定增長，我國云計算市場處于高速增長階段。中國信息通信研究院在2019年7月發布的《2019年云計算發展白皮書》中指出：2018年我國云計算整體市場規模達962.8億元，增速39.2%,我國公有云市場將保持50%以上增長，預計2018～2022年仍將保持快速增長態勢，到2022年公有云市場規模將達到1731億元，私有云市場規模將達到1172億元。企業在數字化轉型過程中，要以最快的速度應對IT新環境、用戶需求以及競爭對手帶來的挑戰。2014年，Gartner就提出了“雙模IT”的理念——一個維穩一個圖新，雙軌部分。第一個部分即為傳統的IT架構，傾向于按部就班的工作，確保企業業務平穩運行；第二個部分則采用了敏捷開發、快速迭代的方式，應對最新的挑戰。1.1.2云計算時代的IT架構特點企業使用IT架構的歷史，從最初大型機的集中式計算架構到以服務方式提供計算能力的云架構，走過了幾十年的歷程，每次IT系統升級的變革，都帶動了生產力和企業管理的變革與發展。企業IT系統的發展歷史如圖1-1所示。從20世紀60年代中期開始，一些企業開始使用大型機。大型機的使用門檻和成本很高，只有極少數企業能夠使用。從20世紀80年代開始，PC和小型機出現，企業通過購買硬件獲得計算和存儲能力，但存在架構不靈活、資源利用率不高、易被廠家鎖定而不可控等問題。從20世紀90年代中期開始，企業開始在互聯網數據中心托管和租用硬件，風、火、水、電由數據中心提供和保障，但是計算設備以及計算系統還需要企業自身提供，計算能力依然被少數大企業占有。從2000年開始出現去IOE技術浪潮，通用x86服務器成了IT基礎架構的絕對主流技術。現已進入云架構時代，以服務方式提供計算能力，按需獲取，降低使用門檻，使計算成為像水電一樣的社會公共基礎設施。近幾年隨著軟件的敏捷開發、持續支付、DevOps理論的發展和實踐，以及基于Docker等輕量級容器部署應用和服務的成熟，微服務架構日漸流行，已經發展成為應用架構的未來演進方向。通過服務的原子化拆分，微服務的獨立打包、部署和升級，可以使小團隊敏捷交付，應用的交付周期將縮短，運營成本也將進一步大幅下降。最新出現的函數計算更可免去管理底層基礎架構的煩擾，讓研發更專注于業務功能設計和持續交付。容器PC和小型機數據中心靜態應用和架構復雜應用復雜應用t客戶端服務器架構架構圖1-1企業IT系統的發展歷史1.1.3云計算時代的IT管理變革云架構的彈性帶來資源的集約化，實現按需使用、按需付費以及高質量的專業運維帶來了計算的服務化。通過IT集中式架構向分布式云架構的轉型優化，能夠支撐高并發、高性能的架構需求，使企業能夠放心地擁抱互聯網，能夠進行基于互聯網、大數據的業務創新，也為IT管理帶來全新的變化。1.企業IT投入模式改變在傳統的IT投入模式下，基礎設施(機房、電力、帶寬、主機、存儲、網絡、數據庫、中間件)的投入占比最大，服務器運維人工成本次之，應用開發的投入占比最小。上云后，投入比例正好相反，基礎設施租用成本最少，運維的人工成本也將大量下降，這樣可以把更多的資金投入到業務開發上面，企業可以快速滿足業務的需求。企業遷云前后投入的變化如圖1-2所示。2.IT人員能力要求的變化云計算時代對IT人員能力的要求也將發生變化。傳統IT環境中人員更關注底層基礎設施的運維、項目管理，對業務需求的理解和響應比較被動。云計算中IT人員需要更關注業務的需求，探索新的業務模式，主動發現客戶需求，尋找新的技術和解決方案，而不僅僅關注底層平臺的運維和資源管理。比如，以往IT人員遇到一個系統的問題，在解決問題的同時往往要搞清楚問題發生的根本原因是什么,以避免再次發生類似的問題。在云計算環境下，這種思路發生了根本性改變，“創建比修復更容易”,只需要迅速下線或釋放有問題的資源，同時開通相對應的新資源。企業IT人員需要做的是準備好問題發生時的預案并有效執行，至于問題產生的根因，可以留給云計算服務商的工程師去思考和研究。應用系統開發費應用系統開發費人工成本云基礎設施租開發費IT廠商服務費運維人工成本投入基礎設施建設機房/電力/帶寬數據庫/中間件圖1-2企業遷云前后投入的變化3.關注用戶體驗和業務指標如果沒能詳細了解服務中各種行為的重要程度，不去度量這些行為的正確性，就無法正確維護這個應用系統，更不要說保障系統可靠、穩定地運行了。那么,不管是對外的服務，還是內部API,都需要制定一個針對用戶的服務質量目標，并且努力達到這個質量目標。在這個過程中，需要利用一些主觀判斷結合過去的經驗以及對于服務的理解來定義一些服務質量指標(SLI)、服務質量目標(SLO),以及服務質量協議(SLA)。這三項分別是指該服務最重要的一些基礎指標，這些指標的預期值，以及當指標不符合預期時的應對計劃。事先選擇合適的指標有助于在故障發生時幫助維護團隊更好地進行決策，同時也為維護團隊判斷系統是否正常工作提供幫助。評估是否違反SLA,如果違反就升級走流程。這樣既靈活，也有章可循。如果開發團隊能力強，代碼質量高或者運氣好，可以快速迭代。反之，需要慢點來，大家都對線上系統負1.2云計算監控的目標和挑戰監控系統的目標是：提供對復雜信息系統的全面監控，反映云資源池的健康狀況和可用性情況，得到一個可控制、可預測的云環境，支持云業務安全、穩定、高效、持續地運行；同時，有效地控制管理成本，規范管理工作，實現運行管理的智能化和高效性，提高整體的維護水平；及時掌握各種資源現狀和運行信息，為決策提供支持。監控是運維團隊眼睛的延伸。監控系統應當解決三個問題：“出問了問題?”“是什么問題?”控。通過白盒監控能夠了解其內部的實際運行狀態，觀察監控指標能夠預判可能出現的問可以在系統或者服務發生故障時快速通知相關人員進行處理。通過建立完善的監控體系，·長期趨勢分析：通過對監控樣本數據的持續收集和統計，對監控指標進行長期趨勢分析。例如，通過對磁盤空間增長率的判斷，我們可以提前預測在未來什么時間節點上需要·對照分析：兩個版本的系統運行資源使用情況的差異如何?在不同容量情況下系統的并發和負載變化如何?通過監控能夠方便地對系統進行跟蹤和比較。·告警：當系統出現或者即將出現故障時，監控系統需要迅速反應并通知管理員，從而能夠對問題進行快速處理或者提前預防問題的發生，避免對業務產生影響。·故障分析與定位：當問題發生后，需要對問題進行調查和處理。通過對比分析不同監控數據與歷史數據，能夠找到并解決根源問題。·數據可視化：通過可視化儀表盤能夠直接獲取系統的運行狀態、資源使用情況，以及網站可靠性工程SRE(SiteReliabilityEngineer)的終極責任是確保該服務可以正常運轉。為達成這個目標，SRE定義了一套服務可靠性層級模型(如圖1-3所示),需要完成開發監控系統、規劃容量、處理緊急事件、確保事故根源被跟蹤修復等一系列工作。產品設計產品設計軟件開發容量規劃測試+發布應急事件處置監控圖1-3服務可靠性層級模型監控系統是服務可靠性層級中的最底層。離開了監控系統，就沒有能力辨別一個系統是否在正常提供服務。沒有一套設計周全的監控體系就如同蒙著眼睛狂奔。作為一個合格的系統運維人員，需要先于用戶發現系統中存在的問題。沒有監控的支持，上層應急事件處理、事后總結/問題根因分析、測試+發布、容量規劃、軟件開發、產品設計也就沒有了根要對基于現代基礎設施的應用系統進行監控，將面臨DevOps實踐和基礎架構代碼化，監控系統將會迎接若干重大挑戰。挑戰1:持續變更。在運維中需要監測偏離正常行為的信號，這里所說的“正常行為”是假設系統已經穩定運行了很長時間。然而，在一個大型復雜環境中，變更是常態。這些變更來自于：·云計算的彈性，使得基礎設施資源變得更靈活。·自動化的DevOps運維，觸發很多零散的運維操作(例如升級、重配置、備份),零散的運維、持續部署和部署實踐使得軟件變·持續變更中，監控的參數頻繁變更，監控系統參數也經常需·系統基礎設施和系統本身的持續變更使得監控參數的設置變得復雜。即使向相同的虛擬機提交請求，仍然存在巨大的性能差別。這些差別來自于你無法控制的因素，如你得到的CPU的類型。你的監控可能需要調整以適應這種變化，或者你可以配置縮放控制器，以便用新的虛擬機來代替性能下降或提升的虛擬機。·自動化設置警報、告警和閾值。監控配置過程是另一個化。當提供一臺新服務器時，應該在監控系統中自動注冊這臺服務器；當服務器停止使用挑戰2:自下而上還是自上而下監控的主要目的是盡可能快地發現缺陷、錯誤或小規模的故障，以便能夠盡早做出反應。我們很自然地采用了自下而上的方式進行監控：根據聚合值，低層中的錯誤和單個模塊中的錯誤，可以在它們傳播和影響到上層應用服務器或者應用本身之前被發現。這里要面臨部署在上百臺服務器上，依賴于網絡和存儲組件的支持。在實際環境中，把這些監控信息·在云中，低層基礎設施和服務器之間有正常和異常的分配，例如，服務器漂移的終止操作、伸縮以及滾動升級，或者實例失效或者資源共享不穩定等，導致監控服務器非常復采取自上而下的方法來監控基于云的和高度復雜的系統是解決以上問題的一種嘗試，通過監控上層或者聚合數據，從頂層問題出發再以智能的方式深入低層數據。仍然必須收集低層數據，但不會系統化地監控錯誤。這種方式也面臨挑戰：·發現問題時可能為時已晚。當在上層注意到有錯誤時，阻止影響的擴大可能已經來不·如何深入到低層數據。現代分布式系統有內置的容錯機制來掩蓋故障和錯誤，防止在系統層面出現問題直接影響用戶體驗，因此，檢測到上層問題距離低層根本故障原因出現，·從最初發生故障到擴散到整個系統并變得明顯，可能需要經過很長一段時間。不能簡單地依賴上層錯誤檢測的時間戳，也不能假設與原始問題相關的指標和日志還仍然存在，挑戰3:復雜的微服務架構在云環境中監控系統面臨另一個挑戰是對微服務架構的監控。每個微服務組件可能是一個獨立部署，每個外部請求都可能要穿越大量內部服務才能得到響應。如果一個服務響應變慢，那么整個響應時間就會拉長。在微服務中識別并修復響應慢的節點，對于偶爾發生的性能問題。很難做到盡早確定。在具有大量節點的微服務架構中，如何在這些仍然工作的節點中找出響應慢的節點?如何定義“慢”?如何選擇合適的閾值?挑戰4:大容量的分布式數據很容易生成數百萬個事件以及指標數據，每秒都會產生大量的日志。處理龐大的數據會面·在時間間隔很小的范圍內收集指標，性能開銷是巨大的。根據系統當前的狀態，運維應該使用變化的和可調節的時間間隔，而不是一些固定的時間間隔。如有產生異常的跡象或者當出現了一個偶爾發生的操作時，能用細粒度監控；當情況解決或操作結束時再返回·應該使用現代分布式日志或消息系統來進行數據收集，而不是自己構建一個。分布式日志系統(如Logstash)能收集所有種類的日志，并在數據運輸前進行大量的本地處理。這種類型的系統允許你減少性能開銷、消除噪聲，甚至在本地識別錯誤。1.3云計算監控的范圍和架構1.3.1監控管理的范圍構，由大型互聯網公司(例如谷歌、亞馬遜、Facebook等)的運維工程師開發和使用。該架構通常是由很多開源工具構成的，例如Nagios和Zenoss等，用這些工具定制和部署所能達到的監控規模是同類商業軟件很難實現的。監控體系架構如圖1-4所示。·在業務邏輯、應用程序和運行環境層級上收集數據，在每一層，以事件、日志和指標為監控對象。可以在所有服務器上使用特定文件來存儲日志，但最好將所有日志發送到公共日志服務中，這樣更利于聚合、查詢和清除。此外，在應用程序棧的所有層級中收集指標，能更好地了解系統的活動狀態。在操作系統級別，可以收集CPU、內存、磁盤或網絡·事件路由器負責事件的存儲和轉發：支持監控可視化、趨勢分析、告警、異常檢測等。通過采集、存儲和聚合所有監控信息，能實現更深入的分析和健康檢查。事件路由器用于存儲與服務(和它們支持的應用程序與運行環境)有關的配置，可以實現基于閾值的告警存儲圖形化告警業務邏輯應用程序操作系統事件路由器監控體系架構監控體系架構圖1-4監控體系架構監控管理的范圍包括構成資源服務的所有IT資源，云計算環境下的監控對象除了包括傳統的資源，還包括對虛擬化資源的監控。監控系統通常的基本架構如圖1-5所示。被監控的系統可以是獨立的應用程序或服務的集合，也可以是單獨的應用程序。如果系統主動地提供了被監控的數據，那么監控是入侵式的且影響系統設計；如果系統不主動提供被監控的數據，那么監控是非入侵的。外部系統可以通過健康檢查、性能或事務監控來監控系統或者應用級別的狀態。據庫是分布式的，是邏輯上的中心而不是物理上的中心。數據從初始收集到中心數據庫的每一步都可以進行過濾和聚合。判斷過濾和聚合量的條件包括：生產數據的大小、本地節點的潛在故障和必要通信的傳輸粒度。因為本地節點可能發生故障且數據變得不可用，所以從本地節點獲取數據并監控是重要的。將所有數據直接發送到中心數據庫可能會導致網絡阻塞，因此，在設計監控架構時，選擇從本地節點到中心數據庫之間的中間步驟以及在系統2無代理證維人員圖1-5監控系統的基本架構一旦監控數據被收集起來，就可以做很多事情。可以配置報警來觸發警告以通知運維人員或其他系統。使用圖形化和儀表盤，可以將系統狀態的變化可視化地展現給運維人員。監控系統也允許運維人員得到詳細的監控數據和日志，這對錯誤診斷、根本原因分析和確由于監控數據的使用需求不斷增長，所以很多公司開始對監控系統和整體應用系統采用統一的日志和以指標為中心的“發布-訂閱”架構。越來越多的數據類型，包括非傳統日志和指標數據，都放入統一的數據庫中，各種其他系統(不管是否與監控相關)都可以訂前面簡單介紹了監控系統的基本架構，與之相關的解決方案已經有很多。監控系統有4個發展階段，也是度量監控系統的方法，以及對監控改進的指南，可用于評估當前監控系統的成熟度級別以及可采用的改進步驟。第1級是組件監控，可以反映每個組件的狀態并根據策略進行警報通知。第2級是對各層級進行監控，從各個層級、角度收集運行信息，包括各種指標度量值、輸出日志、服務追蹤信息等。第3級不僅查看所有的狀態、事件和度量，還查看依賴關系并跟蹤動態變更情況，數據用可視化工具展現，以實時洞察整個系統的總體運行情況。第4級是智能化，是更遠大愿景的一部分，能夠在發生故障之前發送警報，通過擴展或重路由服務來實現自我治愈、異常檢測等。監控系統成熟度各級的輸入與輸出，如圖1-6所示。圖1-6監控系統成熟度當從監控成熟度第1級晉升到第2級，將獲得對系統更深入的洞察力，將更好地理解服務的可用性和性能。從第2級到第3級，將可以在整個IT系統中獲得全棧的可見性，并精確地理解業務流程、應用程序和基礎架構之間的依賴關系。無論是云計算、應用程序、還是基礎設施，都可以采用更加主動的監控方法來支持數字企業的需求。最后進入第4級時，將獲得預測分析能力，這將幫助企業預測可能發生的問題、指出可能的原因，IT維護更智能、敏捷、高效。對于監控系統軟件，開源的解決方案有流量監控(MRTG、Cacti、Smokeping、Graphite等)和性能告警(Nagios、Zabbix、ZenossCore、Ganglia、OpenTSDB等),每種軟件都有自己的特點和功能，有各自的側重點和目標，然而，在設計理念和實現方法上都大同小異，具有共同特征。例如，都具有采集數據、分析展示、告警以及簡單的故障自動處理等環節。下面簡單介紹監控系統發展演進過程中出現的兩個最常用的開源軟件。Zabbix是一個基于Web界面的提供分布式系統監視以及網絡監視功能的企業級開源解決方案，其工作數據流如圖1-7所示。conflog.conflogconfe圖1-7Zabbix工作數據流Zabbix能監視各種網絡參數，保證服務系統的安全運營，并提供良好的通知機制使系統管理員能夠快速定位/解決存在的各種問題。Zabbix由兩部分構成——Zabbixserver與可選組件Zabbixagent。Zabbixserver可以單獨監視遠程服務器的服務狀態；同時也可以與Zabbixagent配合，可以輪詢Zabbixagent主動接收監視數據，還可被動接收等多種協議，將采集到的數據存放到數據庫，然后對其進行分析整理，若達到條件觸發則告警。Zabbix支持二次開發，其靈活的擴展性和豐富的功能是其他監控系統所不能比擬OpenTSDB通過HBase存儲所有的時序(無須采樣)來構建一個分布式、可伸縮的時間序列數據庫。它支持秒級數據采集所有指標，支持永久存儲，可以做容量規劃，并可很容易地接入現有的報警系統。OpenTSDB可以從大規模的集群(包括集群中的網絡設備、操作系統、應用程序)中獲取相應的指標，并進行存儲、索引以及服務，從而使這些數據更集，這是之前其他監控系統很難實現的。因得益于其存儲系統的選擇，它支持大數據分析，在大型的基礎設施監控中也得到較為廣泛的使用。CNetworkPrometheus(普羅米修斯，有時簡稱Prom)是一個開源的容器和微服務監測和預警工具集。Prometheus是為提供豐富度量指標、又不影響目標系統性能而設計的、高度可定制的云原生監控系統。Prometheus已經成為主流開源的監測工具，受到了廣大用戶的歡迎，對于那些嚴重依賴容器和微服務的人來說，Prometheus是他們最佳的選擇。Prometheus適用于各種規模、各個行業。Prometheus已經具備完整的生態，包括與監控密切關聯的報警系統，也非常方便與第三方的監控系統集成，成為監控報警平臺。Prometheus為現代DevOps工作流提供了關鍵組件，監視云原生應用程序和基礎設施，并與CNCF另一個流行的項目Kubernetes完美協同。Prometheus是由SoundCloud開發的開源監控報警系統和時序數據庫(TimDatabase,TSDB)。PrometheusGoogle的Brog系統演變而來的),從2012年開始由前Google工程師在SoundCloud以開源軟件的形式進行研發，并且于2015年初對外發布早期版本。2016年5月繼Kubernetes之后成為第二個正式加入CNCF基金會的項目，同年6月正式發布1.0版本。2017年底發布了基于全新存儲層的2.0版本，能更好地與容器平臺、云平臺配合。2018Prometheus歷史故事從前，在加利福尼亞州山景城有一家公司，名為Google。該公司經營著一系列產品，最著名的是廣告ERM搜索引擎平臺。為了運行這Borg的平臺。Borg系統是“一個集群管理器，它運行數十萬個作業，來自數千個不同的應用程序跨越多個集群，每個集群都有多達數萬臺機器”。開源容器管理器Kubernetes的大部分遺產都歸功于Borg。Borg在Google部署后不久，人們就意識到，若要應對這種復雜性，則需要一個類似功能的監控系統。Google(備注：Borg和Borgmon都從未公開過。直到最近，人們才了解Prometheus的靈感來自Google的Borgmon。MattT.Proud(前Google員工)最初將其作為研究項目開發的。在Proud加入SoundCloud之后，他與另一位工程師JuliusVolz最終在2015年1月發布了公開版本。多公司采納，通常用于類似的監控，但也用于監控更傳統的體系結構。2.成為開源社區熱點、監控主流Prometheus使用開源的Go語言編寫，并且在Apache2.0許可下授權，該項目有著非常活躍的開發者和用戶社區。現在已經成為一個獨立的開源項目核，并且獨立于任何公司。Prometheus作為新一代的云原生監控系統，目前GitHub上已超過2萬顆星。超過650多位貢獻者參與到Prometheus的研發工作上，并且有120多項的第三方集成。從2012年11月開始至今，Prometheus持續成為監控領域的熱點。在2016年之后，Prometheus綜合排名持續提升，且速度最快。Prometheus很有活力，開發者可以自己寫導出器(exporter),每個監控參數都可控，并能很快定位到問題。Prometheus能抓取或拉取應用程序導出的時間序列數據。應用程序本身經常通過客戶端函數庫或導出器(導出程序，作為HTTP端點)呈現出時間序列數據。導出器和客戶端函數庫可用于多種語言、框架和開源應用程序，例如用于Apache、NgiPrometheus關注的是近期發生的事情，而不是跟蹤數周或數月的數據。因為大多數監視查詢和警報都是從最近的(通常不到一天的)數據生成的。Prometheus假設用戶試圖修復的問題是最近的，因此最有用的數據是最近的數據。Prometheus監控數據默認保留15天。/metries圖1-9Prometheus設計理念Prometheus還有一個推送網關，可以用來接收少量數據，例如獲取不能被直接抓取的監控目標的指標數據。Network傳統的監控解決方案需要多種監控工具組合，如圖1-10所示。圖1-10傳統復雜的多種監控手段組合和其他監控系統相比，Prometheus功能強大，可以監控所有層級的指標(見表1-1),簡化了監控復雜度(如圖1-11所示)。監控指標(示例)應用時延、鋯誤、查詢量、內部狀態等白己代碼埋點資源使用、性能特性等主機(OS,硬件)網絡圖1-11Prometheus監控解決方案，簡化系統部署Prometheus是一個開源的完整監控解決方案，對傳統監控系統的測試和告警模型進行了徹底的顛覆，形成了基于集中化的規則計算、統一分析和告警管理的新模型。相比于傳統監控系統，Prometheus具有大量優點。1.易管理性Prometheus核心部分只有一個單獨的二進制文件，不存在任何的第三方依賴(數據庫、緩存等)。唯一需要的就是本地磁盤，因此不會有潛在關聯的故障風險。Prometheus基于Pull模型的架構方式，可以在任何環境(本地主機、開發環境、測試環境等)搭建監控系統。對于一些復雜的情況，還可以結合Prometheus的服務發現能力動態地管理監控2.更契合的架構采用Push模型的監控系統，客戶端需要在服務端上進行注冊及監控數據推送；而在Prometheus采用的Pull模型架構里，具體的數據拉取行為是完全由服務端決定的。服務端可以基于某種服務發現機制自動發現監控對象，多個服務端之間能夠通過集群機制實現數據分片。Push模型想要實現相同的功能，通常需要客戶端進行配合，而這在微服務架構里是比較困難的。Prometheus建議用戶監控服務的內部狀態，可以基于Prometheus提供的豐富Client庫，很容易地在應用程序中添加支持Prometheus的監控指標，用戶可以3.靈活的數據模型在Prometheus里，監控數據是由值、時間戳和標簽表組成的，其中，監控數據的源信這些數據，還提供了PromBench基準測試。在硬件資源滿足的情況下，對于單實例Prometheus可以處理數以百萬的監控指標以及數十萬個數據點。數，大部分情況下用戶都可以直接通過PromQPromQL也可應用于數據可視化(如GraPrometheus架構非常簡單，可以在每個數據中心、每個團隊中運行獨立的Prometheus服務器實例。對于大型環境，Prometheus支持聯邦(federation)集群方式，把多個Prometheus實例集成單個邏輯集群。當單個Prometheus服務器實例處理的任務量過大時，通過功能分區(sharding)結合聯邦集群可以對其進行擴展。6.健全的生態，開放、易于與第三方系統集成使用Prometheus可以快速搭建監控服務，并且可以方便地在應用程序中進行集成。目(SDK),基于這些SDK可以很容易地將應用程序納入到Prometheus的監控中，或者開發自己的監控數據收集程序。同時，Prometheus還支持與其他監控系統進行集成，如Graphite、Statsd、CollecPrometheus的情況下，采用Prometheus的clientlibPrometheus社區提供了大量第三方實現的監控數7.可視化Prometheus服務器中自帶了一個PrometheusUI,通過這個UI可以方便地對數據進行查詢，并且支持直接以圖形化的形式展示數據。最新的Grafana可視化工具已經完美支持Prometheus,基于Grafana可以創建精美、炫酷的監控視圖。基于Prometheus提供的API,還可以實現自己的監控可視化UI。Prometheus雖然具有上述優勢，但其仍然無法滿足微服務監控的所有需求，具體的不1.6本章小結本章從云計算時代的業務特點出發，探討了云計算監控的目標和挑戰，梳理了云資源監控的范圍及監控系統實現的一般方式。接著從開源監控軟件的演進出發，簡單介紹了下一章將詳細介紹Prometheus的架構和組件，然后快速部署、運行一個簡單的Prometheus監控系統，使讀者對Prometheus有一個感性的認識。更多閱讀材料[1]中國信息通信研究院.云計算發展白皮書(2019年)[P/OL].2019-7./a/[2]肖建一.中國云數據中心運營指南[M].北京：清華大學出版社，2013.[3]LenBass,等.DevOps軟件架構師行動指南[M].胥峰，等譯.北京：機械工業出版社，2017.[4]國務院發展研究中心課題組.傳統產業數字化轉型的模式和路徑[P/OL].2018-[5]BetsyBeyer,等.SRE:Google運維解密[M].孫宇聰，譯.北京：電子工業出版社，2016.[6]EricCarter.examplesofPrometheus第2章Prometheus基本概念及部署本章深入闡述Prometheus生態圈系統中的核心組件及其整體架構內容，并對所涉及的相關概念進行介紹。在傳統主機和Docker環境中，對Prometheus進行快速部署操作，為后續全面掌握Prometheus在傳統業務和云中對各個應用環境的監控和告警做好知識儲備。2.1Prometheus架構圖2-1為官方提供的Prometheus體系架構及其生態圈系統組件。pulljsbsjohspagerditypishcotifyNude圖中展示了Prometheus的整體架構設計理念，中心化數據采集和分析。其關鍵的工作·Prometheus服務器周期性地或在設定的時間段內，可以通過以下方式獲取內容。·從已經配置好的job或者exporter中拉取metric。·Prometheus服務器獲取到數據后存儲在本地(也可以選擇遠端存儲),通過一定規則對數據進行清理和整理，并且把結果存儲到新的時間序列中。·Prometheus服務器定時查詢已經定義好的規則，若發現滿足定義的觸發條件，便將alert信息推送至已配置好的Alertmanager。·Alertmanager收到alert信息后，根據配置文件對接收到的alert信息進行處理(聚合、去重、降噪),然后將它們轉換為網頁、電子郵件和其他通知方式發出告警。·最后通過PromQL或其他API可視化地展示收集的數據，例如自帶Prometheus在記錄純數字時間序列方面表現得非常優秀。它既適用于對服務器硬件各項指標的監控，也適用于對高度動態的面向服務架構的監控。在當下比較火的微服務生態圈中，它對多維數據收集和查詢的支持具有特殊的優勢。Prometheus的基本原理是通過HTTP協議周期性獲取被監控組件的狀態信息，任意組件Prometheus可以更好地適應虛擬化，如VM或Docker容器的環境集成。當使用者監控的服務出現故障時，它可以快速定位和診斷問題。每個Prometheus服務器都是獨立的，不依賴于網絡存儲或其他遠程服務。當基礎架構的其他部分損壞時，可以快速恢復，并且不需要設置大量的基礎依賴架構。與此同時，Prometheus也有不適用的應用場景，例如，使用者要求統計數據100%的精確，那么它并不適用，因為它收集的數據還是有可能不夠詳細和完整，例如精準實時計費首先我們對Prometheus進行快速部署，使其啟動正常運行，然后通過Prometheus自帶的一個比較簡單的WebUI查看表達式搜索結果。Prometheus官方給出了多種部署方法，如使用Docker容器，還提供了使用第三方配置管理工具Ansible、Chef和Saltstack進行安裝的案例地址，這些都可以在官方文檔中找到，感興趣的讀者可以進行相關測試安裝。官方網站還為用戶提供了二進制文件。如果沒有特殊定制代碼的需求，直接使用二進制文件進行部署是一種比較簡便的方法，因為Prometheus是基于Go語言編寫的，編譯后的軟件包不依賴第三方的內容。用戶完整下載自己所需要的版本，在系統中解壓軟件包并做簡單的基礎配置，之后就可以正常啟動Prometheus服務，開始我們的Prometheus云原生這里我們選擇二進制文件安裝包進行快速部署。在安裝之前，首先在官方網站下載頁面地址https://prometheus.io/download/中找到Prometheus下載列表。在這里可以適用于各平臺的二進制文件最新版本。或者，也可以直接在官方的PrometheusGitHub下載頁面地址/prometheus/prometheus/releases特定版本，以及對應平臺的二進制文件。下面我們開始Prometheus的安裝部署工作。2.快速部署#sha256sumprometheus-2.4.0.linux-amd64.tar.gz與官網提供的軟件包類表中“SHA256Checksum”列里的哈希值進行核對，保證下載的Prometheus軟件包的完整性。2)解壓縮二進制軟件包到指定的安裝目錄，運行Prometheus,操作如下：#tar-zxvfprometheus-2.4.0.linux-amd64.tar.gz-C/data#這里安裝在/data目錄下#cd/data#注意核對個人安裝目錄#chown-Rroot:rootprometheus-2.4.0.linux-#ln-svprometheus-2.4.0.linux-amd64prometheus3)啟動Prometheus。我們進行快速部署，目的是盡快看到一個Prometheus監控環境，所以不對Prometheus服務同級目錄下的prometheus.yml配置文件進行詳細說明和配置修改，后續第3章會進一步介紹配置文件的使用。然后，我們運行與默認配置文件同級目錄下的Prometheus執可以看到以下輸出信息，由于本書篇幅緣故，這里只截取了Prometheus啟動時輸出日志的部分內容，省略了日志格式中開頭類似“level=infots=2019-03-caller=main.go:238msg="StartingPrometheus"version="(version=2.4.0,brarevision=068eaa5dbfce6ccaller=main.go:239build_context="(go=gol.10.3,user=root@d84c15ea5e93,date=20180911-10:46:37)"caller=main.go:242vm_limits=”(soft=unlimited,hard=unlimitecaller=web.go:397component=webmsg="Startlisteningforconnections"adcaller=main.go:554msg="Scaller=main.go:624msg="Loadingconf?igurationf?ile"f?ilename=prometheus.ymlcaller=main.go:650msg="Completedloadingofconf?igurationf?ile"f?ilename=procaller=main.go:523msg="Serverisreadytoreceive從截取的日志中，我們找到加粗標記字體的信息，可以看到prometheus服務已經成功啟動，且默認監聽端口9090已經開啟，如果想更換默認監控端口，需要啟動時添加配置用./prometheus-h查看相關幫助信4)添加Prometheus為系統服務開機啟動。此時，當終端關閉或按下Ctrl+C時，Prometheus服務會自動關閉，這不是我們想要的工作方式。熟悉Linux系統的讀者可以在Prometheus當前目錄下，直接執行命令：nohup./prometheus&使其后臺進行運行即可。但是，我們要對進程執行關閉、重新啟動、查看進程狀態等操作時，還需配合各種Linux命令才能完成。這里為了方便，將Prometheus添加為系統服務且開機自啟動。可以使用CentOSLinuxrelease7操作系統中的命令systemctl來管理守護進程#vi/usr/lib/systemd/system/prometheusDescription=PrometheusserverdaemonExecStart=/data/prometheus/pr--conf?ig.f?ile"/data/prometheus/proEQ\*jc3\*hps19\o\al(\s\up5(stor),sto)EQ\*jc3\*hps19\o\al(\s\up5(a),r)EQ\*jc3\*hps19\o\al(\s\up5(g),a)EQ\*jc3\*hps19\o\al(\s\up5(e),g)EQ\*jc3\*hps19\o\al(\s\up5(.t),e)EQ\*jc3\*hps19\o\al(\s\up5(db.),tsd)EQ\*jc3\*hps19\o\al(\s\up5(p),b)EQ\*jc3\*hps19\o\al(\s\up5(t),r)EQ\*jc3\*hps19\o\al(\s\up5(h),e)EQ\*jc3\*hps19\o\al(\s\up5("/data/),tentio)EQ\*jc3\*hps19\o\al(\s\up5(meth),15d)--web.console.templates="/data/promethe--web.console.libraries="/data/prometheus/consol--web.listen-address"0.0.0WantedBy=multi-user,以上prometheus.service文件中選項內容語義都比較清晰直觀，在使用文件過程中，根據各自部署環境可能需要對選項做出修改，如表2-1所示。說明ExecStart--datw/prometheusprom-storage.tsdb.path"/data/prometheu--web.console.templates="/data/prometheus/co用于生成返回Prometheus的相對和絕可以在后續告警通知內容中直接點擊鏈接地址訪問-web.listen-address":9090*Prometheus默認監控端口表2-1可修改的選項及說明如果有讀者朋友仍舊有疑惑，可以通過./prometheus-h查看幫助內容。但需要注意的是，由于筆者是內網測試環境，以上默認使用了root用戶和組。建議大家使用非root用戶權限，讀者可以根據實際使用環境指定用戶權限，例如使用prometheus用戶，當然前提是需要個人在系統中創建此用戶。最后，配置文件完成且保存退出，需要通知systemdstartprometheus.servicestatusprometheurestartprometheus.ser#開啟服務#查看狀態為Active:active(running)#重啟服務#停止服務至此，我們完成了Prometheus的快速安裝工作，并添加了系統服務、設置了開機啟動Prometheus所在的Target是multi-user.target。這個設置非常重要，因為執行systemctlenableprometheus.service命令設置一個符號鏈接，就會放在/etc/systemd/system目錄下面的multi-user.target.wants目錄之中。Prometheus啟動腳本中用到了systemd的service·[Unit],提供服務描述信息、啟動順序與依賴關系。·[Service],服務的關鍵部分，設置服務運行時使用的一些具體參數。·After,服務類別描述，定義unit的啟動次序。·Type,設置進程啟動類型，其類型有：·simple:默認值，執行ExecStart指定的命令，啟動為主進程。·forking:進程將在啟動過程中使用fork()系統調用，創建后父進程立即退出，而子·dbus:類似于simple,但會等待D-Bus信號后啟動。·notify:當前服務啟動完畢，通知systemd再繼續往下執行。·ExecStartPre:在ExecStart之前執行的命令，語法規則與ExecStart=完全相同。·ExecStartPost:在ExecStart之后執行的命令，語法規則與ExecStart=完全相同。·ExecReload:可選指令，設置服務被要求重新載入配置時所執行的命令行。·ExecStop:可選指令，設置停止服務要運行的命令或腳本。可以設置如下值：·no(默認值):退出后不會重啟。·on-success:只有正常退出時(退出狀態碼為0),才會重啟。·on-failure:非正常退出時(退出狀態碼非0),包括被信號終止和超時，才會重啟。·always:不管是什么退出原因，總是重啟。[Install]區塊常用選項：·Alias:可用于啟動的別名。3.熱加載更新配置在Prometheus的日常維護中，一定會對配置文件prometheus.yml進行再編輯操作，通常對Prometheus服務進行重啟動操作即可完成對配置文件的加載。當然也可以通過動態的熱加載來更新prometheus.yml中的配置信息，一般熱加載有兩種方法：#curl-XPOSThttp://localhost:9090/-/reload若使用第二種方式進行熱加載操作，需要在Prometheus服務啟動時指定--web.enable-lifecycle,添加到以上的Prometheus自啟動文件中使用。無論使用哪種熱加載方式，要想熱加載更新配置文件成功，必須保證配置信息填寫正確。這里可以通過Prometheus提供的工具promtool對prometheus.yml配置文件進行提前核關于promtool工具其他的使用方法，可以利用#./promtool-h進行查看。Prometheus服務鏡像。在安裝前，首先要確保個人安裝環境已經完成了Docker的安裝，如果沒有Docker環境，則需要根據Docker官方或其他資料完成對應平臺的Dock現在，我們開始Prometheus安裝操作，執行安裝命令，安裝最新版本；#dockerrun—nameprometheus-p9090安裝完成后，終端顯示以默認配置文件為示例的Prometheus啟動信息，并開啟映射端口9090對外進行監聽。可以使用Docker命令進行一些基礎的操作：#dockerps-fnames=prometheusCONTAINERIDIMAGE...STATUSPORTS5fd51542a6a4prom/prometheus..Up2#dockerstartprometheus#啟動已經停止的prometheus容器#dockerstatsprometheus#查看prometheus容器狀態#dockerrestartprometheus#重啟prometheus容器#dockerstopprometheus#停止運行的prometheus容器對于生產環境部署，強烈建議使用數據卷容器模式來簡化對Prometheus升級數據的管理。例如，使用Docker綁定數據卷功能，映射prometheus.yml配置文件到主機指定的路徑下。這里我們不做具體的操作演示，感興趣的讀者可以自己對Prometheus容器數據卷至此，我們已經在物理主機環境或使用Docker容器快速部署好了Prometheus系統環境，需要注意的是防火墻要開通對外提供訪問的9090端口。如果使用CentOSLinuxrelease7操作系統進行Prometheus安裝，要注意設置SeLinux狀態內容。完成這些工作后，我們便可以通過瀏覽器使用PrometheusWebUI,即在瀏覽器中輸入http://IP:9090格式便可進行訪問。例如，依據以上安裝時的應用信息，訪問示例地址http://7:9090,此時默認訪問的頁面是Graph頁面，如圖2-2所示。accuratetimeandtimednttmightcauseunexpectedqueryresuExpression(pressShit+EElement圖2-2PrometheusWebUIGraph頁面注意，圖中的“Warning”提示信息，這是由于瀏覽器主機與Prometheus服務器之間時間不一致造成的。需要對瀏覽器主機或Prometheus服務器進行時間同步。在時間同步完成后，再次訪問http://192.168.24.17:9090,警告自動消失。如圖2-3所示。Prometheus本身是自帶導出器(exporter)的，現在可以在WebUI中查看exporter采集到具體數據，例如，在查詢框中輸入UP,點擊“Execute”按鈕后，會在Console選項卡中顯示Prometheus服務在線狀態的“UP”信息，如圖2-4所示。PrometheusPrometheus1圖2-4PrometheusUP狀態若點擊“Graph”選項卡，則展示“UP”狀態，如圖2-5所示。PrometheusAlertsGraphStatusHExecule-insertmetncatc210圖2-5PrometheusUP狀態視圖最后，通過訪問7:9090/targets地址，可以查看頁面中的Targets信息。示例中使用默認配置文件，僅僅對Prometheus本機進行監控，如圖2-6nttp/Aocalhost90900圖2-6Targets頁面信息Prometheus內部默認提供許多metric(指標)用于監控操作，這些指標都可以在Web我們直接點擊圖2-6中提供的鏈接即可訪問Metrics信息，但示例中是默認配置文件，需信息。由于內容比較多，這里僅展示部分輸出信息；#TYPEgo_gc_duration_secondssgo_gc_duration_seconds{quantile="0"}0go_gc_duration_seconds{quantile=“0.25”}0prometheus_build_info{branch="HEAD",goversion="gol.10.3",revision="068eaa5dbfce6c08f3d05d3d3cOb#HELPprometheus_conf?ig_last_reload_success_timestamp_secondsTimestampofthelastsuccessful#TYPEprometheus_conf?iglast_reload_success_timestamp_prometheus_conf?ig_last_reload_success_timestamp_#HELPprometheus_conf?ig_last_reload_successfulWhetherthelastconf?igurationreloadattemptwas#TYPEprometheus_conf?ig_last_reload_successf#HELPpromhttp_metric_handler_requests_in_f?lightCurrentnumberofscra#TYPEpromhttp_metric_handler_requests_in_f?lightgaugepromhttp_metric_handler_requests_in_f?light#HELPpromhttp_metric_handler_requests_totalTotalnumberofscra#TYPEpromhttp_metric_handler_requests_totalpromhttp_metric_handler_requests_total{code="20promhttp_metric_handler_requests_total{promhttp_metric_handler_requests_total{code="5在2.2節中，其實我們已經涉及了一些概念詞匯，本節我們將對Prometheus中的Datamodel(數據模型)、metric類型以及Job和Instance等相關概念進行說明，便于讀者Prometheus將所有數據存儲為時間序列(timeseries)數據，每個時間序列數據都具有帶時間戳的數據流，數據流都由其指標(metric)名稱和一組鍵值對(也稱為標簽(label))唯一標識，即不同的標簽代表不同的時間序列。我們可以基于這些標簽很容metric即指標，指定監控目標系統測量特征，可以理解為定義了某個監控指標類型名稱。指標是隨時間將數據點鏈接在一起的標識符，是Prometheus的核心概念之一。Prometheus會將指標存儲在其時間序列數據庫中，可以對它們進行查詢操作，以了解被監控目標隨時間的變化情況。指標名稱可以由ASCII字母、數字、下劃線和冒號組成，但應該以字母開頭，后面可以跟任意數量的字母、數字和下劃線。而[a-zA-Z:][a-zA-ZO-9:]*是有效指標的正則表達式。注意：冒號“:”是為用戶定義的記錄規則保留的。當有多個服務公開相同的指標時，為了對其進行區下幾個字段組成：·任意數量的標簽，當然也可以是零個，表示為鍵值(key-value)其實在2.2.3小節中，我們通過瀏覽器訪問Prometheus示例端點http://7:9090/metrics,查看抓取的Prometheus指標，其開始內容如下：go_gc_duration_seconds{quantile="0.75"}0.label即標簽，支持Prometheus的維度數據模型，是一個關鍵部分。相同監控指標名稱的任何給定標簽組合，都會標識該指標的特定維度實例化，基于這些維度，Prometheus可以使用查詢語言對數據進行過濾和聚合。更改任何標簽值，包括添加或刪除標簽，都將標簽名稱可以包含ASCII字母、數字和下劃線，需要以字母a-z或A-Z開頭，然后跟字劃線)開頭的標簽名稱，只能在系統內部使用。標簽值可以是任何UTF-8字符，也可以為空，但是在Prometheus服務器中，標簽值為空可能令人困惑，因為看起來就像沒有這個標簽一樣。sample即樣本，按照某個時序以時間維度采集的數據，有序的樣本形成了實際的時間notation即符號，Prometheus時序格式和OpenTSDB類似，是用符號表示時間序列的。在指定一個指標和一個或一組標簽時，時間序列通常使用以下格式標識： 監控指標名稱(metricname)用來說明被監控樣本怎么稱呼，標簽反映的是當前樣本method="POST"和handler="/messages"的時間序列可以這樣寫：2.3.2Metric的四種類型Prometheus客戶端庫提供了四種核心指標類型。目前，它們僅在客戶端庫(以支持針對特定類型的使用而定制的API)和wire"協議中有所區別。Prometheus服務器還沒有充分使用這些類型信息，未來官方在這方面會持續改進。·重啟進程后，會被重置，例如在微服務架構中，服務實例是短暫的，在滾動更新、自動縮放等操作時，計數器就會被重置為0。該指標類型通常用于跟蹤事件的數量或大小，可以用它來記錄服務請求次數、任務完成數、錯誤發生次數。常用的場景有接口請求次數、操作重試次數和消息隊列數量等。對于命名Counter類指標的最佳做法是使用_total后綴，例如，用戶和系統CPU總時間監控在實際應用場景中，大部分指標為Counter類型，因為該類型不會在兩次采集間隔中丟失信息，所以它是推薦使用比較多的指標類型。有些數據的值可能會隨著時間的推移而上下浮動，這時可以使用Gauge類型的指標來跟蹤此類數據，Gauge類型的指標是一種常規指標，反映系統當前狀態的快照，是對一個值的瞬時測量，有如下特點：Gauge類指標通常可以用來記錄CPU使用情況、內存使用量、磁盤當前和已經使用的空間容量、網絡使用變化、溫度變化、業務類游戲在線人數統計和訂單數量統計等等，例如，Gauge類型指標適合記錄那些無規律變化的數據，而且兩次采集之間可能會丟失某些變化數值，當然隨著時間周期的粒度變大，丟失關鍵變化數值的情況也會增多。Histogram即直方圖，形狀與柱狀圖相似，用于表示在一段時間范圍內對數據進行采樣，對指定區間以及總數進行分組統計。典型的應用有請求持續時間、響應大小等等。在Prometheus系統中的查詢語言中，它有三種作用：·對每個采樣點進行統計，對應到各個分類值中及bucket(可稱為“桶”)。·對每個采樣點值累計和(sum)。·對采樣點的次數累計和(count)。例如，采用對應的以下幾種方式產生直方圖(假設監控指標名稱為<basename>):·按bucket累計計數，相當于<basename>_bucket{le="<上限邊界>"},此值為小于等于上限邊界的所有采樣點數量。·樣本累計總和，相當于<basename>_sum。·樣本累計次數總和，相當于<basename>_count。具有基本監控指標標準名稱的直方圖，在scrape期間暴露多個時間序列。實踐中，直方圖將會創建一個額外的帶有_bucket后綴的指標，在PrometheusServer返回的自身樣prometheushttp_requestdurationsecondsbucket(handler="/",le="關于Histogram類型，使用的查詢會對服務器的CPU有一定的消耗，最直觀的反映就是查詢結果的返回耗時情況。需要記住，每個獨特的標簽組合都被視為一個單獨的時間序列，因此，通常的做法是盡量保持bucket的數量較小，以及直方圖上的其他標簽數量較少。Summary即概率圖，類似于Histogram,常用于跟蹤與時間相關的數據。典型的應用包括請求持續時間、響應大小等。Summary同樣提供樣本的count和sum功能；還提供quantiles功能，可以按百分比劃分跟蹤結果，例如，quantile取值0.95,表示取樣本里面的95%數據。Histogram需要通過<basename>_bucket計算quantile,而Summary直同樣，Summary在scrape期間暴露多個時間序列，例如以下是Golang垃圾收集器摘要[1]Wire協議是總線通信中最為重要的一種操作，在每次總線通信之前主機必須首先發送復位信號。在Prometheus中，任何被采集的目標，即每一個暴露監控樣本數據的HTTP服務都稱為一個實例(Instance),通常對應于單個進程。而具有相同采集目的的實例集合(比如為可伸縮性或可靠性而復制的流程)稱為作業(Job)。例如，以下四個復制實例的API服job:api-server這里可以結合后續第3章介紹的用來監控主機CPU、內存、磁盤、網絡等的Nodeexporter監控程序來學習。現在看一下在Prometheus中使用prometheus.yml配置文件在以上Job中，采用靜態配置方式定義被監控目標，在當前主機上運行的Nodeexporter監控程序被稱為一個實例(Instance),而具有相同目的這些實例，或者是同一個監控進程的多個副本進程則通過每一個作業(Job)進行管理。除了靜態配置每個Job采集實例地址外，Prometheus還可以從自動發現的實例上采集監控數據。下面介紹自動生成標簽和時間序列。Prometheus在采集目標數據的同時，會自動在時序的基礎上附加如下標簽，用于識別被采集的目標。·job:配置目標所屬的job名稱。·up{job="<job-name>",instance="<instance-id>"}:即可訪問，則為1,否則為0。EQ\*jc3\*hps24\o\al(\s\up11(續采),scra)EQ\*jc3\*hps24\o\al(\s\up11(集),pe)EQ\*jc3\*hps24\o\al(\s\up11(耗時間),sample)到的數據按照時間序列存儲在本地磁盤的時序數據庫中(當然也支持遠程存儲),自身對用于輸出被監控組件信息的HTTP接口統稱為Exporter(導出器)。目前互聯網公司常用的組件大部分都有Exporter供直接使用，比如Nginx、MySQL、Linux系統信息(包括Exporter是Prometheus系統中重要的組成部分。在實際中收集監控樣本數據都是由Exporter完成的。Exporter可以是一個獨立運行的進程，對外提供一個用于獲取監控數據的HTTP服務。Prometheusserver只需要定時通過這些Exporter提供的HTTP服務獲取監控數據即可。可以類似理解為我們傳統意義上的被監控目標的agent,只是區別在于Exporter不會主動推送監控數據到Prometheusserver。官方的Exporter列表中包含了常見的絕大多數系統監控指標，比如用于機器性能監控的node_exporter,MySQL數據庫監控的mysqld_exporter,以及網絡設備監控的snmp_exporter等。這些已有的Exporter對于監控來說，只需進行很少的配置，就能提Pushgateway是指用于支持短期臨時或批量計劃任務