Prometheus監(jiān)控技術(shù)與實(shí)踐

第一部分概述第1章云計(jì)算時(shí)代的監(jiān)控系統(tǒng)1.2云計(jì)算監(jiān)控的目標(biāo)和挑戰(zhàn)1.6本章小結(jié)第2章Prometheus基本概念及部署2.2Prometheus快速部署2.5本章小結(jié)第二部分Prometheus技術(shù)基礎(chǔ)第3章Exporter3.5Prometheus之黑盒監(jiān)控第4章服務(wù)發(fā)現(xiàn)4.1基于文件的服務(wù)發(fā)現(xiàn)4.2基于Consul的服務(wù)發(fā)現(xiàn)4.4Relabelling4.5本章小結(jié)5.1時(shí)序數(shù)據(jù)庫5.3PromQL聚合操作5.6PromQL查詢分析5.7本章小結(jié)第6章告警處理6.7本章小結(jié)第7章可視化7.7本章小結(jié)第三部分監(jiān)控綜合實(shí)踐第9章OpenStack云計(jì)算監(jiān)控9.2OpenStackExp9.4本章小結(jié)第10章Docker容器監(jiān)控第11章Kubernetes監(jiān)控11.3通過Operator方式部署Prometheus11.5監(jiān)控對象11.8本章小結(jié)第12章微服務(wù)及業(yè)務(wù)監(jiān)控12.4在SpringBoot自定義Metrics第13章日志監(jiān)控的設(shè)計(jì)與實(shí)現(xiàn)13.3Fluentd日志監(jiān)控第一部分概述■第1章云計(jì)算時(shí)代的監(jiān)控系統(tǒng)■第2章Prometheus基本概念及部署第1章云計(jì)算時(shí)代的監(jiān)控系統(tǒng)過去的十年里，我國云計(jì)算、大數(shù)據(jù)、人工智能等IT技術(shù)迅速發(fā)展，數(shù)字技術(shù)呈指數(shù)級增長，技術(shù)創(chuàng)新和商業(yè)創(chuàng)新呈現(xiàn)大爆炸的形態(tài)。容器、微服務(wù)、DevOps等技術(shù)不斷推動著云計(jì)算的變革。云計(jì)算的應(yīng)用已經(jīng)深入到政府、金融、工業(yè)、交通、物流、醫(yī)療健康等傳統(tǒng)行業(yè)。隨之而來的挑戰(zhàn)是如何管理好這些新型的IT基礎(chǔ)環(huán)境，特別是如何實(shí)時(shí)掌握云環(huán)境下業(yè)務(wù)的運(yùn)行狀態(tài)及達(dá)到服務(wù)保障等級。企業(yè)需要考慮：本章將從云計(jì)算時(shí)代的應(yīng)用特點(diǎn)入手，分析云計(jì)算環(huán)境下監(jiān)控面臨的挑戰(zhàn)，提出需要什么樣的監(jiān)控。接著簡要介紹監(jiān)控的成熟度，并回顧開源監(jiān)控軟件的演進(jìn)歷史。最后重點(diǎn)介紹順應(yīng)云時(shí)代的云原生監(jiān)控系統(tǒng)——Prometheus誕生及其解決方案的特點(diǎn)。1.1云計(jì)算時(shí)代的應(yīng)用系統(tǒng)云計(jì)算時(shí)代的應(yīng)用系統(tǒng)首先是大量企業(yè)通過“IT云化”實(shí)現(xiàn)數(shù)字轉(zhuǎn)型，之后達(dá)到敏捷1.1.1企業(yè)“IT云化”實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型中國已是最大的數(shù)字化消費(fèi)市場，崛起的新興數(shù)字行業(yè)、企業(yè)在金融服務(wù)、通訊、出行和物流等領(lǐng)域?qū)鹘y(tǒng)的市場規(guī)則和經(jīng)營方式形成巨大沖擊，數(shù)字化所帶來的新理念和商業(yè)·企業(yè)“IT云化”實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型是時(shí)代發(fā)展之大勢，發(fā)展空間云計(jì)算發(fā)展已步入第二個(gè)十年，全球云計(jì)算市場趨于穩(wěn)定增長，我國云計(jì)算市場處于高速增長階段。中國信息通信研究院在2019年7月發(fā)布的《2019年云計(jì)算發(fā)展白皮書》中指出：2018年我國云計(jì)算整體市場規(guī)模達(dá)962.8億元，增速39.2%,我國公有云市場將保持50%以上增長，預(yù)計(jì)2018～2022年仍將保持快速增長態(tài)勢，到2022年公有云市場規(guī)模將達(dá)到1731億元，私有云市場規(guī)模將達(dá)到1172億元。企業(yè)在數(shù)字化轉(zhuǎn)型過程中，要以最快的速度應(yīng)對IT新環(huán)境、用戶需求以及競爭對手帶來的挑戰(zhàn)。2014年，Gartner就提出了“雙模IT”的理念——一個(gè)維穩(wěn)一個(gè)圖新，雙軌部分。第一個(gè)部分即為傳統(tǒng)的IT架構(gòu)，傾向于按部就班的工作，確保企業(yè)業(yè)務(wù)平穩(wěn)運(yùn)行；第二個(gè)部分則采用了敏捷開發(fā)、快速迭代的方式，應(yīng)對最新的挑戰(zhàn)。1.1.2云計(jì)算時(shí)代的IT架構(gòu)特點(diǎn)企業(yè)使用IT架構(gòu)的歷史，從最初大型機(jī)的集中式計(jì)算架構(gòu)到以服務(wù)方式提供計(jì)算能力的云架構(gòu)，走過了幾十年的歷程，每次IT系統(tǒng)升級的變革，都帶動了生產(chǎn)力和企業(yè)管理的變革與發(fā)展。企業(yè)IT系統(tǒng)的發(fā)展歷史如圖1-1所示。從20世紀(jì)60年代中期開始，一些企業(yè)開始使用大型機(jī)。大型機(jī)的使用門檻和成本很高，只有極少數(shù)企業(yè)能夠使用。從20世紀(jì)80年代開始，PC和小型機(jī)出現(xiàn)，企業(yè)通過購買硬件獲得計(jì)算和存儲能力，但存在架構(gòu)不靈活、資源利用率不高、易被廠家鎖定而不可控等問題。從20世紀(jì)90年代中期開始，企業(yè)開始在互聯(lián)網(wǎng)數(shù)據(jù)中心托管和租用硬件，風(fēng)、火、水、電由數(shù)據(jù)中心提供和保障，但是計(jì)算設(shè)備以及計(jì)算系統(tǒng)還需要企業(yè)自身提供，計(jì)算能力依然被少數(shù)大企業(yè)占有。從2000年開始出現(xiàn)去IOE技術(shù)浪潮，通用x86服務(wù)器成了IT基礎(chǔ)架構(gòu)的絕對主流技術(shù)?，F(xiàn)已進(jìn)入云架構(gòu)時(shí)代，以服務(wù)方式提供計(jì)算能力，按需獲取，降低使用門檻，使計(jì)算成為像水電一樣的社會公共基礎(chǔ)設(shè)施。近幾年隨著軟件的敏捷開發(fā)、持續(xù)支付、DevOps理論的發(fā)展和實(shí)踐，以及基于Docker等輕量級容器部署應(yīng)用和服務(wù)的成熟，微服務(wù)架構(gòu)日漸流行，已經(jīng)發(fā)展成為應(yīng)用架構(gòu)的未來演進(jìn)方向。通過服務(wù)的原子化拆分，微服務(wù)的獨(dú)立打包、部署和升級，可以使小團(tuán)隊(duì)敏捷交付，應(yīng)用的交付周期將縮短，運(yùn)營成本也將進(jìn)一步大幅下降。最新出現(xiàn)的函數(shù)計(jì)算更可免去管理底層基礎(chǔ)架構(gòu)的煩擾，讓研發(fā)更專注于業(yè)務(wù)功能設(shè)計(jì)和持續(xù)交付。容器PC和小型機(jī)數(shù)據(jù)中心靜態(tài)應(yīng)用和架構(gòu)復(fù)雜應(yīng)用復(fù)雜應(yīng)用t客戶端服務(wù)器架構(gòu)架構(gòu)圖1-1企業(yè)IT系統(tǒng)的發(fā)展歷史1.1.3云計(jì)算時(shí)代的IT管理變革云架構(gòu)的彈性帶來資源的集約化，實(shí)現(xiàn)按需使用、按需付費(fèi)以及高質(zhì)量的專業(yè)運(yùn)維帶來了計(jì)算的服務(wù)化。通過IT集中式架構(gòu)向分布式云架構(gòu)的轉(zhuǎn)型優(yōu)化，能夠支撐高并發(fā)、高性能的架構(gòu)需求，使企業(yè)能夠放心地?fù)肀Щヂ?lián)網(wǎng)，能夠進(jìn)行基于互聯(lián)網(wǎng)、大數(shù)據(jù)的業(yè)務(wù)創(chuàng)新，也為IT管理帶來全新的變化。1.企業(yè)IT投入模式改變在傳統(tǒng)的IT投入模式下，基礎(chǔ)設(shè)施(機(jī)房、電力、帶寬、主機(jī)、存儲、網(wǎng)絡(luò)、數(shù)據(jù)庫、中間件)的投入占比最大，服務(wù)器運(yùn)維人工成本次之，應(yīng)用開發(fā)的投入占比最小。上云后，投入比例正好相反，基礎(chǔ)設(shè)施租用成本最少，運(yùn)維的人工成本也將大量下降，這樣可以把更多的資金投入到業(yè)務(wù)開發(fā)上面，企業(yè)可以快速滿足業(yè)務(wù)的需求。企業(yè)遷云前后投入的變化如圖1-2所示。2.IT人員能力要求的變化云計(jì)算時(shí)代對IT人員能力的要求也將發(fā)生變化。傳統(tǒng)IT環(huán)境中人員更關(guān)注底層基礎(chǔ)設(shè)施的運(yùn)維、項(xiàng)目管理，對業(yè)務(wù)需求的理解和響應(yīng)比較被動。云計(jì)算中IT人員需要更關(guān)注業(yè)務(wù)的需求，探索新的業(yè)務(wù)模式，主動發(fā)現(xiàn)客戶需求，尋找新的技術(shù)和解決方案，而不僅僅關(guān)注底層平臺的運(yùn)維和資源管理。比如，以往IT人員遇到一個(gè)系統(tǒng)的問題，在解決問題的同時(shí)往往要搞清楚問題發(fā)生的根本原因是什么,以避免再次發(fā)生類似的問題。在云計(jì)算環(huán)境下，這種思路發(fā)生了根本性改變，“創(chuàng)建比修復(fù)更容易”,只需要迅速下線或釋放有問題的資源，同時(shí)開通相對應(yīng)的新資源。企業(yè)IT人員需要做的是準(zhǔn)備好問題發(fā)生時(shí)的預(yù)案并有效執(zhí)行，至于問題產(chǎn)生的根因，可以留給云計(jì)算服務(wù)商的工程師去思考和研究。應(yīng)用系統(tǒng)開發(fā)費(fèi)應(yīng)用系統(tǒng)開發(fā)費(fèi)人工成本云基礎(chǔ)設(shè)施租開發(fā)費(fèi)IT廠商服務(wù)費(fèi)運(yùn)維人工成本投入基礎(chǔ)設(shè)施建設(shè)機(jī)房/電力/帶寬數(shù)據(jù)庫/中間件圖1-2企業(yè)遷云前后投入的變化3.關(guān)注用戶體驗(yàn)和業(yè)務(wù)指標(biāo)如果沒能詳細(xì)了解服務(wù)中各種行為的重要程度，不去度量這些行為的正確性，就無法正確維護(hù)這個(gè)應(yīng)用系統(tǒng)，更不要說保障系統(tǒng)可靠、穩(wěn)定地運(yùn)行了。那么,不管是對外的服務(wù)，還是內(nèi)部API,都需要制定一個(gè)針對用戶的服務(wù)質(zhì)量目標(biāo)，并且努力達(dá)到這個(gè)質(zhì)量目標(biāo)。在這個(gè)過程中，需要利用一些主觀判斷結(jié)合過去的經(jīng)驗(yàn)以及對于服務(wù)的理解來定義一些服務(wù)質(zhì)量指標(biāo)(SLI)、服務(wù)質(zhì)量目標(biāo)(SLO),以及服務(wù)質(zhì)量協(xié)議(SLA)。這三項(xiàng)分別是指該服務(wù)最重要的一些基礎(chǔ)指標(biāo)，這些指標(biāo)的預(yù)期值，以及當(dāng)指標(biāo)不符合預(yù)期時(shí)的應(yīng)對計(jì)劃。事先選擇合適的指標(biāo)有助于在故障發(fā)生時(shí)幫助維護(hù)團(tuán)隊(duì)更好地進(jìn)行決策，同時(shí)也為維護(hù)團(tuán)隊(duì)判斷系統(tǒng)是否正常工作提供幫助。評估是否違反SLA,如果違反就升級走流程。這樣既靈活，也有章可循。如果開發(fā)團(tuán)隊(duì)能力強(qiáng)，代碼質(zhì)量高或者運(yùn)氣好，可以快速迭代。反之，需要慢點(diǎn)來，大家都對線上系統(tǒng)負(fù)1.2云計(jì)算監(jiān)控的目標(biāo)和挑戰(zhàn)監(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è)問題：“出問了問題?”“是什么問題?”控。通過白盒監(jiān)控能夠了解其內(nèi)部的實(shí)際運(yùn)行狀態(tài)，觀察監(jiān)控指標(biāo)能夠預(yù)判可能出現(xiàn)的問可以在系統(tǒng)或者服務(wù)發(fā)生故障時(shí)快速通知相關(guān)人員進(jìn)行處理。通過建立完善的監(jiān)控體系，·長期趨勢分析：通過對監(jiān)控樣本數(shù)據(jù)的持續(xù)收集和統(tǒng)計(jì)，對監(jiān)控指標(biāo)進(jìn)行長期趨勢分析。例如，通過對磁盤空間增長率的判斷，我們可以提前預(yù)測在未來什么時(shí)間節(jié)點(diǎn)上需要·對照分析：兩個(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)生影響?！す收戏治雠c定位：當(dāng)問題發(fā)生后，需要對問題進(jìn)行調(diào)查和處理。通過對比分析不同監(jiān)控?cái)?shù)據(jù)與歷史數(shù)據(jù)，能夠找到并解決根源問題?！?shù)據(jù)可視化：通過可視化儀表盤能夠直接獲取系統(tǒng)的運(yùn)行狀態(tài)、資源使用情況，以及網(wǎng)站可靠性工程SRE(SiteReliabilityEngineer)的終極責(zé)任是確保該服務(wù)可以正常運(yùn)轉(zhuǎn)。為達(dá)成這個(gè)目標(biāo)，SRE定義了一套服務(wù)可靠性層級模型(如圖1-3所示),需要完成開發(fā)監(jiān)控系統(tǒng)、規(guī)劃容量、處理緊急事件、確保事故根源被跟蹤修復(fù)等一系列工作。產(chǎn)品設(shè)計(jì)產(chǎn)品設(shè)計(jì)軟件開發(fā)容量規(guī)劃測試+發(fā)布應(yīng)急事件處置監(jiān)控圖1-3服務(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ì)也就沒有了根要對基于現(xiàn)代基礎(chǔ)設(shè)施的應(yīng)用系統(tǒng)進(jìn)行監(jiān)控，將面臨DevOps實(shí)踐和基礎(chǔ)架構(gòu)代碼化，監(jiān)控系統(tǒng)將會迎接若干重大挑戰(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è)施資源變得更靈活?！ぷ詣踊腄evOps運(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ī)?！ぷ詣踊O(shè)置警報(bào)、告警和閾值。監(jiān)控配置過程是另一個(gè)化。當(dāng)提供一臺新服務(wù)器時(shí)，應(yīng)該在監(jiān)控系統(tǒng)中自動注冊這臺服務(wù)器；當(dāng)服務(wù)器停止使用挑戰(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)。這里要面臨部署在上百臺服務(wù)器上，依賴于網(wǎng)絡(luò)和存儲組件的支持。在實(shí)際環(huán)境中，把這些監(jiān)控信息·在云中，低層基礎(chǔ)設(shè)施和服務(wù)器之間有正常和異常的分配，例如，服務(wù)器漂移的終止操作、伸縮以及滾動升級，或者實(shí)例失效或者資源共享不穩(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)控錯(cuò)誤。這種方式也面臨挑戰(zhàn)：·發(fā)現(xiàn)問題時(shí)可能為時(shí)已晚。當(dāng)在上層注意到有錯(cuò)誤時(shí)，阻止影響的擴(kuò)大可能已經(jīng)來不·如何深入到低層數(shù)據(jù)?，F(xiàn)代分布式系統(tǒng)有內(nèi)置的容錯(cuò)機(jī)制來掩蓋故障和錯(cuò)誤，防止在系統(tǒng)層面出現(xiàn)問題直接影響用戶體驗(yàn)，因此，檢測到上層問題距離低層根本故障原因出現(xiàn)，·從最初發(fā)生故障到擴(kuò)散到整個(gè)系統(tǒng)并變得明顯，可能需要經(jīng)過很長一段時(shí)間。不能簡單地依賴上層錯(cuò)誤檢測的時(shí)間戳，也不能假設(shè)與原始問題相關(guān)的指標(biāo)和日志還仍然存在，挑戰(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í)間就會拉長。在微服務(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ù)很容易生成數(shù)百萬個(gè)事件以及指標(biāo)數(shù)據(jù)，每秒都會產(chǎn)生大量的日志。處理龐大的數(shù)據(jù)會面·在時(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í)再返回·應(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ò)誤。1.3云計(jì)算監(jiān)控的范圍和架構(gòu)1.3.1監(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)的。監(jiān)控體系架構(gòu)如圖1-4所示?！ぴ跇I(yè)務(wù)邏輯、應(yīng)用程序和運(yùn)行環(huán)境層級上收集數(shù)據(jù)，在每一層，以事件、日志和指標(biāo)為監(jiān)控對象。可以在所有服務(wù)器上使用特定文件來存儲日志，但最好將所有日志發(fā)送到公共日志服務(wù)中，這樣更利于聚合、查詢和清除。此外，在應(yīng)用程序棧的所有層級中收集指標(biāo)，能更好地了解系統(tǒng)的活動狀態(tài)。在操作系統(tǒng)級別，可以收集CPU、內(nèi)存、磁盤或網(wǎng)絡(luò)·事件路由器負(fù)責(zé)事件的存儲和轉(zhuǎn)發(fā)：支持監(jiān)控可視化、趨勢分析、告警、異常檢測等。通過采集、存儲和聚合所有監(jiān)控信息，能實(shí)現(xiàn)更深入的分析和健康檢查。事件路由器用于存儲與服務(wù)(和它們支持的應(yīng)用程序與運(yùn)行環(huán)境)有關(guān)的配置，可以實(shí)現(xiàn)基于閾值的告警存儲圖形化告警業(yè)務(wù)邏輯應(yīng)用程序操作系統(tǒng)事件路由器監(jiān)控體系架構(gòu)監(jiān)控體系架構(gòu)圖1-4監(jiān)控體系架構(gòu)監(jiān)控管理的范圍包括構(gòu)成資源服務(wù)的所有IT資源，云計(jì)算環(huán)境下的監(jiān)控對象除了包括傳統(tǒng)的資源，還包括對虛擬化資源的監(jiān)控。監(jiān)控系統(tǒng)通常的基本架構(gòu)如圖1-5所示。被監(jiān)控的系統(tǒng)可以是獨(dú)立的應(yīng)用程序或服務(wù)的集合，也可以是單獨(dú)的應(yīng)用程序。如果系統(tǒng)主動地提供了被監(jiān)控的數(shù)據(jù)，那么監(jiān)控是入侵式的且影響系統(tǒng)設(shè)計(jì)；如果系統(tǒng)不主動提供被監(jiān)控的數(shù)據(jù)，那么監(jiān)控是非入侵的。外部系統(tǒng)可以通過健康檢查、性能或事務(wù)監(jiān)控來監(jiān)控系統(tǒng)或者應(yīng)用級別的狀態(tài)。據(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ù)庫可能會導(dǎo)致網(wǎng)絡(luò)阻塞，因此，在設(shè)計(jì)監(jiān)控架構(gòu)時(shí)，選擇從本地節(jié)點(diǎn)到中心數(shù)據(jù)庫之間的中間步驟以及在系統(tǒng)2無代理證維人員圖1-5監(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))都可以訂前面簡單介紹了監(jiān)控系統(tǒng)的基本架構(gòu)，與之相關(guān)的解決方案已經(jī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)系并跟蹤動態(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)成熟度各級的輸入與輸出，如圖1-6所示。圖1-6監(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è)施，都可以采用更加主動的監(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、ZenossCore、Ganglia、OpenTSDB等),每種軟件都有自己的特點(diǎn)和功能，有各自的側(cè)重點(diǎn)和目標(biāo)，然而，在設(shè)計(jì)理念和實(shí)現(xiàn)方法上都大同小異，具有共同特征。例如，都具有采集數(shù)據(jù)、分析展示、告警以及簡單的故障自動處理等環(huán)節(jié)。下面簡單介紹監(jiān)控系統(tǒng)發(fā)展演進(jìn)過程中出現(xiàn)的兩個(gè)最常用的開源軟件。Zabbix是一個(gè)基于Web界面的提供分布式系統(tǒng)監(jiān)視以及網(wǎng)絡(luò)監(jiān)視功能的企業(yè)級開源解決方案，其工作數(shù)據(jù)流如圖1-7所示。conflog.conflogconfe圖1-7Zabbix工作數(shù)據(jù)流Zabbix能監(jiān)視各種網(wǎng)絡(luò)參數(shù)，保證服務(wù)系統(tǒng)的安全運(yùn)營，并提供良好的通知機(jī)制使系統(tǒng)管理員能夠快速定位/解決存在的各種問題。Zabbix由兩部分構(gòu)成——Zabbixserver與可選組件Zabbixagent。Zabbixserver可以單獨(dú)監(jiān)視遠(yuǎn)程服務(wù)器的服務(wù)狀態(tài)；同時(shí)也可以與Zabbixagent配合，可以輪詢Zabbixagent主動接收監(jiān)視數(shù)據(jù)，還可被動接收等多種協(xié)議，將采集到的數(shù)據(jù)存放到數(shù)據(jù)庫，然后對其進(jìn)行分析整理，若達(dá)到條件觸發(fā)則告警。Zabbix支持二次開發(fā)，其靈活的擴(kuò)展性和豐富的功能是其他監(jiān)控系統(tǒng)所不能比擬OpenTSDB通過HBase存儲所有的時(shí)序(無須采樣)來構(gòu)建一個(gè)分布式、可伸縮的時(shí)間序列數(shù)據(jù)庫。它支持秒級數(shù)據(jù)采集所有指標(biāo)，支持永久存儲，可以做容量規(guī)劃，并可很容易地接入現(xiàn)有的報(bào)警系統(tǒng)。OpenTSDB可以從大規(guī)模的集群(包括集群中的網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應(yīng)用程序)中獲取相應(yīng)的指標(biāo)，并進(jìn)行存儲、索引以及服務(wù)，從而使這些數(shù)據(jù)更集，這是之前其他監(jiān)控系統(tǒng)很難實(shí)現(xiàn)的。因得益于其存儲系統(tǒng)的選擇，它支持大數(shù)據(jù)分析，在大型的基礎(chǔ)設(shè)施監(jiān)控中也得到較為廣泛的使用。CNetworkPrometheus(普羅米修斯，有時(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é)同。Prometheus是由SoundCloud開發(fā)的開源監(jiān)控報(bào)警系統(tǒng)和時(shí)序數(shù)據(jù)庫(TimDatabase,TSDB)。PrometheusGoogle的Brog系統(tǒng)演變而來的),從2012年開始由前Google工程師在SoundCloud以開源軟件的形式進(jìn)行研發(fā)，并且于2015年初對外發(fā)布早期版本。2016年5月繼Kubernetes之后成為第二個(gè)正式加入CNCF基金會的項(xiàng)目，同年6月正式發(fā)布1.0版本。2017年底發(fā)布了基于全新存儲層的2.0版本，能更好地與容器平臺、云平臺配合。2018Prometheus歷史故事從前，在加利福尼亞州山景城有一家公司，名為Google。該公司經(jīng)營著一系列產(chǎn)品，最著名的是廣告ERM搜索引擎平臺。為了運(yùn)行這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(備注：Borg和Borgmon都從未公開過。直到最近，人們才了解Prometheus的靈感來自Google的Borgmon。MattT.Proud(前Google員工)最初將其作為研究項(xiàng)目開發(fā)的。在Proud加入SoundCloud之后，他與另一位工程師JuliusVolz最終在2015年1月發(fā)布了公開版本。多公司采納，通常用于類似的監(jiān)控，但也用于監(jiān)控更傳統(tǒng)的體系結(jié)構(gòu)。2.成為開源社區(qū)熱點(diǎn)、監(jiān)控主流Prometheus使用開源的Go語言編寫，并且在Apache2.0許可下授權(quán)，該項(xiàng)目有著非常活躍的開發(fā)者和用戶社區(qū)?，F(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ù)都可控，并能很快定位到問題。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、NgiPrometheus關(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天。/metries圖1-9Prometheus設(shè)計(jì)理念Prometheus還有一個(gè)推送網(wǎng)關(guān)，可以用來接收少量數(shù)據(jù)，例如獲取不能被直接抓取的監(jiān)控目標(biāo)的指標(biāo)數(shù)據(jù)。Network傳統(tǒng)的監(jiān)控解決方案需要多種監(jiān)控工具組合，如圖1-10所示。圖1-10傳統(tǒng)復(fù)雜的多種監(jiān)控手段組合和其他監(jiān)控系統(tǒng)相比，Prometheus功能強(qiáng)大，可以監(jiān)控所有層級的指標(biāo)(見表1-1),簡化了監(jiān)控復(fù)雜度(如圖1-11所示)。監(jiān)控指標(biāo)(示例)應(yīng)用時(shí)延、鋯誤、查詢量、內(nèi)部狀態(tài)等白己代碼埋點(diǎn)資源使用、性能特性等主機(jī)(OS,硬件)網(wǎng)絡(luò)圖1-11Prometheus監(jiān)控解決方案，簡化系統(tǒng)部署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ù)庫、緩存等)。唯一需要的就是本地磁盤，因此不會有潛在關(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)能力動態(tài)地管理監(jiān)控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ī)制自動發(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)，用戶可以3.靈活的數(shù)據(jù)模型在Prometheus里，監(jiān)控?cái)?shù)據(jù)是由值、時(shí)間戳和標(biāo)簽表組成的，其中，監(jiān)控?cái)?shù)據(jù)的源信這些數(shù)據(jù)，還提供了PromBench基準(zhǔn)測試。在硬件資源滿足的情況下，對于單實(shí)例Prometheus可以處理數(shù)以百萬的監(jiān)控指標(biāo)以及數(shù)十萬個(gè)數(shù)據(jù)點(diǎn)。數(shù)，大部分情況下用戶都可以直接通過PromQPromQL也可應(yīng)用于數(shù)據(jù)可視化(如GraPrometheus架構(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)行集成。目(SDK),基于這些SDK可以很容易地將應(yīng)用程序納入到Prometheus的監(jiān)控中，或者開發(fā)自己的監(jiān)控?cái)?shù)據(jù)收集程序。同時(shí)，Prometheus還支持與其他監(jiān)控系統(tǒng)進(jìn)行集成，如Graphite、Statsd、CollecPrometheus的情況下，采用Prometheus的clientlibPrometheus社區(qū)提供了大量第三方實(shí)現(xiàn)的監(jiān)控?cái)?shù)7.可視化Prometheus服務(wù)器中自帶了一個(gè)PrometheusUI,通過這個(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)控的所有需求，具體的不1.6本章小結(jié)本章從云計(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ā)，簡單介紹了下一章將詳細(xì)介紹Prometheus的架構(gòu)和組件，然后快速部署、運(yùn)行一個(gè)簡單的Prometheus監(jiān)控系統(tǒng)，使讀者對Prometheus有一個(gè)感性的認(rèn)識。更多閱讀材料[1]中國信息通信研究院.云計(jì)算發(fā)展白皮書(2019年)[P/OL].2019-7./a/[2]肖建一.中國云數(shù)據(jù)中心運(yùn)營指南[M].北京：清華大學(xué)出版社，2013.[3]LenBass,等.DevOps軟件架構(gòu)師行動指南[M].胥峰，等譯.北京：機(jī)械工業(yè)出版社，2017.[4]國務(wù)院發(fā)展研究中心課題組.傳統(tǒng)產(chǎn)業(yè)數(shù)字化轉(zhuǎn)型的模式和路徑[P/OL].2018-[5]BetsyBeyer,等.SRE:Google運(yùn)維解密[M].孫宇聰，譯.北京：電子工業(yè)出版社，2016.[6]EricCarter.examplesofPrometheus第2章Prometheus基本概念及部署本章深入闡述Prometheus生態(tài)圈系統(tǒng)中的核心組件及其整體架構(gòu)內(nèi)容，并對所涉及的相關(guān)概念進(jìn)行介紹。在傳統(tǒng)主機(jī)和Docker環(huán)境中，對Prometheus進(jìn)行快速部署操作，為后續(xù)全面掌握Prometheus在傳統(tǒng)業(yè)務(wù)和云中對各個(gè)應(yīng)用環(huán)境的監(jiān)控和告警做好知識儲備。2.1Prometheus架構(gòu)圖2-1為官方提供的Prometheus體系架構(gòu)及其生態(tài)圈系統(tǒng)組件。pulljsbsjohspagerditypishcotifyNude圖中展示了Prometheus的整體架構(gòu)設(shè)計(jì)理念，中心化數(shù)據(jù)采集和分析。其關(guān)鍵的工作·Prometheus服務(wù)器周期性地或在設(shè)定的時(shí)間段內(nèi)，可以通過以下方式獲取內(nèi)容?！囊呀?jīng)配置好的job或者exporter中拉取metric?！rometheus服務(wù)器獲取到數(shù)據(jù)后存儲在本地(也可以選擇遠(yuǎn)端存儲),通過一定規(guī)則對數(shù)據(jù)進(jìn)行清理和整理，并且把結(jié)果存儲到新的時(shí)間序列中?！rometheus服務(wù)器定時(shí)查詢已經(jīng)定義好的規(guī)則，若發(fā)現(xiàn)滿足定義的觸發(fā)條件，便將alert信息推送至已配置好的Alertmanager。·Alertmanager收到alert信息后，根據(jù)配置文件對接收到的alert信息進(jìn)行處理(聚合、去重、降噪),然后將它們轉(zhuǎn)換為網(wǎng)頁、電子郵件和其他通知方式發(fā)出告警?！ぷ詈笸ㄟ^PromQL或其他API可視化地展示收集的數(shù)據(jù)，例如自帶Prometheus在記錄純數(shù)字時(shí)間序列方面表現(xiàn)得非常優(yōu)秀。它既適用于對服務(wù)器硬件各項(xiàng)指標(biāo)的監(jiān)控，也適用于對高度動態(tài)的面向服務(wù)架構(gòu)的監(jiān)控。在當(dāng)下比較火的微服務(wù)生態(tài)圈中，它對多維數(shù)據(jù)收集和查詢的支持具有特殊的優(yōu)勢。Prometheus的基本原理是通過HTTP協(xié)議周期性獲取被監(jiān)控組件的狀態(tài)信息，任意組件Prometheus可以更好地適應(yīng)虛擬化，如VM或Docker容器的環(huán)境集成。當(dāng)使用者監(jiān)控的服務(wù)出現(xiàn)故障時(shí)，它可以快速定位和診斷問題。每個(gè)Prometheus服務(wù)器都是獨(dú)立的，不依賴于網(wǎng)絡(luò)存儲或其他遠(yuǎn)程服務(wù)。當(dāng)基礎(chǔ)架構(gòu)的其他部分損壞時(shí)，可以快速恢復(fù)，并且不需要設(shè)置大量的基礎(chǔ)依賴架構(gòu)。與此同時(shí)，Prometheus也有不適用的應(yīng)用場景，例如，使用者要求統(tǒng)計(jì)數(shù)據(jù)100%的精確，那么它并不適用，因?yàn)樗占臄?shù)據(jù)還是有可能不夠詳細(xì)和完整，例如精準(zhǔn)實(shí)時(shí)計(jì)費(fèi)首先我們對Prometheus進(jìn)行快速部署，使其啟動正常運(yùn)行，然后通過Prometheus自帶的一個(gè)比較簡單的WebUI查看表達(dá)式搜索結(jié)果。Prometheus官方給出了多種部署方法，如使用Docker容器，還提供了使用第三方配置管理工具Ansible、Chef和Saltstack進(jìn)行安裝的案例地址，這些都可以在官方文檔中找到，感興趣的讀者可以進(jìn)行相關(guān)測試安裝。官方網(wǎng)站還為用戶提供了二進(jìn)制文件。如果沒有特殊定制代碼的需求，直接使用二進(jìn)制文件進(jìn)行部署是一種比較簡便的方法，因?yàn)镻rometheus是基于Go語言編寫的，編譯后的軟件包不依賴第三方的內(nèi)容。用戶完整下載自己所需要的版本，在系統(tǒng)中解壓軟件包并做簡單的基礎(chǔ)配置，之后就可以正常啟動Prometheus服務(wù)，開始我們的Prometheus云原生這里我們選擇二進(jìn)制文件安裝包進(jìn)行快速部署。在安裝之前，首先在官方網(wǎng)站下載頁面地址https://prometheus.io/download/中找到Prometheus下載列表。在這里可以適用于各平臺的二進(jìn)制文件最新版本?；蛘?，也可以直接在官方的PrometheusGitHub下載頁面地址/prometheus/prometheus/releases特定版本，以及對應(yīng)平臺的二進(jìn)制文件。下面我們開始Prometheus的安裝部署工作。2.快速部署#sha256sumprometheus-2.4.0.linux-amd64.tar.gz與官網(wǎng)提供的軟件包類表中“SHA256Checksum”列里的哈希值進(jìn)行核對，保證下載的Prometheus軟件包的完整性。2)解壓縮二進(jìn)制軟件包到指定的安裝目錄，運(yùn)行Prometheus,操作如下：#tar-zxvfprometheus-2.4.0.linux-amd64.tar.gz-C/data#這里安裝在/data目錄下#cd/data#注意核對個(gè)人安裝目錄#chown-Rroot:rootprometheus-2.4.0.linux-#ln-svprometheus-2.4.0.linux-amd64prometheus3)啟動Prometheus。我們進(jìn)行快速部署，目的是盡快看到一個(gè)Prometheus監(jiān)控環(huán)境，所以不對Prometheus服務(wù)同級目錄下的prometheus.yml配置文件進(jìn)行詳細(xì)說明和配置修改，后續(xù)第3章會進(jìn)一步介紹配置文件的使用。然后，我們運(yùn)行與默認(rèn)配置文件同級目錄下的Prometheus執(zhí)可以看到以下輸出信息，由于本書篇幅緣故，這里只截取了Prometheus啟動時(shí)輸出日志的部分內(nèi)容，省略了日志格式中開頭類似“l(fā)evel=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從截取的日志中，我們找到加粗標(biāo)記字體的信息，可以看到prometheus服務(wù)已經(jīng)成功啟動，且默認(rèn)監(jiān)聽端口9090已經(jīng)開啟，如果想更換默認(rèn)監(jiān)控端口，需要啟動時(shí)添加配置用./prometheus-h查看相關(guān)幫助信4)添加Prometheus為系統(tǒng)服務(wù)開機(jī)啟動。此時(shí)，當(dāng)終端關(guān)閉或按下Ctrl+C時(shí)，Prometheus服務(wù)會自動關(guān)閉，這不是我們想要的工作方式。熟悉Linux系統(tǒng)的讀者可以在Prometheus當(dāng)前目錄下，直接執(zhí)行命令：nohup./prometheus&使其后臺進(jìn)行運(yùn)行即可。但是，我們要對進(jìn)程執(zhí)行關(guān)閉、重新啟動、查看進(jìn)程狀態(tài)等操作時(shí)，還需配合各種Linux命令才能完成。這里為了方便，將Prometheus添加為系統(tǒng)服務(wù)且開機(jī)自啟動。可以使用CentOSLinuxrelease7操作系統(tǒng)中的命令systemctl來管理守護(hù)進(jìn)程#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文件中選項(xiàng)內(nèi)容語義都比較清晰直觀，在使用文件過程中，根據(jù)各自部署環(huán)境可能需要對選項(xiàng)做出修改，如表2-1所示。說明ExecStart--datw/prometheusprom-storage.tsdb.path"/data/prometheu--web.console.templates="/data/prometheus/co用于生成返回Prometheus的相對和絕可以在后續(xù)告警通知內(nèi)容中直接點(diǎn)擊鏈接地址訪問-web.listen-address":9090*Prometheus默認(rèn)監(jiān)控端口表2-1可修改的選項(xiàng)及說明如果有讀者朋友仍舊有疑惑，可以通過./prometheus-h查看幫助內(nèi)容。但需要注意的是，由于筆者是內(nèi)網(wǎng)測試環(huán)境，以上默認(rèn)使用了root用戶和組。建議大家使用非root用戶權(quán)限，讀者可以根據(jù)實(shí)際使用環(huán)境指定用戶權(quán)限，例如使用prometheus用戶，當(dāng)然前提是需要個(gè)人在系統(tǒng)中創(chuàng)建此用戶。最后，配置文件完成且保存退出，需要通知systemdstartprometheus.servicestatusprometheurestartprometheus.ser#開啟服務(wù)#查看狀態(tài)為Active:active(running)#重啟服務(wù)#停止服務(wù)至此，我們完成了Prometheus的快速安裝工作，并添加了系統(tǒng)服務(wù)、設(shè)置了開機(jī)啟動Prometheus所在的Target是multi-user.target。這個(gè)設(shè)置非常重要，因?yàn)閳?zhí)行systemctlenableprometheus.service命令設(shè)置一個(gè)符號鏈接，就會放在/etc/systemd/system目錄下面的multi-user.target.wants目錄之中。Prometheus啟動腳本中用到了systemd的service·[Unit],提供服務(wù)描述信息、啟動順序與依賴關(guān)系。·[Service],服務(wù)的關(guān)鍵部分，設(shè)置服務(wù)運(yùn)行時(shí)使用的一些具體參數(shù)?！fter,服務(wù)類別描述，定義unit的啟動次序?！ype,設(shè)置進(jìn)程啟動類型，其類型有：·simple:默認(rèn)值，執(zhí)行ExecStart指定的命令，啟動為主進(jìn)程?！orking:進(jìn)程將在啟動過程中使用fork()系統(tǒng)調(diào)用，創(chuàng)建后父進(jìn)程立即退出，而子·dbus:類似于simple,但會等待D-Bus信號后啟動?！otify:當(dāng)前服務(wù)啟動完畢，通知systemd再繼續(xù)往下執(zhí)行?！xecStartPre:在ExecStart之前執(zhí)行的命令，語法規(guī)則與ExecStart=完全相同?！xecStartPost:在ExecStart之后執(zhí)行的命令，語法規(guī)則與ExecStart=完全相同?！xecReload:可選指令，設(shè)置服務(wù)被要求重新載入配置時(shí)所執(zhí)行的命令行?！xecStop:可選指令，設(shè)置停止服務(wù)要運(yùn)行的命令或腳本?？梢栽O(shè)置如下值：·no(默認(rèn)值):退出后不會重啟?！n-success:只有正常退出時(shí)(退出狀態(tài)碼為0),才會重啟。·on-failure:非正常退出時(shí)(退出狀態(tài)碼非0),包括被信號終止和超時(shí)，才會重啟?！lways:不管是什么退出原因，總是重啟。[Install]區(qū)塊常用選項(xiàng)：·Alias:可用于啟動的別名。3.熱加載更新配置在Prometheus的日常維護(hù)中，一定會對配置文件prometheus.yml進(jìn)行再編輯操作，通常對Prometheus服務(wù)進(jìn)行重啟動操作即可完成對配置文件的加載。當(dāng)然也可以通過動態(tài)的熱加載來更新prometheus.yml中的配置信息，一般熱加載有兩種方法：#curl-XPOSThttp://localhost:9090/-/reload若使用第二種方式進(jìn)行熱加載操作，需要在Prometheus服務(wù)啟動時(shí)指定--web.enable-lifecycle,添加到以上的Prometheus自啟動文件中使用。無論使用哪種熱加載方式，要想熱加載更新配置文件成功，必須保證配置信息填寫正確。這里可以通過Prometheus提供的工具promtool對prometheus.yml配置文件進(jìn)行提前核關(guān)于promtool工具其他的使用方法，可以利用#./promtool-h進(jìn)行查看。Prometheus服務(wù)鏡像。在安裝前，首先要確保個(gè)人安裝環(huán)境已經(jīng)完成了Docker的安裝，如果沒有Docker環(huán)境，則需要根據(jù)Docker官方或其他資料完成對應(yīng)平臺的Dock現(xiàn)在，我們開始Prometheus安裝操作，執(zhí)行安裝命令，安裝最新版本；#dockerrun—nameprometheus-p9090安裝完成后，終端顯示以默認(rèn)配置文件為示例的Prometheus啟動信息，并開啟映射端口9090對外進(jìn)行監(jiān)聽?？梢允褂肈ocker命令進(jìn)行一些基礎(chǔ)的操作：#dockerps-fnames=prometheusCONTAINERIDIMAGE...STATUSPORTS5fd51542a6a4prom/prometheus..Up2#dockerstartprometheus#啟動已經(jīng)停止的prometheus容器#dockerstatsprometheus#查看prometheus容器狀態(tài)#dockerrestartprometheus#重啟prometheus容器#dockerstopprometheus#停止運(yùn)行的prometheus容器對于生產(chǎn)環(huán)境部署，強(qiáng)烈建議使用數(shù)據(jù)卷容器模式來簡化對Prometheus升級數(shù)據(jù)的管理。例如，使用Docker綁定數(shù)據(jù)卷功能，映射prometheus.yml配置文件到主機(jī)指定的路徑下。這里我們不做具體的操作演示，感興趣的讀者可以自己對Prometheus容器數(shù)據(jù)卷至此，我們已經(jīng)在物理主機(jī)環(huán)境或使用Docker容器快速部署好了Prometheus系統(tǒng)環(huán)境，需要注意的是防火墻要開通對外提供訪問的9090端口。如果使用CentOSLinuxrelease7操作系統(tǒng)進(jìn)行Prometheus安裝，要注意設(shè)置SeLinux狀態(tài)內(nèi)容。完成這些工作后，我們便可以通過瀏覽器使用PrometheusWebUI,即在瀏覽器中輸入http://IP:9090格式便可進(jìn)行訪問。例如，依據(jù)以上安裝時(shí)的應(yīng)用信息，訪問示例地址http://7:9090,此時(shí)默認(rèn)訪問的頁面是Graph頁面，如圖2-2所示。accuratetimeandtimednttmightcauseunexpectedqueryresuExpression(pressShit+EElement圖2-2PrometheusWebUIGraph頁面注意，圖中的“Warning”提示信息，這是由于瀏覽器主機(jī)與Prometheus服務(wù)器之間時(shí)間不一致造成的。需要對瀏覽器主機(jī)或Prometheus服務(wù)器進(jìn)行時(shí)間同步。在時(shí)間同步完成后，再次訪問http://192.168.24.17:9090,警告自動消失。如圖2-3所示。Prometheus本身是自帶導(dǎo)出器(exporter)的，現(xiàn)在可以在WebUI中查看exporter采集到具體數(shù)據(jù)，例如，在查詢框中輸入U(xiǎn)P,點(diǎn)擊“Execute”按鈕后，會在Console選項(xiàng)卡中顯示Prometheus服務(wù)在線狀態(tài)的“UP”信息，如圖2-4所示。PrometheusPrometheus1圖2-4PrometheusUP狀態(tài)若點(diǎn)擊“Graph”選項(xiàng)卡，則展示“UP”狀態(tài)，如圖2-5所示。PrometheusAlertsGraphStatusHExecule-insertmetncatc210圖2-5PrometheusUP狀態(tài)視圖最后，通過訪問7:9090/targets地址，可以查看頁面中的Targets信息。示例中使用默認(rèn)配置文件，僅僅對Prometheus本機(jī)進(jìn)行監(jiān)控，如圖2-6nttp/Aocalhost90900圖2-6Targets頁面信息Prometheus內(nèi)部默認(rèn)提供許多metric(指標(biāo))用于監(jiān)控操作，這些指標(biāo)都可以在Web我們直接點(diǎn)擊圖2-6中提供的鏈接即可訪問Metrics信息，但示例中是默認(rèn)配置文件，需信息。由于內(nèi)容比較多，這里僅展示部分輸出信息；#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節(jié)中，其實(shí)我們已經(jīng)涉及了一些概念詞匯，本節(jié)我們將對Prometheus中的Datamodel(數(shù)據(jù)模型)、metric類型以及Job和Instance等相關(guān)概念進(jìn)行說明，便于讀者Prometheus將所有數(shù)據(jù)存儲為時(shí)間序列(timeseries)數(shù)據(jù)，每個(gè)時(shí)間序列數(shù)據(jù)都具有帶時(shí)間戳的數(shù)據(jù)流，數(shù)據(jù)流都由其指標(biāo)(metric)名稱和一組鍵值對(也稱為標(biāo)簽(label))唯一標(biāo)識，即不同的標(biāo)簽代表不同的時(shí)間序列。我們可以基于這些標(biāo)簽很容metric即指標(biāo)，指定監(jiān)控目標(biāo)系統(tǒng)測量特征，可以理解為定義了某個(gè)監(jiān)控指標(biāo)類型名稱。指標(biāo)是隨時(shí)間將數(shù)據(jù)點(diǎn)鏈接在一起的標(biāo)識符，是Prometheus的核心概念之一。Prometheus會將指標(biāo)存儲在其時(shí)間序列數(shù)據(jù)庫中，可以對它們進(jìn)行查詢操作，以了解被監(jiān)控目標(biāo)隨時(shí)間的變化情況。指標(biāo)名稱可以由ASCII字母、數(shù)字、下劃線和冒號組成，但應(yīng)該以字母開頭，后面可以跟任意數(shù)量的字母、數(shù)字和下劃線。而[a-zA-Z:][a-zA-ZO-9:]*是有效指標(biāo)的正則表達(dá)式。注意：冒號“:”是為用戶定義的記錄規(guī)則保留的。當(dāng)有多個(gè)服務(wù)公開相同的指標(biāo)時(shí)，為了對其進(jìn)行區(qū)下幾個(gè)字段組成：·任意數(shù)量的標(biāo)簽，當(dāng)然也可以是零個(gè)，表示為鍵值(key-value)其實(shí)在2.2.3小節(jié)中，我們通過瀏覽器訪問Prometheus示例端點(diǎn)http://7:9090/metrics,查看抓取的Prometheus指標(biāo)，其開始內(nèi)容如下：go_gc_duration_seconds{quantile="0.75"}0.label即標(biāo)簽，支持Prometheus的維度數(shù)據(jù)模型，是一個(gè)關(guān)鍵部分。相同監(jiān)控指標(biāo)名稱的任何給定標(biāo)簽組合，都會標(biāo)識該指標(biāo)的特定維度實(shí)例化，基于這些維度，Prometheus可以使用查詢語言對數(shù)據(jù)進(jìn)行過濾和聚合。更改任何標(biāo)簽值，包括添加或刪除標(biāo)簽，都將標(biāo)簽名稱可以包含ASCII字母、數(shù)字和下劃線，需要以字母a-z或A-Z開頭，然后跟字劃線)開頭的標(biāo)簽名稱，只能在系統(tǒng)內(nèi)部使用。標(biāo)簽值可以是任何UTF-8字符，也可以為空，但是在Prometheus服務(wù)器中，標(biāo)簽值為空可能令人困惑，因?yàn)榭雌饋砭拖駴]有這個(gè)標(biāo)簽一樣。sample即樣本，按照某個(gè)時(shí)序以時(shí)間維度采集的數(shù)據(jù)，有序的樣本形成了實(shí)際的時(shí)間notation即符號，Prometheus時(shí)序格式和OpenTSDB類似，是用符號表示時(shí)間序列的。在指定一個(gè)指標(biāo)和一個(gè)或一組標(biāo)簽時(shí)，時(shí)間序列通常使用以下格式標(biāo)識： 監(jiān)控指標(biāo)名稱(metricname)用來說明被監(jiān)控樣本怎么稱呼，標(biāo)簽反映的是當(dāng)前樣本method="POST"和handler="/messages"的時(shí)間序列可以這樣寫：2.3.2Metric的四種類型Prometheus客戶端庫提供了四種核心指標(biāo)類型。目前，它們僅在客戶端庫(以支持針對特定類型的使用而定制的API)和wire"協(xié)議中有所區(qū)別。Prometheus服務(wù)器還沒有充分使用這些類型信息，未來官方在這方面會持續(xù)改進(jìn)?！ぶ貑⑦M(jìn)程后，會被重置，例如在微服務(wù)架構(gòu)中，服務(wù)實(shí)例是短暫的，在滾動更新、自動縮放等操作時(shí)，計(jì)數(shù)器就會被重置為0。該指標(biāo)類型通常用于跟蹤事件的數(shù)量或大小，可以用它來記錄服務(wù)請求次數(shù)、任務(wù)完成數(shù)、錯(cuò)誤發(fā)生次數(shù)。常用的場景有接口請求次數(shù)、操作重試次數(shù)和消息隊(duì)列數(shù)量等。對于命名Counter類指標(biāo)的最佳做法是使用_total后綴，例如，用戶和系統(tǒng)CPU總時(shí)間監(jiān)控在實(shí)際應(yīng)用場景中，大部分指標(biāo)為Counter類型，因?yàn)樵擃愋筒粫趦纱尾杉g隔中丟失信息，所以它是推薦使用比較多的指標(biāo)類型。有些數(shù)據(jù)的值可能會隨著時(shí)間的推移而上下浮動，這時(shí)可以使用Gauge類型的指標(biāo)來跟蹤此類數(shù)據(jù)，Gauge類型的指標(biāo)是一種常規(guī)指標(biāo)，反映系統(tǒng)當(dāng)前狀態(tài)的快照，是對一個(gè)值的瞬時(shí)測量，有如下特點(diǎn)：Gauge類指標(biāo)通?？梢杂脕碛涗汣PU使用情況、內(nèi)存使用量、磁盤當(dāng)前和已經(jīng)使用的空間容量、網(wǎng)絡(luò)使用變化、溫度變化、業(yè)務(wù)類游戲在線人數(shù)統(tǒng)計(jì)和訂單數(shù)量統(tǒng)計(jì)等等，例如，Gauge類型指標(biāo)適合記錄那些無規(guī)律變化的數(shù)據(jù)，而且兩次采集之間可能會丟失某些變化數(shù)值，當(dāng)然隨著時(shí)間周期的粒度變大，丟失關(guān)鍵變化數(shù)值的情況也會增多。Histogram即直方圖，形狀與柱狀圖相似，用于表示在一段時(shí)間范圍內(nèi)對數(shù)據(jù)進(jìn)行采樣，對指定區(qū)間以及總數(shù)進(jìn)行分組統(tǒng)計(jì)。典型的應(yīng)用有請求持續(xù)時(shí)間、響應(yīng)大小等等。在Prometheus系統(tǒng)中的查詢語言中，它有三種作用：·對每個(gè)采樣點(diǎn)進(jìn)行統(tǒng)計(jì)，對應(yīng)到各個(gè)分類值中及bucket(可稱為“桶”)?！γ總€(gè)采樣點(diǎn)值累計(jì)和(sum)?！Σ蓸狱c(diǎn)的次數(shù)累計(jì)和(count)。例如，采用對應(yīng)的以下幾種方式產(chǎn)生直方圖(假設(shè)監(jiān)控指標(biāo)名稱為<basename>):·按bucket累計(jì)計(jì)數(shù)，相當(dāng)于<basename>_bucket{le="<上限邊界>"},此值為小于等于上限邊界的所有采樣點(diǎn)數(shù)量。·樣本累計(jì)總和，相當(dāng)于<basename>_sum?！颖纠塾?jì)次數(shù)總和，相當(dāng)于<basename>_count。具有基本監(jiān)控指標(biāo)標(biāo)準(zhǔn)名稱的直方圖，在scrape期間暴露多個(gè)時(shí)間序列。實(shí)踐中，直方圖將會創(chuàng)建一個(gè)額外的帶有_bucket后綴的指標(biāo)，在PrometheusServer返回的自身樣prometheushttp_requestdurationsecondsbucket(handler="/",le="關(guān)于Histogram類型，使用的查詢會對服務(wù)器的CPU有一定的消耗，最直觀的反映就是查詢結(jié)果的返回耗時(shí)情況。需要記住，每個(gè)獨(dú)特的標(biāo)簽組合都被視為一個(gè)單獨(dú)的時(shí)間序列，因此，通常的做法是盡量保持bucket的數(shù)量較小，以及直方圖上的其他標(biāo)簽數(shù)量較少。Summary即概率圖，類似于Histogram,常用于跟蹤與時(shí)間相關(guān)的數(shù)據(jù)。典型的應(yīng)用包括請求持續(xù)時(shí)間、響應(yīng)大小等。Summary同樣提供樣本的count和sum功能；還提供quantiles功能，可以按百分比劃分跟蹤結(jié)果，例如，quantile取值0.95,表示取樣本里面的95%數(shù)據(jù)。Histogram需要通過<basename>_bucket計(jì)算quantile,而Summary直同樣，Summary在scrape期間暴露多個(gè)時(shí)間序列，例如以下是Golang垃圾收集器摘要[1]Wire協(xié)議是總線通信中最為重要的一種操作，在每次總線通信之前主機(jī)必須首先發(fā)送復(fù)位信號。在Prometheus中，任何被采集的目標(biāo)，即每一個(gè)暴露監(jiān)控樣本數(shù)據(jù)的HTTP服務(wù)都稱為一個(gè)實(shí)例(Instance),通常對應(yīng)于單個(gè)進(jìn)程。而具有相同采集目的的實(shí)例集合(比如為可伸縮性或可靠性而復(fù)制的流程)稱為作業(yè)(Job)。例如，以下四個(gè)復(fù)制實(shí)例的API服job:api-server這里可以結(jié)合后續(xù)第3章介紹的用來監(jiān)控主機(jī)CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等的Nodeexporter監(jiān)控程序來學(xué)習(xí)?，F(xiàn)在看一下在Prometheus中使用prometheus.yml配置文件在以上Job中，采用靜態(tài)配置方式定義被監(jiān)控目標(biāo)，在當(dāng)前主機(jī)上運(yùn)行的Nodeexporter監(jiān)控程序被稱為一個(gè)實(shí)例(Instance),而具有相同目的這些實(shí)例，或者是同一個(gè)監(jiān)控進(jìn)程的多個(gè)副本進(jìn)程則通過每一個(gè)作業(yè)(Job)進(jìn)行管理。除了靜態(tài)配置每個(gè)Job采集實(shí)例地址外，Prometheus還可以從自動發(fā)現(xiàn)的實(shí)例上采集監(jiān)控?cái)?shù)據(jù)。下面介紹自動生成標(biāo)簽和時(shí)間序列。Prometheus在采集目標(biāo)數(shù)據(jù)的同時(shí)，會自動在時(shí)序的基礎(chǔ)上附加如下標(biāo)簽，用于識別被采集的目標(biāo)?！ob:配置目標(biāo)所屬的job名稱。·up{job="<job-name>",instance="<instance-id>"}:即可訪問，則為1,否則為0。EQ\*jc3\*hps24\o\al(\s\up11(續(xù)采),scra)EQ\*jc3\*hps24\o\al(\s\up11(集),pe)EQ\*jc3\*hps24\o\al(\s\up11(耗時(shí)間),sample)到的數(shù)據(jù)按照時(shí)間序列存儲在本地磁盤的時(shí)序數(shù)據(jù)庫中(當(dāng)然也支持遠(yuǎn)程存儲),自身對用于輸出被監(jiān)控組件信息的HTTP接口統(tǒng)稱為Exporter(導(dǎo)出器)。目前互聯(lián)網(wǎng)公司常用的組件大部分都有Exporter供直接使用，比如Nginx、MySQL、Linux系統(tǒng)信息(包括Exporter是Prometheus系統(tǒng)中重要的組成部分。在實(shí)際中收集監(jiān)控樣本數(shù)據(jù)都是由Exporter完成的。Exporter可以是一個(gè)獨(dú)立運(yùn)行的進(jìn)程，對外提供一個(gè)用于獲取監(jiān)控?cái)?shù)據(jù)的HTTP服務(wù)。Prometheusserver只需要定時(shí)通過這些Exporter提供的HTTP服務(wù)獲取監(jiān)控?cái)?shù)據(jù)即可。可以類似理解為我們傳統(tǒng)意義上的被監(jiān)控目標(biāo)的agent,只是區(qū)別在于Exporter不會主動推送監(jiān)控?cái)?shù)據(jù)到Prometheusserver。官方的Exporter列表中包含了常見的絕大多數(shù)系統(tǒng)監(jiān)控指標(biāo)，比如用于機(jī)器性能監(jiān)控的node_exporter,MySQL數(shù)據(jù)庫監(jiān)控的mysqld_exporter,以及網(wǎng)絡(luò)設(shè)備監(jiān)控的snmp_exporter等。這些已有的Exporter對于監(jiān)控來說，只需進(jìn)行很少的配置，就能提Pushgateway是指用于支持短期臨時(shí)或批量計(jì)劃任務(wù)