容器云平臺(tái)監(jiān)控架構(gòu)設(shè)計(jì)及優(yōu)化

1概述隨著容器化的大力發(fā)展，容器云平臺(tái)已經(jīng)基本由Kubernetes作為統(tǒng)一的容器管理方案。當(dāng)我們使用Kubernetes進(jìn)行容器化管理時(shí)，傳統(tǒng)監(jiān)控工具如Zabbix無法對(duì)Kubernetes做到統(tǒng)一有效的全面監(jiān)控，全面監(jiān)控Kubernetes也就成為我們需要探索的問題。使用容器云監(jiān)控，旨在全面監(jiān)控Kubernetes集群、節(jié)點(diǎn)、服務(wù)、實(shí)例的統(tǒng)計(jì)數(shù)據(jù)，驗(yàn)證集群是否正常運(yùn)行并創(chuàng)建相應(yīng)告警。本文旨在于介紹容器云平臺(tái)監(jiān)控的架構(gòu)設(shè)計(jì)及優(yōu)化。2價(jià)值和意義監(jiān)控是運(yùn)維體系中是非常重要的組成部分，通過監(jiān)控可以實(shí)時(shí)掌握系統(tǒng)運(yùn)行狀態(tài)，對(duì)故障提前預(yù)警，以及歷史狀態(tài)的回放，還可以通過監(jiān)控?cái)?shù)據(jù)為系統(tǒng)的容量規(guī)劃提供輔助決策，為系統(tǒng)性能優(yōu)化提供真實(shí)的用戶行為和體驗(yàn)。為容器云提供良好的監(jiān)控環(huán)境是保證容器服務(wù)的高可靠性、高可用性和高性能的重要部分，通過對(duì)本文的學(xué)習(xí)，能夠快速認(rèn)識(shí)當(dāng)前容器環(huán)境下都有哪些監(jiān)控方案，并對(duì)主流的監(jiān)控方案有一個(gè)系統(tǒng)的了解和認(rèn)識(shí)。3監(jiān)控方案選型3.1容器云監(jiān)控方案有哪些（1）ZabbixZabbix是由AlexeiVladishev開源的分布式監(jiān)控系統(tǒng)，支持多種采集方式和采集客戶端，同時(shí)支持SNMP、IPMI、JMX、Telnet、SSH等多種協(xié)議，它將采集到的數(shù)據(jù)存放到數(shù)據(jù)庫中，然后對(duì)其進(jìn)行分析整理，如果符合告警規(guī)則，則觸發(fā)相應(yīng)的告警。Zabbix核心組件主要是Agent和Server，其中Agent主要負(fù)責(zé)采集數(shù)據(jù)并通過主動(dòng)或者被動(dòng)的方式采集數(shù)據(jù)發(fā)送到Server/Proxy，除此之外，為了擴(kuò)展監(jiān)控項(xiàng)，Agent還支持執(zhí)行自定義腳本。Server主要負(fù)責(zé)接收Agent發(fā)送的監(jiān)控信息，并進(jìn)行匯總存儲(chǔ)，觸發(fā)告警等。ZabbixServer將收集的監(jiān)控?cái)?shù)據(jù)存儲(chǔ)到ZabbixDatabase中。ZabbixDatabase支持常用的關(guān)系型數(shù)據(jù)庫，如MySQL、PostgreSQL、Oracle等，默認(rèn)是MySQL，并提供ZabbixWeb頁面（PHP編寫）數(shù)據(jù)查詢。Zabbix由于使用了關(guān)系型數(shù)據(jù)存儲(chǔ)時(shí)序數(shù)據(jù)，所以在監(jiān)控大規(guī)模集群時(shí)常常在數(shù)據(jù)存儲(chǔ)方面捉襟見肘。所以從Zabbix4.2版本后開始支持TimescaleDB時(shí)序數(shù)據(jù)庫，不過目前成熟度還不高。（2）Open-FalconOpen-Falcon是小米開源的企業(yè)級(jí)監(jiān)控工具，用Go語言開發(fā)而成，包括小米、滴滴、美團(tuán)等在內(nèi)的互聯(lián)網(wǎng)公司都在使用它，是一款靈活、可擴(kuò)展并且高性能的監(jiān)控方案，主要組件包括了：1）Falcon-agent是用Go語言開發(fā)的Daemon程序，運(yùn)行在每臺(tái)Linux服務(wù)器上，用于采集主機(jī)上的各種指標(biāo)數(shù)據(jù)，主要包括CPU、內(nèi)存、磁盤、文件系統(tǒng)、內(nèi)核參數(shù)、Socket連接等，目前已經(jīng)支持200多項(xiàng)監(jiān)控指標(biāo)。并且，Agent支持用戶自定義的監(jiān)控腳本。2）Hearthbeatserver簡稱HBS心跳服務(wù)，每個(gè)Agent都會(huì)周期性地通過RPC方式將自己的狀態(tài)上報(bào)給HBS，主要包括主機(jī)名、主機(jī)IP、Agent版本和插件版本，Agent還會(huì)從HBS獲取自己需要執(zhí)行的采集任務(wù)和自定義插件。3）Transfer負(fù)責(zé)接收Agent發(fā)送的監(jiān)控?cái)?shù)據(jù)，并對(duì)數(shù)據(jù)進(jìn)行整理，在過濾后通過一致性Hash算法發(fā)送到Judge或者Graph。4）Graph是基于RRD的數(shù)據(jù)上報(bào)、歸檔、存儲(chǔ)組件。Graph在收到數(shù)據(jù)以后，會(huì)以rrdtool的數(shù)據(jù)歸檔方式來存儲(chǔ)，同時(shí)提供RPC方式的監(jiān)控查詢接口。5）Judge告警模塊，Transfer轉(zhuǎn)發(fā)到Judge的數(shù)據(jù)會(huì)觸發(fā)用戶設(shè)定的告警規(guī)則，如果滿足，則會(huì)觸發(fā)郵件、微信或者回調(diào)接口。這里為了避免重復(fù)告警引入了Redis暫存告警，從而完成告警的合并和抑制。6）Dashboard是面向用戶的監(jiān)控?cái)?shù)據(jù)查詢和告警配置界面。（3）NagiosNagios原名為NetSaint，由EthanGalstad開發(fā)并維護(hù)。Nagios是一個(gè)老牌監(jiān)控工具，由C語言編寫而成，主要針對(duì)主機(jī)監(jiān)控（CPU、內(nèi)存、磁盤等）和網(wǎng)絡(luò)監(jiān)控（SMTP、POP3、HTTP和NNTP等），當(dāng)然也支持用戶自定義的監(jiān)控腳本。它還支持一種更加通用和安全的采集方式NREP（NagiosRemotePluginExecutor），它首先在遠(yuǎn)端啟動(dòng)一個(gè)NREP守護(hù)進(jìn)程，用于在遠(yuǎn)端主機(jī)上面運(yùn)行檢測命令，在Nagios服務(wù)端用checknrep的plugin插件通過SSL對(duì)接到NREP守護(hù)進(jìn)程執(zhí)行相應(yīng)的監(jiān)控行為。相比SSH遠(yuǎn)程執(zhí)行命令的方式，這種方式更加安全。（4）PrometheusPrometheus是一個(gè)很受歡迎的開源監(jiān)控和警報(bào)工具包，繼Kubernetes之后成為第二個(gè)正式加入CNCF基金會(huì)的項(xiàng)目，2017年底發(fā)布了基于全新存儲(chǔ)層的2.0版本，能更好地與容器云平臺(tái)配合。能實(shí)現(xiàn)dockerstatus、cAdvisor的監(jiān)控功能，并且Prometheus原生支持Kubernetes監(jiān)控，具有Kubernetes對(duì)象服務(wù)發(fā)現(xiàn)能力，Kubernetes的核心組件也提供了Prometheus的采集接口。單個(gè)Prometheus可以每秒抓取10萬的metrics，能滿足一定規(guī)模下k8s集群的監(jiān)控需求，并且具備良好的查詢能力，提供數(shù)據(jù)查詢語言PromQL，PromQL提供了大量的數(shù)據(jù)計(jì)算函數(shù)，大部分情況下用戶都可以直接通過PromQL從Prometheus里查詢到需要的聚合數(shù)據(jù)。3.2方案對(duì)比并確定通過以下方面對(duì)上述監(jiān)控方案進(jìn)行對(duì)比：1）從開發(fā)語言上看，為了應(yīng)對(duì)高并發(fā)和快速迭代的需求，監(jiān)控系統(tǒng)的開發(fā)語言已經(jīng)慢慢從C語言轉(zhuǎn)移到Go。不得不說，Go憑借簡潔的語法和優(yōu)雅的并發(fā)，在Java占據(jù)業(yè)務(wù)開發(fā)，C占領(lǐng)底層開發(fā)的情況下，準(zhǔn)確定位中間件開發(fā)需求，在當(dāng)前開源中間件產(chǎn)品中被廣泛應(yīng)用。2）從系統(tǒng)成熟度上看，Zabbix和Nagios都是老牌的監(jiān)控系統(tǒng)，系統(tǒng)功能比較穩(wěn)定，成熟度較高。而Prometheus和Open-Falcon都是最近幾年才誕生的，雖然功能還在不斷迭代更新，但站在巨人的肩膀之上，在架構(gòu)設(shè)計(jì)上借鑒了很多老牌監(jiān)控系統(tǒng)的經(jīng)驗(yàn)。3）從系統(tǒng)擴(kuò)展性方面看，Zabbix和Open-Falcon都可以自定義各種監(jiān)控腳本，并且Zabbix不僅可以做到主動(dòng)推送，還可以做到被動(dòng)拉取，Prometheus則定義了一套監(jiān)控?cái)?shù)據(jù)規(guī)范，并通過各種exporter擴(kuò)展系統(tǒng)采集能力。4）從數(shù)據(jù)存儲(chǔ)方面來看，Zabbix采用關(guān)系數(shù)據(jù)庫保存，這極大限制了Zabbix采集的性能，Nagios和Open-Falcon都采用RDD數(shù)據(jù)存儲(chǔ)，Open-Falcon還加入了一致性hash算法分片數(shù)據(jù)，并且可以對(duì)接到OpenTSDB，而Prometheus自研一套高性能的時(shí)序數(shù)據(jù)庫，在V3版本可以達(dá)到每秒千萬級(jí)別的數(shù)據(jù)存儲(chǔ)，通過對(duì)接第三方時(shí)序數(shù)據(jù)庫擴(kuò)展歷史數(shù)據(jù)的存儲(chǔ)。5）從配置復(fù)雜度上看，Prometheus只有一個(gè)核心server組件，一條命令便可以啟動(dòng)，相比而言，其他系統(tǒng)配置相對(duì)麻煩，尤其是Open-Falcon。6）從社區(qū)活躍度上看，目前Zabbix和Nagios的社區(qū)活躍度比較低，尤其是Nagios，Open-Falcon雖然也比較活躍，但基本都是國內(nèi)的公司參與，Prometheus在這方面占據(jù)絕對(duì)優(yōu)勢，社區(qū)活躍度最高，并且受到CNCF的支持，后期的發(fā)展值得期待。7）從容器支持角度看，由于Zabbix和Nagios出現(xiàn)得比較早，當(dāng)時(shí)容器還沒有誕生，自然對(duì)容器的支持也比較差。Open-Falcon雖然提供了容器的監(jiān)控，但支持力度有限。Prometheus的動(dòng)態(tài)發(fā)現(xiàn)機(jī)制，不僅可以支持swarm原生集群，還支持Kubernetes容器集群的監(jiān)控，是目前容器監(jiān)控最好解決方案。Zabbix在傳統(tǒng)監(jiān)控系統(tǒng)中，尤其是在服務(wù)器相關(guān)監(jiān)控方面，占據(jù)絕對(duì)優(yōu)勢。而Nagios則在網(wǎng)絡(luò)監(jiān)控方面有廣泛應(yīng)用，伴隨著容器的發(fā)展，Prometheus開始成為主導(dǎo)及容器監(jiān)控方面的標(biāo)配，并且在未來可見的時(shí)間內(nèi)被廣泛應(yīng)用?？傮w來說，對(duì)比各種監(jiān)控系統(tǒng)的優(yōu)劣，Prometheus可以說是目前監(jiān)控領(lǐng)域最鋒利的“瑞士軍刀”了。4基于prometheus的容器云平臺(tái)監(jiān)控架構(gòu)設(shè)計(jì)4.1prometheus介紹Prometheus是由SoundCloud開發(fā)的開源監(jiān)控報(bào)警系統(tǒng)和時(shí)序列數(shù)據(jù)庫。于2016年加入CloudNativeComputingFoundation，作為繼Kubernetes之后的第二個(gè)托管項(xiàng)目，具有強(qiáng)大的數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)展示、告警等功能，天生完美支持kubernetes。主要特點(diǎn)：多維數(shù)據(jù)模型：通過度量名稱和鍵值對(duì)標(biāo)識(shí)的時(shí)間序列數(shù)據(jù)PromSQL：一種靈活的查詢語言，可以利用多維數(shù)據(jù)完成復(fù)雜的查詢不依賴分布式存儲(chǔ)，單個(gè)服務(wù)器節(jié)點(diǎn)可直接工作基于HTTP的pull方式采集時(shí)間序列數(shù)據(jù)推送時(shí)間序列數(shù)據(jù)通過PushGateway組件支持通過服務(wù)發(fā)現(xiàn)或靜態(tài)配置發(fā)現(xiàn)目標(biāo)多種圖形模式及儀表盤支持組件：Prometheus生態(tài)包括了很多組件，它們中的一些是可選的Prometheus主服務(wù)器，用于抓取和存儲(chǔ)時(shí)間序列數(shù)據(jù)用于檢測應(yīng)用程序代碼的客戶端庫用于支持短聲明周期的push網(wǎng)關(guān)針對(duì)HAProxy，StatsD，Graphite，Snmp等服務(wù)的特定exporters警告管理器各種支持工具多數(shù)Prometheus組件是Go語言寫的，這使得這些組件很容易編譯和部署。4.2架構(gòu)設(shè)計(jì)（1）圖片左側(cè)是各種數(shù)據(jù)源主要是各種符合Prometheus數(shù)據(jù)格式的exporter，除此之外為了支持推動(dòng)數(shù)據(jù)類型的Agent，可以通過Pushgateway組件，將Push轉(zhuǎn)化為Pull。Prometheus甚至可以從其它的Prometheus獲取數(shù)據(jù)，組建聯(lián)邦集群。Prometheus的基本原理是通過HTTP周期性抓取被監(jiān)控組件的狀態(tài)，任意組件只要提供對(duì)應(yīng)的HTTP接口并且符合Prometheus定義的數(shù)據(jù)格式，就可以接入Prometheus監(jiān)控。（2）圖片上側(cè)是服務(wù)發(fā)現(xiàn)，Prometheus支持監(jiān)控對(duì)象的自動(dòng)發(fā)現(xiàn)機(jī)制，從而可以動(dòng)態(tài)獲取監(jiān)控對(duì)象。（3）圖片中間是Prometheus

Server，Retrieval模塊定時(shí)拉取數(shù)據(jù)，并通過Storage模塊保存數(shù)據(jù)。PromQL為Prometheus提供的查詢語法，PromQL模塊通過解析語法樹，調(diào)用Storage模塊查詢接口獲取監(jiān)控?cái)?shù)據(jù)。（4）圖片右側(cè)是告警和頁面展現(xiàn)，Prometheus將告警推送到alertmanger，然后通過alertmanger對(duì)告警進(jìn)行處理并執(zhí)行相應(yīng)動(dòng)作。數(shù)據(jù)展現(xiàn)除了Prometheus自帶的webui，還可以通過grafana等組件查詢Prometheus監(jiān)控?cái)?shù)據(jù)。Prometheus支持使用聯(lián)邦集群的方式，對(duì)Prometheus進(jìn)行擴(kuò)展。如圖，在每個(gè)集群（數(shù)據(jù)中心）部署單獨(dú)的Prometheus，用于采集當(dāng)前集群（數(shù)據(jù)中心）監(jiān)控?cái)?shù)據(jù)，并由上層的Prometheus負(fù)責(zé)聚合多個(gè)集群（數(shù)據(jù)中心）的監(jiān)控?cái)?shù)據(jù)。這里部署多個(gè)聯(lián)邦節(jié)點(diǎn)是為了實(shí)現(xiàn)高可用。聯(lián)邦集群的核心在于每一個(gè)Prometheus都包含一個(gè)用于獲取當(dāng)前實(shí)例中監(jiān)控樣本的接口/federate。對(duì)于聯(lián)邦Prometheus而言，無論是從其他的Prometheus實(shí)例還是Exporter實(shí)例中獲取數(shù)據(jù)實(shí)際上并沒有任何差異。適用場景：Prometheus在記錄純數(shù)字時(shí)間序列方面表現(xiàn)非常好。既適用于面向服務(wù)器等硬件指標(biāo)的監(jiān)控，也適用于高動(dòng)態(tài)的面向服務(wù)架構(gòu)的監(jiān)控。對(duì)于現(xiàn)流行的微服務(wù)，Prometheus的多維度數(shù)據(jù)收集和數(shù)據(jù)篩選查詢語言也是非常的強(qiáng)大。Prometheus是為服務(wù)的可靠性而設(shè)計(jì)的，當(dāng)服務(wù)出現(xiàn)故障時(shí)，可以快速定位和診斷問題。搭建過程對(duì)硬件和服務(wù)沒有很強(qiáng)的依賴關(guān)系。不適用場景：（1）如果需要100％的準(zhǔn)確度（例如按請(qǐng)求計(jì)費(fèi)），Prometheus不是一個(gè)好的選擇，因?yàn)槭占臄?shù)據(jù)可能不夠詳細(xì)和完整。在這種情況下，最好使用其他系統(tǒng)來收集和分析數(shù)據(jù)以進(jìn)行計(jì)費(fèi)，并使用Prometheus進(jìn)行其余監(jiān)控。（2）Prometheus只針對(duì)性能和可用性監(jiān)控，默認(rèn)并不具備日志監(jiān)控等功能。（3）Prometheus認(rèn)為只有最近的監(jiān)控?cái)?shù)據(jù)才有查詢的需要，本地存儲(chǔ)的設(shè)計(jì)初衷只是保持短期（一個(gè)月）的數(shù)據(jù)，并非針對(duì)大量的歷史數(shù)據(jù)的存儲(chǔ)。如果需要報(bào)表之類的歷史數(shù)據(jù)，則建議使用遠(yuǎn)端存儲(chǔ)。（4）Prometheus沒有定義單位，需要使用者自己去區(qū)分或者事先定義好監(jiān)控?cái)?shù)據(jù)單位。4.3監(jiān)控點(diǎn)有哪些從容器云平臺(tái)本身的業(yè)務(wù)需求分析來看，至少應(yīng)該通過Prometheus獲取到以下監(jiān)控?cái)?shù)據(jù)：性能指標(biāo)：（1）容器相關(guān)的性能指標(biāo)數(shù)據(jù)container.cpu.utilization：容器的cpu使用率container.memory.utilization：容器的memory使用率（2）Pod相關(guān)的性能指標(biāo)數(shù)據(jù)pod.cpu.utilization：pod的cpu使用率pod.memory.utilization：pod的memory使用率（3）主機(jī)Node節(jié)點(diǎn)相關(guān)的性能指標(biāo)數(shù)據(jù)node.cpu.utilization：主機(jī)的cpu使用率node.memory.utilization：主機(jī)的memory使用率node.load.1：主機(jī)過去1分鐘的負(fù)載node.load.5：主機(jī)過去5分鐘的負(fù)載node.load.15：主機(jī)過去15分鐘的負(fù)載node.resource.request.cpu.utilization：主機(jī)的kubernetescpuresource使用率node.resource.request.memory.utilization：主機(jī)的kubernetesmemoryresource使用率服務(wù)健康狀態(tài)：（1）Kubernetes集群服務(wù)的健康狀態(tài)ControlPlaneUP：集群健康狀態(tài)（2）Kubernetes服務(wù)組件的健康狀態(tài)APIServerUP：APIServer狀態(tài)ControllerManagerUP：ControllerManager狀態(tài)SchedulersUP：Schedulers狀態(tài)KubeletUP：kubelet狀態(tài)Kube-proxyUP：Kube-proxy狀態(tài)（3）主機(jī)Node節(jié)點(diǎn)的健康狀態(tài)NodeUP：node節(jié)點(diǎn)的狀態(tài)（4）docker服務(wù)進(jìn)程的健康狀態(tài)DockerUP：Docker狀態(tài)（5）Deployment相關(guān)的健康狀態(tài)DeploymentReplicas：deployment副本數(shù)（6）Pod的健康狀態(tài)PodReady：pod的狀態(tài)下面選取以上指標(biāo)中的部分進(jìn)行舉例：容器cpu使用率：container_cpu_user_seconds_total{container_name="jenkins",endpoint="https-metrics",instance="22:10250",job="expose-kubelets-metrics",namespace="kube-ops",node="node1",pod_name="jenkins2-696b8fbdbb-hd9hm",service="expose-kubelets-metrics"}主機(jī)過去5分鐘的負(fù)載：node_load5{endpoint="metrics",host_ip="21",instance="21:9796",job="expose-node-metrics",namespace="cattle-prometheus",node="master",pod="exporter-node-cluster-monitoring-b4m72",service="expose-node-metrics"}Deployment副本數(shù)：kube_deployment_spec_replicas{deployment="coredns",endpoint="http",host_ip="22",instance="49:8080",job="expose-kubernetes-metrics",namespace="kube-system",node="node1",pod="exporter-kube-state-cluster-monitoring-5c988dbc56-ckrz6",service="expose-kubernetes-metrics"}Pod的狀態(tài)：kube_pod_status_ready{condition="true",endpoint="http",host_ip="22",instance="49:8080",job="expose-kubernetes-metrics",namespace="default",node="node1",pod="toolbox-f95b876-mrkxn",service="expose-kubernetes-metrics"}4.4重要組件介紹（1）Prometheus-Operator上圖是Prometheus-Operator官方提供的架構(gòu)圖，其中Operator是最核心的部分，作為一個(gè)控制器，它會(huì)去創(chuàng)建Prometheus、ServiceMonitor、AlertManager以及PrometheusRule4個(gè)CRD資源對(duì)象，然后會(huì)一直監(jiān)控并維持這4個(gè)資源對(duì)象的狀態(tài)。Prometheus：PrometheusDeployment定義ServiceMonitor：Prometheus監(jiān)控對(duì)象的定義Alertmanager：AlertmanagerDeployment定義PrometheusRule：告警規(guī)則這樣，我們?cè)诩褐斜O(jiān)控?cái)?shù)據(jù)就變成了直接去操作Kubernetes集群的資源對(duì)象，方便很多了。一個(gè)ServiceMonitor可以通過labelSelector的方式去匹配一類Service，Prometheus也可以通過labelSelector去匹配多個(gè)ServiceMonitor。（2）PrometheusServerPrometheusServer是Prometheus組件中的核心部分，負(fù)責(zé)實(shí)現(xiàn)對(duì)監(jiān)控?cái)?shù)據(jù)的獲取，存儲(chǔ)以及查詢。PrometheusServer可以通過靜態(tài)配置管理監(jiān)控目標(biāo)，也可以配合使用ServiceDiscovery的方式動(dòng)態(tài)管理監(jiān)控目標(biāo)，并從這些監(jiān)控目標(biāo)中獲取數(shù)據(jù)。其次PrometheusServer需要對(duì)采集到的監(jiān)控?cái)?shù)據(jù)進(jìn)行存儲(chǔ)，其本身就是一個(gè)時(shí)序數(shù)據(jù)庫，將采集到的監(jiān)控?cái)?shù)據(jù)按照時(shí)間序列的方式存儲(chǔ)在本地磁盤當(dāng)中。PrometheusServer對(duì)外提供了自定義的PromQL語言，實(shí)現(xiàn)對(duì)數(shù)據(jù)的查詢以及分析。PrometheusServer內(nèi)置的ExpressBrowserUI，通過這個(gè)UI可以直接通過PromQL實(shí)現(xiàn)數(shù)據(jù)的查詢以及可視化。PrometheusServer的聯(lián)邦集群能力可以使其從其他的PrometheusServer實(shí)例中獲取數(shù)據(jù)，因此在大規(guī)模監(jiān)控的情況下，可以通過聯(lián)邦集群以及功能分區(qū)的方式對(duì)PrometheusServer進(jìn)行擴(kuò)展。Prometheus支持兩種類型的規(guī)則：記錄規(guī)則和警報(bào)規(guī)則。要在Prometheus中包含規(guī)則，需要?jiǎng)?chuàng)建一個(gè)包含必要規(guī)則語句的文件，并讓Prometheus通過Prometheus配置文件中的rule_files字段加載規(guī)則文件。①Recordingrules（記錄規(guī)則）Recordingrules可以預(yù)先計(jì)算經(jīng)常需要或計(jì)算量大的表達(dá)式，并將其結(jié)果保存為一組新的時(shí)間序列。這樣，查詢預(yù)先計(jì)算的結(jié)果通常比每次需要原始表達(dá)式查詢要快得多。這對(duì)于dashboards特別有用，dashboards每次刷新時(shí)都需要重復(fù)查詢相同的表達(dá)式。②Alertingrules（告警規(guī)則）告警規(guī)則可以基于Prometheus表達(dá)式定義警報(bào)條件，并將有關(guān)觸發(fā)告警的通知發(fā)送到外部服務(wù)。每當(dāng)告警表達(dá)式在給定時(shí)間點(diǎn)生成一個(gè)或多個(gè)向量元素時(shí)，警報(bào)將計(jì)為這些元素的標(biāo)簽集的活動(dòng)狀態(tài)。并且Prometheus提供了多種服務(wù)發(fā)現(xiàn)方式：azure_sd_configsconsul_sd_configsdns_sd_configsec2_sd_configsopenstack_sd_configsfile_sd_configskubernetes_sd_configsmarathon_sd_configsnerve_sd_configsserverset_sd_configstriton_sd_configs（3）PushGateway由于Prometheus數(shù)據(jù)采集基于Pull模型進(jìn)行設(shè)計(jì)，因此在網(wǎng)絡(luò)環(huán)境的配置上必須要讓PrometheusServer能夠直接與Exporter進(jìn)行通信。當(dāng)這種網(wǎng)絡(luò)需求無法直接滿足時(shí)，就可以利用PushGateway來進(jìn)行中轉(zhuǎn)?？梢酝ㄟ^PushGateway將內(nèi)部網(wǎng)絡(luò)的監(jiān)控?cái)?shù)據(jù)主動(dòng)Push到Gateway當(dāng)中。而PrometheusServer則可以采用同樣Pull的方式從PushGateway中獲取到監(jiān)控?cái)?shù)據(jù)。（4）ExportersExporter將監(jiān)控?cái)?shù)據(jù)采集的端點(diǎn)通過HTTP服務(wù)的形式暴露給PrometheusServer，PrometheusServer通過訪問該Exporter提供的Endpoint端點(diǎn)，即可獲取到需要采集的監(jiān)控?cái)?shù)據(jù)。一般來說可以將Exporter分為2類：①直接采集：這一類Exporter直接內(nèi)置了對(duì)Prometheus監(jiān)控的支持，比如cAdvisor，Kubernetes，Etcd等，都直接內(nèi)置了用于向Prometheus暴露監(jiān)控?cái)?shù)據(jù)的端點(diǎn)。②間接采集：間接采集，原有監(jiān)控目標(biāo)并不直接支持Prometheus，因此我們需要通過Prometheus提供的ClientLibrary編寫該監(jiān)控目標(biāo)的監(jiān)控采集程序。例如：MysqlExporter，JMXExporter，BlackboxExporter等。（5）AlertManager在PrometheusServer中支持基于PromQL創(chuàng)建告警規(guī)則，如果滿足PromQL定義的規(guī)則，則會(huì)產(chǎn)生一條告警，而告警的后續(xù)處理流程則由AlertManager進(jìn)行管理。在AlertManager中我們可以與郵件，Slack等等內(nèi)置的通知方式進(jìn)行集成，也可以通過Webhook自定義告警處理方式。AlertManager即Prometheus體系中的告警處理中心。主要處理流程：①接收到Alert，根據(jù)labels判斷屬于哪些Route（可存在多個(gè)Route，一個(gè)Route有多個(gè)Group，一個(gè)Group有多個(gè)Alert）。②將Alert分配到Group中，沒有則新建Group。③新的Group等待group_wait指定的時(shí)間（等待時(shí)可能收到同一Group的Alert），根據(jù)resolve_timeout判斷Alert是否解決，然后發(fā)送通知。④已有的Group等待group_interval指定的時(shí)間，判斷Alert是否解決，當(dāng)上次發(fā)送通知到現(xiàn)在的間隔大于repeat_interval或者Group有更新時(shí)會(huì)發(fā)送通知。alert工作流程：一旦這些警報(bào)存儲(chǔ)在Alertmanager，它們可能處于以下任何狀態(tài)：inactive:表示當(dāng)前報(bào)警信息既不是firing狀態(tài)也不是pending狀態(tài)。pending:表示在設(shè)置的閾值時(shí)間范圍內(nèi)被激活了。firing:表示超過設(shè)置的閾值時(shí)間被激活了。在這個(gè)頁面中可以進(jìn)行一些操作，比如過濾、分組等等，里面還有兩個(gè)新的概念：Inhibition(抑制)和Silences(靜默)。Inhibition：如果某些其他警報(bào)已經(jīng)觸發(fā)了，則對(duì)于某些警報(bào)，Inhibition是一個(gè)抑制通知的概念。例如：一個(gè)警報(bào)已經(jīng)觸發(fā)，它正在通知整個(gè)集群是不可達(dá)的時(shí)，Alertmanager則可以配置成關(guān)心這個(gè)集群的其他警報(bào)無效。這可以防止與實(shí)際問題無關(guān)的數(shù)百或數(shù)千個(gè)觸發(fā)警報(bào)的通知，Inhibition需要通過上面的配置文件進(jìn)行配置。Silences：靜默是一個(gè)非常簡單的方法，可以在給定時(shí)間內(nèi)簡單地忽略所有警報(bào)。Silences基于matchers配置，類似路由樹。來到的警告將會(huì)被檢查，判斷它們是否和活躍的Silences相等或者正則表達(dá)式匹配。如果匹配成功，則不會(huì)將這些警報(bào)發(fā)送給接收者。4.5數(shù)據(jù)可視化（1）WebConsolePrometheus自帶了WebConsole，安裝成功后可以訪問http://localhost:9090/graph頁面，用它可以進(jìn)行任何PromQL查詢和調(diào)試工作，非常方便，例如：其中：①alters可以查看當(dāng)前報(bào)警的狀態(tài)②status->rules可以查看配置的報(bào)警規(guī)則③status->targets可以查看配置的job及狀態(tài)通過上圖不難發(fā)現(xiàn)，Prometheus自帶的Web界面比較簡單，因?yàn)樗哪康氖菫榱思皶r(shí)查詢數(shù)據(jù)，方便PromeQL調(diào)試。（2）Grafanagrafana主要用于大規(guī)模指標(biāo)數(shù)據(jù)的可視化展現(xiàn)，是網(wǎng)絡(luò)架構(gòu)和應(yīng)用分析中最流行的時(shí)序數(shù)據(jù)展示工具，目前已經(jīng)支持絕大部分常用的時(shí)序數(shù)據(jù)庫。Grafana支持許多不同的數(shù)據(jù)源，每個(gè)數(shù)據(jù)源都有一個(gè)特定的查詢編輯器，該編輯器定制的特性和功能是公開的特定數(shù)據(jù)來源。官方支持以下數(shù)據(jù)源：Graphite、Elasticsearch、InfluxDB、Prometheus、Cloudwatch、MySQL和OpenTSDB等。進(jìn)入到Grafana的界面中，默認(rèn)情況下使用賬戶admin/admin進(jìn)行登錄。在Grafana首頁中顯示默認(rèn)的使用向?qū)Вǎ喊惭b、添加數(shù)據(jù)源、創(chuàng)建Dashboard、邀請(qǐng)成員、以及安裝應(yīng)用和插件等主要流程。這里將添加Prometheus作為默認(rèn)的數(shù)據(jù)源，如下圖所示，指定數(shù)據(jù)源類型為Prometheus并且設(shè)置Prometheus的訪問地址即可，在配置正確的情況下點(diǎn)擊“Add”按鈕，會(huì)提示連接成功的信息：在完成數(shù)據(jù)源的添加之后就可以在Grafana中創(chuàng)建我們可視化Dashboard了。Grafana提供了對(duì)PromQL的完整支持，如下所示，通過Grafana添加Dashboard并且為該Dashboard添加一個(gè)類型為“Graph”的面板。并在該面板的“Metrics”選項(xiàng)下通過PromQL查詢需要可視化的數(shù)據(jù)：點(diǎn)擊界面中的保存選項(xiàng)，就創(chuàng)建了我們的可視化Dashboard了。當(dāng)然作為開源軟件，Grafana社區(qū)鼓勵(lì)用戶通過/dashboards網(wǎng)站分享Dashboard，可以找到大量可直接使用的Dashboard：Grafana中所有的Dashboard通過JSON進(jìn)行共享，下載并且導(dǎo)入這些JSON文件，就可以直接使用這些已經(jīng)定義好的Dashboard。4.6高可用設(shè)計(jì)4.6.1存儲(chǔ)Prometheus內(nèi)置了一個(gè)基于本地存儲(chǔ)的時(shí)間序列數(shù)據(jù)庫。在Prometheus設(shè)計(jì)上，使用本地存儲(chǔ)可以降低Prometheus部署和管理的復(fù)雜度同時(shí)減少高可用（HA）帶來的復(fù)雜性。在默認(rèn)情況下，用戶只需要部署多套Prometheus，采集相同的Targets即可實(shí)現(xiàn)基本的HA。同時(shí)由于Promethus高效的數(shù)據(jù)處理能力，單個(gè)PrometheusServer基本上能夠應(yīng)對(duì)大部分用戶監(jiān)控規(guī)模的需求。（1）本地存儲(chǔ)通過Prometheus自帶的tsdb（時(shí)序數(shù)據(jù)庫），將數(shù)據(jù)保存到本地磁盤，為了性能考慮，建議使用SSD。Prometheus本地存儲(chǔ)經(jīng)過多年改進(jìn)，自Prometheus2.0后提供的V3版本tsdb性能已經(jīng)非常高。本地存儲(chǔ)也帶來了一些不好的地方，首先就是數(shù)據(jù)持久化的問題，特別是在像Kubernetes這樣的動(dòng)態(tài)集群環(huán)境下，如果Promthues的實(shí)例被重新調(diào)度，那所有歷史監(jiān)控?cái)?shù)據(jù)都會(huì)丟失。其次本地存儲(chǔ)也意味著Prometheus不適合保存大量歷史數(shù)據(jù)(一般Prometheus推薦只保留幾周或者幾個(gè)月的數(shù)據(jù))。最后本地存儲(chǔ)也導(dǎo)致Prometheus無法進(jìn)行彈性擴(kuò)展。為了適應(yīng)這方面的需求，Prometheus提供了remote_write和remote_read的特性，支持將數(shù)據(jù)存儲(chǔ)到遠(yuǎn)端和從遠(yuǎn)端讀取數(shù)據(jù)。通過將監(jiān)控與數(shù)據(jù)分離，Prometheus能夠更好地進(jìn)行彈性擴(kuò)展。（2）遠(yuǎn)端存儲(chǔ)Prometheus提供了remote_write和remote_read的特性，支持將數(shù)據(jù)存儲(chǔ)到遠(yuǎn)端和從遠(yuǎn)端讀取數(shù)據(jù)。通過將監(jiān)控樣本采集和數(shù)據(jù)存儲(chǔ)分離，解決Prometheus的持久化問題，適用于大量歷史監(jiān)控?cái)?shù)據(jù)的存儲(chǔ)和查詢。目前，遠(yuǎn)端存儲(chǔ)主要包括OpenTSDB、InfluxDB、Elasticsearch、M3db等。RemoteWrite：用戶可以在Prometheus配置文件中指定RemoteWrite(遠(yuǎn)程寫)的URL地址，一旦設(shè)置了該配置項(xiàng)，Prometheus將采集到的樣本數(shù)據(jù)通過HTTP的形式發(fā)送給適配器(Adaptor)。而用戶則可以在適配器中對(duì)接外部任意的服務(wù)。外部服務(wù)可以是真正的存儲(chǔ)系統(tǒng)，公有云的存儲(chǔ)服務(wù)，也可以是消息隊(duì)列等任意形式。RemoteRead：Promthues的RemoteRead(遠(yuǎn)程讀)也通過了一個(gè)適配器實(shí)現(xiàn)。在遠(yuǎn)程讀的流程當(dāng)中，當(dāng)用戶發(fā)起查詢請(qǐng)求后，Promthues將向remote_read中配置的URL發(fā)起查詢請(qǐng)求(matchers,ranges)，Adaptor根據(jù)請(qǐng)求條件從第三方存儲(chǔ)服務(wù)中獲取響應(yīng)的數(shù)據(jù)。同時(shí)將數(shù)據(jù)轉(zhuǎn)換為Promthues的原始樣本數(shù)據(jù)返回給Prometheus

Server。當(dāng)獲取到樣本數(shù)據(jù)后，Promthues在本地使用PromQL對(duì)樣本數(shù)據(jù)進(jìn)行二次處理。（注意：啟用遠(yuǎn)程讀設(shè)置后，只在數(shù)據(jù)查詢時(shí)有效，對(duì)于規(guī)則文件的處理，以及Metadata

API的處理都只基于Prometheus本地存儲(chǔ)完成。）通過遠(yuǎn)端存儲(chǔ)可以分離監(jiān)控樣本采集和數(shù)據(jù)存儲(chǔ)，解決Prometheus的持久化問題。4.6.2Prometheus高可用（1）服務(wù)高可用Promtheus以pull方式設(shè)計(jì)，通過主動(dòng)發(fā)起的方式采集監(jiān)控Metrics。Prometheus內(nèi)置了一個(gè)基于本地存儲(chǔ)機(jī)制的時(shí)間序列數(shù)據(jù)庫TSDB，使用本地存儲(chǔ)的方式降低了部署和管理Prometheus的復(fù)雜度。為了保證

Promtheus服務(wù)的可用性，用戶只需要部署多套PrometheusServer實(shí)例，先通過Nginx/HAProxy接收請(qǐng)求，然后通過Prometheus采集相同的Exporter目標(biāo)，就可以實(shí)現(xiàn)基本的高可用。（2）數(shù)據(jù)一致性Pull模式下，同一個(gè)服務(wù)至少需要兩個(gè)Prometheus節(jié)點(diǎn)同時(shí)拉取監(jiān)控?cái)?shù)據(jù)。這種情況下，就需要解決多個(gè)PrometheusServer實(shí)例之間的數(shù)據(jù)一致性問題。解決方案：采用Prometheus的協(xié)助方案Thanos。同機(jī)部署Thanos

Sidecar與Prometheus，ThanosQuery調(diào)用查詢的載體Sidecar，Sidecar與prometheus進(jìn)行交互，獲取Metrics并去重，來保證數(shù)據(jù)一致性。Thanos是CNCF孵化項(xiàng)目，目前沒有出穩(wěn)定發(fā)行版，未來可能是Prometheus高可用官方解決方案，還需繼續(xù)關(guān)注。（3）水平可擴(kuò)展當(dāng)單臺(tái)PromthuesServer無法處理大量的采集任務(wù)時(shí)，通過聯(lián)邦集群的特性對(duì)Prometheus采集任務(wù)按照功能分區(qū)，對(duì)Promthues進(jìn)行擴(kuò)展，以適應(yīng)規(guī)模的變化。（4）數(shù)據(jù)持久化Prometheus的本地存儲(chǔ)設(shè)計(jì)能夠滿足大部分監(jiān)控規(guī)模的需求，但是本地存儲(chǔ)無法存儲(chǔ)大量歷史數(shù)據(jù)，存在數(shù)據(jù)持久化問題。Prometheus允許用戶通過接口將數(shù)據(jù)保存到第三方數(shù)據(jù)庫中，這種方式在Promthues中稱為遠(yuǎn)程存儲(chǔ)。（一）基本HA基本HA可以保證服務(wù)的高可用，無法長期存儲(chǔ)歷史數(shù)據(jù)。監(jiān)控系統(tǒng)關(guān)注一段時(shí)間某個(gè)監(jiān)控指標(biāo)是否達(dá)到告警狀態(tài)，多個(gè)PrometheusServer之間監(jiān)控指標(biāo)數(shù)據(jù)細(xì)微的差別，對(duì)Promethues是否產(chǎn)生告警通知影響很小，所以基本HA架構(gòu)可以滿足一般的監(jiān)控場景。（二）基本HA+遠(yuǎn)程存儲(chǔ)在基本HA保證Promthues服務(wù)可用性的基礎(chǔ)上，通過添加遠(yuǎn)程存儲(chǔ)支持，確保了數(shù)據(jù)的持久化?；綡A和遠(yuǎn)程存儲(chǔ)的方案適合要求監(jiān)控?cái)?shù)據(jù)持久化，保證PromthuesServer可遷移的場景。（三）基本HA+遠(yuǎn)程存儲(chǔ)+聯(lián)邦集群基本HA+遠(yuǎn)程存儲(chǔ)+聯(lián)邦集群的方案保證Promthues的服務(wù)高可用、數(shù)據(jù)持久化、水平可擴(kuò)展。這種架構(gòu)方案一般適合兩個(gè)使用場景：單數(shù)據(jù)中心和大量采集任務(wù)的場景，Promthues處理大量采集任務(wù)時(shí)存在性能瓶頸。采用Prometheus聯(lián)邦集群對(duì)采集任務(wù)進(jìn)行功能分區(qū)，將不同類型的采集任務(wù)劃分到不同的Promthues中。多數(shù)據(jù)中心的場景，最上層的PromthuesServer無法直接從不同數(shù)據(jù)中心的Exporter拉取數(shù)據(jù)。采用聯(lián)邦集群進(jìn)行分層處理，每個(gè)數(shù)據(jù)中心部署一組PrometheusServer收集該數(shù)據(jù)中心的Metric，再由上層的Prometheus拉取監(jiān)控指標(biāo)。（四）按照實(shí)例進(jìn)行功能分區(qū)當(dāng)單個(gè)采集任務(wù)的Target數(shù)目非常巨大，通過聯(lián)邦集群簡單進(jìn)行功能分區(qū)，PrometheusServer也無法有效處理采集任務(wù)時(shí)，就要考慮在實(shí)例級(jí)別對(duì)采集任務(wù)進(jìn)行功能劃分了。通過將同一任務(wù)的不同實(shí)例劃分到不同的PrometheusServer上。設(shè)置Prometheus的relabel_config，確保當(dāng)前PrometheusServer只收集當(dāng)前采集任務(wù)的一部分實(shí)例的Metric。并且通過當(dāng)前數(shù)據(jù)中心的一個(gè)中心PrometheusServer將實(shí)例級(jí)監(jiān)控Metric聚合到任務(wù)級(jí)別。高可用方案的選擇下表展示了三種Promthues高可用方案各自解決的問題，用戶可以根據(jù)自己的實(shí)際場景選擇高可用部署方案。AlertManager的高可用通常用戶會(huì)部署兩個(gè)或兩個(gè)以上的PromtheusServer，來保證Promtheus服務(wù)可用性。這些Promtheus

Server具有相同的Job配置，告警配置等。AlertManager可以同時(shí)接收多個(gè)相同配置的PromtheusServer產(chǎn)生的告警，基于告警去重機(jī)制做告警處理。但是單個(gè)AlertManager不能保證單點(diǎn)失效時(shí)告警處理的可用性，所以我們打算部署多套AlertManager。由于多個(gè)AlertManager之間不了解彼此的存在，就會(huì)導(dǎo)致同一個(gè)告警通知被不同的AlertManager重復(fù)發(fā)送多次。為了解決這一問題，AlertManager引入Gossip共識(shí)機(jī)制。例如兩個(gè)AlertManager接收到相同告警時(shí)，基于Gossip共識(shí)機(jī)制，只允許一個(gè)AlertManager將這個(gè)告警通知發(fā)送給Receiver。4.7性能優(yōu)化與容量預(yù)估4.7.1Prometheus性能優(yōu)化使用固態(tài)硬盤部署Prometheus相比機(jī)械硬盤，固態(tài)硬盤在讀寫性能方面具有一定的優(yōu)勢?？紤]將PrometheusServer部署在固態(tài)硬盤上，目的是提升吞吐量TPS，提高Prometheus性能。使用RecodingRules優(yōu)化性能使用PromQL可以對(duì)Prometheus中的監(jiān)控樣本數(shù)據(jù)進(jìn)行查詢，聚合以及邏