本文可以看做是對《SRE》一書第10章《基于時間序列數(shù)據(jù)進(jìn)行有效報警》的實踐總結(jié)。

Prometheus是一款開源的業(yè)務(wù)監(jiān)控軟件，可以看作是Google內(nèi)部監(jiān)控系統(tǒng) Borgmon 的一個（非官方）實現(xiàn)。

本文會介紹我近期使用Prometheus構(gòu)建的一套完整的，可用于中小規(guī)模（小于500節(jié)點）的半自動化（少量人工操作）監(jiān)控系統(tǒng)方案。

主動監(jiān)控

監(jiān)控是運維系統(tǒng)的基礎(chǔ)，我們衡量一個公司/部門的運維水平，看他們的監(jiān)控系統(tǒng)就可以了。

監(jiān)控手段一般可以分為三種：

• 主動監(jiān)控：業(yè)務(wù)上線前，按照運維制定的標(biāo)準(zhǔn)，預(yù)先埋點。具體的實現(xiàn)方式又有多種，可能通過日志、向本地 Agent 上報、提供 REST API 等。
• 被動監(jiān)控：通常是對主動監(jiān)控的補(bǔ)充，從外圍進(jìn)行黑盒監(jiān)控，通過主動探測服務(wù)的功能可用性來進(jìn)行監(jiān)控。比如定期ping業(yè)務(wù)端口。
• 旁路監(jiān)控：主動監(jiān)控和被動監(jiān)控，通常還是都在內(nèi)部進(jìn)行的監(jiān)控，內(nèi)部運行平穩(wěn)也不能保證用戶的體驗都是正常的（比如用戶網(wǎng)絡(luò)出問題），所以仍然需要通過輿情監(jiān)控、第三方監(jiān)控工具等的數(shù)據(jù)來間接的監(jiān)控真實的服務(wù)質(zhì)量。

主動監(jiān)控是最理想的方案，后兩種主要用作補(bǔ)充，本文只關(guān)注主動監(jiān)控。

監(jiān)控實際是一個端到端的體系（基礎(chǔ)設(shè)施-服務(wù)器-業(yè)務(wù)-用戶體驗），本文只關(guān)注業(yè)務(wù)級別的主動監(jiān)控。

Prometheus

為什么選擇Prometheus而不是其它TSDB實現(xiàn)（如InfluxDB）？主要是因為Prometheus的核心功能，查詢語言 PromQL，它更像一種可編程計算器，而不是其那么像 SQL，也意味著 PromQL 可以近乎無限之組合出各種查詢結(jié)果。

比如，我們有一個http服務(wù)，監(jiān)控項 http_requests_total 用于統(tǒng)計請求次數(shù)。某一組監(jiān)控數(shù)據(jù)可能是這個樣子：

http_requests_total{instance="1.1.1.1:80",job="cluster1",location="/a"} 100
http_requests_total{instance="1.1.1.1:80", job="cluster1", location="/b"} 110
http_requests_total{instance="1.1.1.2:80", job="cluster2", location="/b"} 100
http_requests_total{instance="1.1.1.3:80", job="cluster3", location="/c"} 110

這里有3個標(biāo)簽，分別對應(yīng)抓取的實例，所屬的 Job（一般我用集群名），訪問路徑（你可以理解為Nginx的location），Prometheus多維數(shù)據(jù)模型意味著我們可以在任意一個或多個維度進(jìn)行計算：

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

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

• Counter（計數(shù)器）：標(biāo)識單調(diào)遞增的數(shù)據(jù)，比如接口訪問次數(shù)。
• Gauge（刻度）：當(dāng)前瞬時的一個狀態(tài)，可能增加，也可能減小，比如CPU使用率，平均延時等等。
• Historgram（直方圖）：用于統(tǒng)計數(shù)據(jù)的分布，比如95 percentile latency。

大部分監(jiān)控項都可以使用Counter來實現(xiàn)，少部分使用Gauge和Histogram，其中Histogram在服務(wù)端計算是相當(dāng)費CPU的，所以也沒要導(dǎo)出太多Histogram數(shù)據(jù)。

最后，Prometheus采用PULL模型的實時抓取存儲計算，主動去抓取監(jiān)控實例數(shù)據(jù)，相比于PUSH模型對業(yè)務(wù)侵入更低，相比于基于log的離線統(tǒng)計則更實時，而監(jiān)控實例只需提供一個文本格式的/metrics接口也更容易debug。

服務(wù)框架的改造

筆者所在團(tuán)隊使用統(tǒng)一的服務(wù)框架來規(guī)范項目開發(fā)并有效降低了開發(fā)難度。

這里先介紹下我們的服務(wù)框架：

• 類似于 Nginx 的多進(jìn)程架構(gòu)（master/worker），但同時也支持多線程的事件循環(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)控項，主要涉及幾方面的工作：

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

• 目前并沒有官方的Prometheus Client Library，幾種開源實現(xiàn)也都不太符合框架的需求。目前實現(xiàn)了支持多線程多進(jìn)程的Counter和Histogram（除了初始化之外，更新操作都是無鎖的），而Gauge由于多進(jìn)程場景有的情況是無法聚合監(jiān)控數(shù)據(jù)的（沒用統(tǒng)一的聚合方法，并不一定都可以相加），所以沒有提供具體實現(xiàn)
• 基礎(chǔ)數(shù)據(jù)要有類似注冊表的功能，方便自動導(dǎo)出數(shù)據(jù)到/metrics接口

• 在服務(wù)框架埋點

• 要足夠靈活，將容易變化的信息通過標(biāo)簽來表達(dá)。

           比如一個web服務(wù)可能有echo，date兩個location，如果要統(tǒng)計它們qps，不要定義echo_requests_total, date_requests_total兩個不同名字的 metrics，而應(yīng)該定義一個名為http_requests_total的 metrics，通過標(biāo)簽location（分別為echo/date）來區(qū)分，這樣再增加/減少接口是不需要改代碼的

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

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

具備導(dǎo)出能力后，就可以通過Prometheus 進(jìn)行抓取了，但還有幾個小坑：

用戶定義的metrics名字，可能是不符合Prometheus規(guī)范的，而遇到一條不合法的數(shù)據(jù)，Prometheus就會停止抓取，所以導(dǎo)出數(shù)據(jù)時要先做一遍過濾和改寫

要控制導(dǎo)出數(shù)據(jù)規(guī)模，一些只對單機(jī)監(jiān)控有意義的數(shù)據(jù)可以不導(dǎo)出（框架有針對單機(jī)的監(jiān)控頁面）

在使用 Prometheus 時，也有幾個地方要注意：

Prometheus即是一個CPU密集型（查詢）也是一個IO密集型（數(shù)據(jù)落地）的，CPU數(shù)量是多多益善，內(nèi)存越大越好（來緩存抓取的數(shù)據(jù)，所以應(yīng)該減少不必要的業(yè)務(wù)數(shù)據(jù)導(dǎo)出），盡量要使用SSD（這個很關(guān)鍵?。驗橐坏㏄rometheus的內(nèi)存使用量達(dá)到閾值會停止抓取數(shù)據(jù)！這個停止抓取的時間，至少是分鐘級，甚至是無法恢復(fù)！所以只要有條件就要用SSD。

Prometheus號稱支持 reload，但目測不是很好用，比如你修改了告警規(guī)則文件，重載之后，新舊告警規(guī)則似乎會一起計算執(zhí)行….

Prometheus本身也提供圖形界面，但是很簡陋：

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

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

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

• 第一行展示實時的 QPS，平均延時，平均排隊時間，Coredump 數(shù)量，下游引擎失敗率，下游引擎延時變化
• 第二行展示業(yè)務(wù)的延遲（50%和95%延遲），流量，吞吐（按照不同錯誤碼）
• 第三行展示下游引擎的延遲（50%和95%延遲），流量，吞吐（按照不同錯誤碼）

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

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ù)來計算rate，這個值取的越小，得到的監(jiān)控結(jié)果波動越大，越大則越平滑，選擇多大的值，取決于你想要什么結(jié)果。建議圖表使用5m，而告警規(guī)則計算采用1m。如果業(yè)務(wù)不是很重要，可以適當(dāng)增大這個值。

這一套監(jiān)控模板基本覆蓋了業(yè)務(wù)對可用性監(jiān)控的需求，同時業(yè)務(wù)也可以自己定義監(jiān)控指標(biāo)并進(jìn)行監(jiān)控。

AlertManager

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

默認(rèn)情況我們配置了不到10條告警規(guī)則，要注意的是周期的選擇，過長的話會產(chǎn)生較大延遲，太短的話一個小的流量波動都會導(dǎo)致大量報警出現(xiàn)。

Prometheus 的設(shè)計是產(chǎn)生報警，但報警的匯總、分發(fā)、屏蔽則在 AlertManager 服務(wù)完成。

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

• 可以通過 webhook 機(jī)制，發(fā)送告警到一個中間服務(wù)轉(zhuǎn)換格式再發(fā)送到內(nèi)部告警接口
• 如果使用第三方告警管理平臺，如PageDuty、OneAlert，可以直接用內(nèi)置的 pageduty 支持或 webhook 發(fā)送告警過去
• 如果是一窮二白的團(tuán)隊，建議配置 email + slack，實現(xiàn)告警歸檔和手機(jī) Push

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

Prometheus + Grafana + Mesos

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

• 目前并沒有將 Prometheus 和 Grafana 容器化部署，因為這兩者本身就沒有什么特殊依賴；安裝包存儲在 minio 中。
• 由于 Prometheus 系統(tǒng)的特殊性，我們通常將其指定在一臺固定的機(jī)器上執(zhí)行，且將數(shù)據(jù)落地到一個固定的目錄，這樣重啟 Prometheus 的影響會非常低
• Grafana 是展示給用戶的，需要盡可能的保持固定入口，所以我們通過 HAPROXY_CONSUL 給其配置了代理

結(jié)論

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