本文可以看做是對《SRE》一書第10章《基于時(shí)間序列數(shù)據(jù)進(jìn)行有效報(bào)警》的實(shí)踐總結(jié)。 Prometheus是一款開源的業(yè)務(wù)監(jiān)控軟件，可以看作是Google內(nèi)部監(jiān)控系統(tǒng) Borgmon 的一個(gè)（非官方）實(shí)現(xiàn)。 本文會(huì)介紹我近期使用Prometheus構(gòu)建的一套完整的，可用于中小規(guī)模（小于500節(jié)點(diǎn)）的半自動(dòng)化（少量人工操作）監(jiān)控系統(tǒng)方案。

主動(dòng)監(jiān)控

監(jiān)控是運(yùn)維系統(tǒng)的基礎(chǔ)，我們衡量一個(gè)公司/部門的運(yùn)維水平，看他們的監(jiān)控系統(tǒng)就可以了。 監(jiān)控手段一般可以分為三種：

主動(dòng)監(jiān)控：業(yè)務(wù)上線前，按照運(yùn)維制定的標(biāo)準(zhǔn)，預(yù)先埋點(diǎn)。具體的實(shí)現(xiàn)方式又有多種，可能通過日志、向本地 Agent 上報(bào)、提供 REST API 等。

被動(dòng)監(jiān)控：通常是對主動(dòng)監(jiān)控的補(bǔ)充，從外圍進(jìn)行黑盒監(jiān)控，通過主動(dòng)探測服務(wù)的功能可用性來進(jìn)行監(jiān)控。比如定期ping業(yè)務(wù)端口。

旁路監(jiān)控：主動(dòng)監(jiān)控和被動(dòng)監(jiān)控，通常還是都在內(nèi)部進(jìn)行的監(jiān)控，內(nèi)部運(yùn)行平穩(wěn)也不能保證用戶的體驗(yàn)都是正常的（比如用戶網(wǎng)絡(luò)出問題），所以仍然需要通過輿情監(jiān)控、第三方監(jiān)控工具等的數(shù)據(jù)來間接的監(jiān)控真實(shí)的服務(wù)質(zhì)量。

主動(dòng)監(jiān)控是最理想的方案，后兩種主要用作補(bǔ)充，本文只關(guān)注主動(dòng)監(jiān)控。 監(jiān)控實(shí)際是一個(gè)端到端的體系（基礎(chǔ)設(shè)施-服務(wù)器-業(yè)務(wù)-用戶體驗(yàn)），本文只關(guān)注業(yè)務(wù)級別的主動(dòng)監(jiān)控。

Prometheus

為什么選擇Prometheus而不是其它TSDB實(shí)現(xiàn)（如InfluxDB）？主要是因?yàn)镻rometheus的核心功能，查詢語言 PromQL，它更像一種可編程計(jì)算器，而不是其那么像 SQL，也意味著 PromQL 可以近乎無限之組合出各種查詢結(jié)果。 比如，我們有一個(gè)http服務(wù)，監(jiān)控項(xiàng)http_requests_total用于統(tǒng)計(jì)請求次數(shù)。某一組監(jiān)控?cái)?shù)據(jù)可能是這個(gè)樣子：

http_requests_total{instance="1.1.1.1:80",job="cluster1",location="/a"} 100http_requests_total{instance="1.1.1.1:80", job="cluster1", location="/b"} 110http_requests_total{instance="1.1.1.2:80", job="cluster2", location="/b"} 100http_requests_total{instance="1.1.1.3:80", job="cluster3", location="/c"} 110 這里有3個(gè)標(biāo)簽，分別對應(yīng)抓取的實(shí)例，所屬的 Job（一般我用集群名），訪問路徑（你可以理解為Nginx的location），Prometheus多維數(shù)據(jù)模型意味著我們可以在任意一個(gè)或多個(gè)維度進(jìn)行計(jì)算：

如果你想統(tǒng)計(jì)單機(jī)qps，sum(rate(http_requests_total[1m])) by (instance)

如果想用統(tǒng)計(jì)每個(gè)集群每個(gè)不同 location 的 path 的 qps，sum(rate(http_requests_total[1m])) by (job, path)，PromQL會(huì)依據(jù)標(biāo)簽job-path的值聚合出結(jié)果。

除了PromQL，豐富的數(shù)據(jù)類型可以提供更有意義的監(jiān)控項(xiàng)：

Counter（計(jì)數(shù)器）：標(biāo)識單調(diào)遞增的數(shù)據(jù)，比如接口訪問次數(shù)。

Gauge（刻度）：當(dāng)前瞬時(shí)的一個(gè)狀態(tài)，可能增加，也可能減小，比如CPU使用率，平均延時(shí)等等。

Historgram（直方圖）：用于統(tǒng)計(jì)數(shù)據(jù)的分布，比如95 percentile latency。

大部分監(jiān)控項(xiàng)都可以使用Counter來實(shí)現(xiàn)，少部分使用Gauge和Histogram，其中Histogram在服務(wù)端計(jì)算是相當(dāng)費(fèi)CPU的，所以也沒要導(dǎo)出太多Histogram數(shù)據(jù)。 最后，Prometheus采用PULL模型的實(shí)時(shí)抓取存儲(chǔ)計(jì)算，主動(dòng)去抓取監(jiān)控實(shí)例數(shù)據(jù)，相比于PUSH模型對業(yè)務(wù)侵入更低，相比于基于log的離線統(tǒng)計(jì)則更實(shí)時(shí)，而監(jiān)控實(shí)例只需提供一個(gè)文本格式的/metrics接口也更容易debug。

服務(wù)框架的改造

筆者所在團(tuán)隊(duì)使用統(tǒng)一的服務(wù)框架來規(guī)范項(xiàng)目開發(fā)并有效降低了開發(fā)難度。 這里先介紹下我們的服務(wù)框架：

類似于 Nginx 的多進(jìn)程架構(gòu)（master/worker），但同時(shí)也支持多線程的事件循環(huán)編程模型

支持多種接入?yún)f(xié)議（HTTP，Thrift，PB等），但主流是HTTP

業(yè)務(wù)通過 Module 來加載進(jìn)框架執(zhí)行（類似 Nginx 的 module，但更簡單）

提供純異步的下游訪問 API

為了使服務(wù)框架可以導(dǎo)出內(nèi)部監(jiān)控項(xiàng)，主要涉及幾方面的工作：

提供基礎(chǔ)數(shù)據(jù)類型

目前并沒有官方的Prometheus Client Library，幾種開源實(shí)現(xiàn)也都不太符合框架的需求。目前實(shí)現(xiàn)了支持多線程多進(jìn)程的Counter和Histogram（除了初始化之外，更新操作都是無鎖的），而Gauge由于多進(jìn)程場景有的情況是無法聚合監(jiān)控?cái)?shù)據(jù)的（沒用統(tǒng)一的聚合方法，并不一定都可以相加），所以沒有提供具體實(shí)現(xiàn)

基礎(chǔ)數(shù)據(jù)要有類似注冊表的功能，方便自動(dòng)導(dǎo)出數(shù)據(jù)到/metrics接口

在服務(wù)框架埋點(diǎn)

要足夠靈活，將容易變化的信息通過標(biāo)簽來表達(dá)。 比如一個(gè)web服務(wù)可能有echo，date兩個(gè)location，如果要統(tǒng)計(jì)它們qps，不要定義echo_requests_total,date_requests_total兩個(gè)不同名字的 metrics，而應(yīng)該定義一個(gè)名為http_requests_total的 metrics，通過標(biāo)簽location（分別為echo/date）來區(qū)分，這樣再增加/減少接口是不需要改代碼的

理想情況是業(yè)務(wù)幾乎為各種通信功能自行埋點(diǎn)，所以內(nèi)置埋點(diǎn)要將常用監(jiān)控項(xiàng)都要覆蓋到（QPS，Latency，Error Ratio）

數(shù)據(jù)的抓取與展現(xiàn)

具備導(dǎo)出能力后，就可以通過Prometheus 進(jìn)行抓取了，但還有幾個(gè)小坑： 用戶定義的metrics名字，可能是不符合Prometheus規(guī)范的，而遇到一條不合法的數(shù)據(jù)，Prometheus就會(huì)停止抓取，所以導(dǎo)出數(shù)據(jù)時(shí)要先做一遍過濾和改寫 要控制導(dǎo)出數(shù)據(jù)規(guī)模，一些只對單機(jī)監(jiān)控有意義的數(shù)據(jù)可以不導(dǎo)出（框架有針對單機(jī)的監(jiān)控頁面） 在使用 Prometheus 時(shí)，也有幾個(gè)地方要注意： Prometheus即是一個(gè)CPU密集型（查詢）也是一個(gè)IO密集型（數(shù)據(jù)落地）的，CPU數(shù)量是多多益善，內(nèi)存越大越好（來緩存抓取的數(shù)據(jù)，所以應(yīng)該減少不必要的業(yè)務(wù)數(shù)據(jù)導(dǎo)出），盡量要使用SSD（這個(gè)很關(guān)鍵?。?，因?yàn)橐坏㏄rometheus的內(nèi)存使用量達(dá)到閾值會(huì)停止抓取數(shù)據(jù)！這個(gè)停止抓取的時(shí)間，至少是分鐘級，甚至是無法恢復(fù)！所以只要有條件就要用SSD。 Prometheus號稱支持 reload，但目測不是很好用，比如你修改了告警規(guī)則文件，重載之后，新舊告警規(guī)則似乎會(huì)一起計(jì)算執(zhí)行…. Prometheus本身也提供圖形界面，但是很簡陋：

通常還是使用Grafana來展示監(jiān)控?cái)?shù)據(jù)。

因?yàn)槭墙y(tǒng)一的業(yè)務(wù)框架，統(tǒng)一的監(jiān)控指標(biāo)，所以 Grafana 的 Dashboard 很容易統(tǒng)一配置：

我沒有找到將默認(rèn)模板打包進(jìn) Grafana 的方法，只能迂回的創(chuàng)建了一個(gè)新的Grafana Plugin，在啟動(dòng)之后，每個(gè)業(yè)務(wù)實(shí)例只需要啟動(dòng)下這個(gè)插件，然后配置一個(gè)默認(rèn)的 Prometheus 數(shù)據(jù)源，就可以使用統(tǒng)一的監(jiān)控 Dashboard

Dashboard 分為3行

第一行展示實(shí)時(shí)的 QPS，平均延時(shí)，平均排隊(duì)時(shí)間，Coredump 數(shù)量，下游引擎失敗率，下游引擎延時(shí)變化

第二行展示業(yè)務(wù)的延遲（50%和95%延遲），流量，吞吐（按照不同錯(cuò)誤碼）

第三行展示下游引擎的延遲（50%和95%延遲），流量，吞吐（按照不同錯(cuò)誤碼）

能夠展示 Prometheus 強(qiáng)大威力的是，這里面每一個(gè)圖表，都可以同時(shí)展示所有機(jī)房的監(jiān)控指標(biāo)，而每一個(gè)指標(biāo)的計(jì)算只需要一條 Query 語句。比如第一行第五列，各個(gè)機(jī)房的各個(gè)下游的失敗率統(tǒng)計(jì)并排序，只用了一條語句：

topk(5, 100*sum(rate(downstream_responses{error_code!="0"}[5m])) by (job, server)/sum(rate(downstream_responses[5m])) by (job, server)) 注意這里的Range Vector Selector - [5m]，意味著我們是基于過去5分鐘的數(shù)據(jù)來計(jì)算rate，這個(gè)值取的越小，得到的監(jiān)控結(jié)果波動(dòng)越大，越大則越平滑，選擇多大的值，取決于你想要什么結(jié)果。建議圖表使用5m，而告警規(guī)則計(jì)算采用1m。如果業(yè)務(wù)不是很重要，可以適當(dāng)增大這個(gè)值。 這一套監(jiān)控模板基本覆蓋了業(yè)務(wù)對可用性監(jiān)控的需求，同時(shí)業(yè)務(wù)也可以自己定義監(jiān)控指標(biāo)并進(jìn)行監(jiān)控。

AlertManager

Prometheus 周期性進(jìn)行抓取數(shù)據(jù)，完成抓取后會(huì)檢查是否有告警規(guī)則并進(jìn)行計(jì)算，滿足告警規(guī)則就會(huì)觸發(fā)告警，發(fā)送到 alertmanager?；谶@個(gè)流程，當(dāng)你在監(jiān)控圖表看到異常時(shí)，告警已經(jīng)先行觸發(fā)了。

默認(rèn)情況我們配置了不到10條告警規(guī)則，要注意的是周期的選擇，過長的話會(huì)產(chǎn)生較大延遲，太短的話一個(gè)小的流量波動(dòng)都會(huì)導(dǎo)致大量報(bào)警出現(xiàn)。 Prometheus 的設(shè)計(jì)是產(chǎn)生報(bào)警，但報(bào)警的匯總、分發(fā)、屏蔽則在 AlertManager 服務(wù)完成。

AlertManager 目前還是非常簡單的，但它可以將告警繼續(xù)分發(fā)到其他接收者：

可以通過webhook機(jī)制，發(fā)送告警到一個(gè)中間服務(wù)轉(zhuǎn)換格式再發(fā)送到內(nèi)部告警接口

如果使用第三方告警管理平臺，如PageDuty、OneAlert，可以直接用內(nèi)置的 pageduty 支持或 webhook 發(fā)送告警過去

如果是一窮二白的團(tuán)隊(duì)，建議配置 email + slack，實(shí)現(xiàn)告警歸檔和手機(jī) Push

更復(fù)雜告警分級管理，AlertManager 還是有很長的路要走，這個(gè)話題也值得今后單獨(dú)講下。

Prometheus + Grafana + Mesos

Prometheus + Grafana 的方案，加上統(tǒng)一的服務(wù)框架，可以滿足大部分中小團(tuán)隊(duì)的監(jiān)控需求。我們將這幾個(gè)組件打包一起部署在 Mesos 之上，統(tǒng)一的安裝包進(jìn)一步降低監(jiān)控系統(tǒng)部署的難度，用戶需要配置一些簡單的參數(shù)即可。但還需要注意幾點(diǎn)：

目前并沒有將 Prometheus 和 Grafana 容器化部署，因?yàn)檫@兩者本身就沒有什么特殊依賴；安裝包存儲(chǔ)在 minio 中。

由于 Prometheus 系統(tǒng)的特殊性，我們通常將其指定在一臺固定的機(jī)器上執(zhí)行，且將數(shù)據(jù)落地到一個(gè)固定的目錄，這樣重啟 Prometheus 的影響會(huì)非常低

Grafana 是展示給用戶的，需要盡可能的保持固定入口，所以我們通過HAPROXY_CONSUL給其配置了代理

結(jié) 論

Prometheus 是相當(dāng)強(qiáng)大并快速成長的一個(gè)監(jiān)控系統(tǒng)實(shí)現(xiàn)，雖然在穩(wěn)定性、性能、文檔上仍有很大提升空間，但對于中小團(tuán)隊(duì)是一個(gè)很棒的選擇，通過定制服務(wù)框架，設(shè)計(jì)完善的埋點(diǎn)，統(tǒng)一的Prometheus/Grafana配置模板，再加上Mesos平臺，可以半自動(dòng)化的部署實(shí)時(shí)業(yè)務(wù)監(jiān)控系統(tǒng)。

審核編輯 ：李倩