Prometheus 是一款基於時序資料庫的開源監控告警系統，說起 Prometheus 則不得不提 SoundCloud，這是一個線上音樂分享的平臺，類似於做影片分享的 YouTube，由於他們在微服務架構的道路上越走越遠，出現了成百上千的服務，使用傳統的監控系統 StatsD 和 Graphite 存在大量的侷限性。
於是他們在 2012 年開始著手開發一套全新的監控系統。Prometheus 的原作者是 Matt T。 Proud，他也是在 2012 年加入 SoundCloud 的，實際上，在加入 SoundCloud 之前，Matt 一直就職於 Google，他從 Google 的叢集管理器 Borg 和它的監控系統 Borgmon 中獲取靈感，開發了開源的監控系統 Prometheus，和 Google 的很多專案一樣，使用的程式語言是 Go。
很顯然，Prometheus 作為一個微服務架構監控系統的解決方案，它和容器也脫不開關係。早在 2006 年 8 月 9 日，Eric Schmidt 在搜尋引擎大會上首次提出了雲計算（Cloud Computing）的概念，在之後的十幾年裡，雲計算的發展勢如破竹。
在 2013 年，Pivotal 的 Matt Stine 又提出了雲原生（Cloud Native）的概念，雲原生由微服務架構、DevOps 和以容器為代表的敏捷基礎架構組成，幫助企業快速、持續、可靠、規模化地交付軟體。
為了統一雲計算介面和相關標準，2015 年 7 月，隸屬於 Linux 基金會的 雲原生計算基金會（CNCF，Cloud Native Computing Foundation） 應運而生。第一個加入 CNCF 的專案是 Google 的 Kubernetes，而 Prometheus 是第二個加入的（2016 年）。
目前 Prometheus 已經廣泛用於 Kubernetes 叢集的監控系統中，對 Prometheus 的歷史感興趣的同學可以看看 SoundCloud 的工程師 Tobias Schmidt 在 2016 年的 PromCon 大會上的演講：The History of Prometheus at SoundCloud 。
|
1 Prometheus 概述
我們在 SoundCloud 的官方部落格中可以找到一篇關於他們為什麼需要新開發一個監控系統的文章 Prometheus： Monitoring at SoundCloud，在這篇文章中，他們介紹到，他們需要的監控系統必須滿足下面四個特性：
A multi-dimensional data model， so that data can be sliced and diced at will， along dimensions like instance， service， endpoint， and method。
Operational simplicity， so that you can spin up a monitoring server where and when you want， even on your local workstation， without setting up a distributed storage backend or reconfiguring the world。
Scalable data collection and decentralized architecture， so that you can reliably monitor the many instances of your services， and independent teams can set up independent monitoring servers。
Finally， a powerful query language that leverages the data model for meaningful alerting （including easy silencing） and graphing （for dashboards and for ad-hoc exploration）。
簡單來說，就是下面四個特性：
多維度資料模型
方便的部署和維護
靈活的資料採集
強大的查詢語言
實際上，多維度資料模型和強大的查詢語言這兩個特性，正是時序資料庫所要求的，所以 Prometheus 不僅僅是一個監控系統，同時也是一個時序資料庫。那為什麼 Prometheus 不直接使用現有的時序資料庫作為後端儲存呢？這是因為 SoundCloud 不僅希望他們的監控系統有著時序資料庫的特點，而且還需要部署和維護非常方便。
縱觀比較流行的時序資料庫（參見下面的附錄），他們要麼元件太多，要麼外部依賴繁重，比如：Druid 有 Historical、MiddleManager、Broker、Coordinator、Overlord、Router 一堆的元件，而且還依賴於 ZooKeeper、Deep storage（HDFS 或 S3 等），Metadata store（PostgreSQL 或 MySQL），部署和維護起來成本非常高。而 Prometheus 採用去中心化架構，可以獨立部署，不依賴於外部的分散式儲存，你可以在幾分鐘的時間裡就可以搭建出一套監控系統。
此外，Prometheus 資料採集方式也非常靈活。要採集目標的監控資料，首先需要在目標處安裝資料採集元件，這被稱之為 Exporter，它會在目標處收集監控資料，並暴露出一個 HTTP 介面供 Prometheus 查詢，Prometheus 透過 Pull 的方式來採集資料，這和傳統的 Push 模式不同。
不過 Prometheus 也提供了一種方式來支援 Push 模式，你可以將你的資料推送到 Push Gateway，Prometheus 透過 Pull 的方式從 Push Gateway 獲取資料。目前的 Exporter 已經可以採集絕大多數的第三方資料，比如 Docker、HAProxy、StatsD、JMX 等等，官網有一份 Exporter 的列表。
除了這四大特性，隨著 Prometheus 的不斷髮展，開始支援越來越多的高階特性，比如：服務發現，更豐富的圖表展示，使用外部儲存，強大的告警規則和多樣的通知方式。
下圖是 Prometheus 的整體架構圖：
從
上圖
可以看出，Prometheus 生態系統包含了幾個關鍵的元件：Prometheus server、Pushgateway、Alertmanager、Web UI 等，但是大多陣列件都不是必需的，其中最核心的元件當然是 Prometheus server，它負責收集和儲存指標資料，支援表示式查詢，和告警的生成。接下來我們就來安裝 Prometheus server。
|
2
安裝 Prometheus server
Prometheus 可以支援多種安裝方式，包括 Docker、Ansible、Chef、Puppet、Saltstack 等。下面介紹最簡單的兩種方式，一種是直接使用編譯好的可執行檔案，開箱即用，另一種是使用 Docker 映象。
2。1 開箱即用
首先從 官網的下載頁面 獲取 Prometheus 的最新版本和下載地址，目前最新版本是 2。4。3（2018年10月），執行下面的命令下載並解壓：
$ wget https：//github。com/prometheus/prometheus/releases/download/v2。4。3/prometheus-2。4。3。linux-amd64。tar。gz $ tar xvfz prometheus-2。4。3。linux-amd64。tar。gz
然後切換到解壓目錄，檢查 Prometheus 版本：
$ cd prometheus-2。4。3。linux-amd64 $ 。/prometheus ——version prometheus， version 2。4。3 （branch： HEAD， revision： 167a4b4e73a8eca8df648d2d2043e21bdb9a7449） build user： root@1e42b46043e9 build date： 20181004-08：42：02 go version： go1。11。1
執行 Prometheus server：
$ 。/prometheus ——config。file=prometheus。yml
2。2 使用 Docker 映象
Docker 基礎就不介紹了，參考我之前寫的系列教程：部落格地址：http：//www。javastack。cn/
基礎教程：
Docker 教程，詳細到令人髮指。
使用 Docker 安裝 Prometheus 更簡單，執行下面的命令即可：
$ sudo docker run -d -p 9090：9090 prom/prometheus
一般情況下，我們還會指定配置檔案的位置：
$ sudo docker run -d -p 9090：9090 \ -v ~/docker/prometheus/：/etc/prometheus/ \ prom/prometheus
我們把配置檔案放在本地
~/docker/prometheus/prometheus。yml
，這樣可以方便編輯和檢視，透過
-v
引數將本地的配置檔案掛載到
/etc/prometheus/
位置，這是 prometheus 在容器中預設載入的配置檔案位置。
如果我們不確定預設的配置檔案在哪，可以先執行上面的不帶
-v
引數的命令，然後透過
docker inspect
命名看看容器在執行時預設的引數有哪些（下面的 Args 引數）：
$ sudo docker inspect 0c ［。。。］ “Id”： “0c4c2d0eed938395bcecf1e8bb4b6b87091fc4e6385ce5b404b6bb7419010f46”， “Created”： “2018-10-15T22：27：34。56050369Z”， “Path”： “/bin/prometheus”， “Args”： ［ “——config。file=/etc/prometheus/prometheus。yml”， “——storage。tsdb。path=/prometheus”， “——web。console。libraries=/usr/share/prometheus/console_libraries”， “——web。console。templates=/usr/share/prometheus/consoles” ］， ［。。。］
2。3 配置 Prometheus
正如上面兩節看到的，Prometheus 有一個配置檔案，透過引數
——config。file
來指定，配置檔案格式為 YAML。我們可以開啟預設的配置檔案
prometheus。yml
看下里面的內容：
/etc/prometheus $ cat prometheus。yml # my global config global： scrape_interval： 15s # Set the scrape interval to every 15 seconds。 Default is every 1 minute。 evaluation_interval： 15s # Evaluate rules every 15 seconds。 The default is every 1 minute。 # scrape_timeout is set to the global default （10s）。 # Alertmanager configuration alerting： alertmanagers： - static_configs： - targets： # - alertmanager：9093 # Load rules once and periodically evaluate them according to the global ‘evaluation_interval’。 rule_files： # - “first_rules。yml” # - “second_rules。yml” # A scrape configuration containing exactly one endpoint to scrape： # Here it‘s Prometheus itself。 scrape_configs： # The job name is added as a label `job=
Prometheus 預設的配置檔案分為四大塊：
global 塊：Prometheus 的全域性配置，比如
scrape_interval
表示 Prometheus 多久抓取一次資料，
evaluation_interval
表示多久檢測一次告警規則；
alerting 塊：關於 Alertmanager 的配置，這個我們後面再看；
rule_files 塊：告警規則，這個我們後面再看；
scrape_config 塊：這裡定義了 Prometheus 要抓取的目標，我們可以看到預設已經配置了一個名稱為
prometheus
的 job，這是因為 Prometheus 在啟動的時候也會透過 HTTP 介面暴露自身的指標資料，這就相當於 Prometheus 自己監控自己，雖然這在真正使用 Prometheus 時沒啥用處，但是我們可以透過這個例子來學習如何使用 Prometheus；可以訪問
http：//localhost：9090/metrics
檢視 Prometheus 暴露了哪些指標；
|3 學習 PromQL
透過上面的步驟安裝好 Prometheus 之後，我們現在可以開始體驗 Prometheus 了。Prometheus 提供了視覺化的 Web UI 方便我們操作，直接訪問
http：//localhost：9090/
即可，它預設會跳轉到 Graph 頁面：
第一次訪問這個頁面可能會不知所措，我們可以先看看其他選單下的內容，比如：Alerts 展示了定義的所有告警規則，Status 可以檢視各種 Prometheus 的狀態資訊，有 Runtime & Build Information、Command-Line Flags、Configuration、Rules、Targets、Service Discovery 等等。
實際上 Graph 頁面才是 Prometheus 最強大的功能，在這裡我們可以使用 Prometheus 提供的一種特殊表示式來查詢監控資料，這個表示式被稱為 PromQL（Prometheus Query Language）。透過 PromQL 不僅可以在 Graph 頁面查詢資料，而且還可以透過 Prometheus 提供的 HTTP API 來查詢。查詢的監控資料有列表和曲線圖兩種展現形式（對應上圖中 Console 和 Graph 這兩個標籤）。
我們上面說過，Prometheus 自身也暴露了很多的監控指標，也可以在 Graph 頁面查詢，展開 Execute 按鈕旁邊的下拉框，可以看到很多指標名稱，我們隨便選一個，譬如：
promhttp_metric_handler_requests_total
，這個指標表示
/metrics
頁面的訪問次數，Prometheus 就是透過這個頁面來抓取自身的監控資料的。在 Console 標籤
中查詢結果
如下：
上面在介紹 Prometheus 的配置檔案時，可以看到
scrape_interval
引數是 15s，也就是說 Prometheus 每 15s 訪問一次
/metrics
頁面，所以我們過 15s 重新整理下頁面，可以看到指標值會自增。在 Graph 標籤中可以看得更明顯：
3。1 資料模型
要學習 PromQL，首先我們需要了解下 Prometheus 的資料模型，一條 Prometheus 資料由一個指標名稱（metric）和 N 個標籤（label，N >= 0）組成的，比如下面這個例子：
promhttp_metric_handler_requests_total{code=“200”，instance=“192。168。0。107：9090”，job=“prometheus”} 106
這條資料的指標名稱為
promhttp_metric_handler_requests_total
，並且包含三個標籤
code
、
instance
和
job
，這條記錄的值為 106。上面說過，Prometheus 是一個時序資料庫，相同指標相同標籤的資料構成一條時間序列。如果以傳統資料庫的概念來理解時序資料庫，可以把指標名當作表名，標籤是欄位，timestamp 是主鍵，還有一個 float64 型別的欄位表示值（Prometheus 裡面所有值都是按 float64 儲存）。
這種資料模型和 OpenTSDB 的資料模型是比較類似的，詳細的資訊可以參考官網文件 Data model。另外，關於指標和標籤的命名，官網有一些指導性的建議，可以參考 Metric and label naming 。
雖然 Prometheus 裡儲存的資料都是 float64 的一個數值，但如果我們按型別來分，可以把 Prometheus 的資料分成四大類：
Counter
Gauge
Histogram
Summary
Counter 用於計數，例如：請求次數、任務完成數、錯誤發生次數，這個值會一直增加，不會減少。Gauge 就是一般的數值，可大可小，例如：溫度變化、記憶體使用變化。Histogram 是直方圖，或稱為柱狀圖，常用於跟蹤事件發生的規模，例如：請求耗時、響應大小。
它特別之處是可以對記錄的內容進行分組，提供 count 和 sum 的功能。Summary 和 Histogram 十分相似，也用於跟蹤事件發生的規模，不同之處是，它提供了一個 quantiles 的功能，可以按百分比劃分跟蹤的結果。例如：quantile 取值 0。95，表示取取樣值裡面的 95% 資料。更多資訊可以參考官網文件 Metric types，Summary 和 Histogram 的概念比較容易混淆，屬於比較高階的指標型別，可以參考 Histograms and summaries 這裡的說明。
這四種類型的資料只在指標的提供方作區分，也就是上面說的 Exporter，如果你需要編寫自己的 Exporter 或者在現有系統中暴露供 Prometheus 抓取的指標，你可以使用 Prometheus client libraries，這個時候你就需要考慮不同指標的資料型別了。如果你不用自己實現，而是直接使用一些現成的 Exporter，然後在 Prometheus 裡查查相關的指標資料，那麼可以不用太關注這塊，不過理解 Prometheus 的資料型別，對寫出正確合理的 PromQL 也是有幫助的。
3。2 PromQL 入門
我們從一些例子開始學習 PromQL，最簡單的 PromQL 就是直接輸入指標名稱，比如：
# 表示 Prometheus 能否抓取 target 的指標，用於 target 的健康檢查 up
這條語句會查出 Prometheus 抓取的所有 target 當前執行情況，譬如下面這樣：
up{instance=“192。168。0。107：9090”，job=“prometheus”} 1 up{instance=“192。168。0。108：9090”，job=“prometheus”} 1 up{instance=“192。168。0。107：9100”，job=“server”} 1 up{instance=“192。168。0。108：9104”，job=“mysql”} 0
也可以指定某個 label 來查詢：
up{job=“prometheus”}
這種寫法被稱為 Instant vector selectors，這裡不僅可以使用
=
號，還可以使用
！=
、
=~
、
！~
，比如下面這樣：
up{job！=“prometheus”} up{job=~“server|mysql”} up{job=~“192\。168\。0\。107。+”}
=~
是根據正則表示式來匹配，必須符合 RE2 的語法。
和 Instant vector selectors 相應的，還有一種選擇器，叫做 Range vector selectors，它可以查出一段時間內的所有資料：
http_requests_total［5m］
這條語句查出 5 分鐘內所有抓取的 HTTP 請求數，注意它返回的資料型別是
Range vector
，沒辦法在 Graph 上顯示成曲線圖，一般情況下，會用在 Counter 型別的指標上，並和
rate（）
或
irate（）
函式一起使用（注意 rate 和 irate 的區別）。
# 計算的是每秒的平均值，適用於變化很慢的 counter # per-second average rate of increase， for slow-moving counters rate（http_requests_total［5m］） # 計算的是每秒瞬時增加速率，適用於變化很快的 counter # per-second instant rate of increase， for volatile and fast-moving counters irate（http_requests_total［5m］）
此外，PromQL 還支援
count
、
sum
、
min
、
max
、
topk
等 聚合操作，還支援
rate
、
abs
、
ceil
、
floor
等一堆的 內建函式，更多的例子，還是上官網學習吧。如果感興趣，我們還可以把 PromQL 和 SQL 做一個對比，會發現 PromQL 語法更簡潔，查詢效能也更高。
3。3 HTTP API
我們不僅僅可以在 Prometheus 的 Graph 頁面查詢 PromQL，Prometheus 還提供了一種 HTTP API 的方式，可以更靈活的將 PromQL 整合到其他系統中使用，譬如下面要介紹的 Grafana，就是透過 Prometheus 的 HTTP API 來查詢指標資料的。實際上，我們在 Prometheus 的 Graph 頁面查詢也是使用了 HTTP API。
我們看下 Prometheus 的 HTTP API 官方文件，它提供了下面這些介面：
GET /api/v1/query
GET /api/v1/query_range
GET /api/v1/series
GET /api/v1/label/
GET /api/v1/targets
GET /api/v1/rules
GET /api/v1/alerts
GET /api/v1/targets/metadata
GET /api/v1/alertmanagers
GET /api/v1/status/config
GET /api/v1/status/flags
從 Prometheus v2。1 開始，又新增了幾個用於管理 TSDB 的介面：
POST /api/v1/admin/tsdb/snapshot
POST /api/v1/admin/tsdb/delete_series
POST /api/v1/admin/tsdb/clean_tombstones
| 4 安裝 Grafana
雖然 Prometheus 提供的 Web UI 也可以很好的檢視不同指標的檢視，但是這個功能非常簡單，只適合用來除錯。要實現一個強大的監控系統，還需要一個能定製展示不同指標的面板，能支援不同型別的展現方式（曲線圖、餅狀圖、熱點圖、TopN 等），這就是儀表盤（Dashboard）功能。
因此 Prometheus 開發了一套儀表盤系統 PromDash，不過很快這套系統就被廢棄了，官方開始推薦使用 Grafana 來對 Prometheus 的指標資料進行視覺化，這不僅是因為 Grafana 的功能非常強大，而且它和 Prometheus 可以完美的無縫融合。
Grafana 是一個用於視覺化大型測量資料的開源系統，它的功能非常強大，介面也非常漂亮，使用它可以建立自定義的控制面板，你可以在面板中配置要顯示的資料和顯示方式，它 支援很多不同的資料來源，比如：Graphite、InfluxDB、OpenTSDB、Elasticsearch、Prometheus 等，而且它也 支援眾多的外掛。
下面我們就體驗下使用 Grafana 來展示 Prometheus 的指標資料。首先我們來安裝 Grafana，我們使用最簡單的 Docker 安裝方式：
$ docker run -d -p 3000：3000 grafana/grafana
執行上面的 docker 命令，Grafana 就安裝好了！你也可以採用其他的安裝方式，參考 官方的安裝文件。安裝完成之後，我們訪問
http：//localhost：3000/
進入 Grafana 的登陸頁面，輸入預設的使用者名稱和密碼（admin/admin）即可。
要使用 Grafana，第一步當然是要配置資料來源，告訴 Grafana 從哪裡取資料，我們點選 Add data source 進入資料來源
的配置頁面：
我們在這裡依次填上：
Name： prometheus
Type： Prometheus
URL： http：//localhost：9090
Access： Browser
要注意的是，這裡的 Access 指的是 Grafana 訪問資料來源的方式，有 Browser 和 Proxy 兩種方式。Browser 方式表示當用戶訪問 Grafana 面板時，瀏覽器直接透過 URL 訪問資料來源的；而 Proxy 方式表示瀏覽器先訪問 Grafana 的某個代理介面（介面地址是
/api/datasources/proxy/
），由 Grafana 的服務端來訪問資料來源的 URL，如果資料來源是部署在內網，使用者透過瀏覽器無法直接訪問時，這種方式非常有用。
配置好資料來源，Grafana 會預設提供幾個已經配置好的面板供你使用，如下圖所示，預設提供了三個面板：Prometheus Stats、Prometheus 2。0 Stats 和 Grafana metrics。點選 Import 就可以匯入並使用該面板。
我們匯入 Prometheus 2。0 Stats 這個面板，可以看到下面這樣的監控面板。如果你的公司有條件，可以申請個大顯示器掛在牆上，將這個面板投影在大屏上，實時觀察線上系統的狀態，可以說是非常 cool 的。
| 5 使用 Exporter 收集指標
目前為止，我們看到的都還只是一些沒有實際用途的指標，如果我們要在我們的生產環境真正使用 Prometheus，往往需要關注各種各樣的指標，譬如伺服器的 CPU負載、記憶體佔用量、IO開銷、入網和出網流量等等。
正如上面所說，Prometheus 是使用 Pull 的方式來獲取指標資料的，要讓 Prometheus 從目標處獲得資料，首先必須在目標上安裝指標收集的程式，並暴露出 HTTP 介面供 Prometheus 查詢，這個指標收集程式被稱為 Exporter，不同的指標需要不同的 Exporter 來收集，目前已經有大量的 Exporter 可供使用，幾乎囊括了我們常用的各種系統和軟體。
官網列出了一份 常用 Exporter 的清單，各個 Exporter 都遵循一份埠約定，避免埠衝突，即從 9100 開始依次遞增，這裡是 完整的 Exporter 埠列表。另外值得注意的是，有些軟體和系統無需安裝 Exporter，這是因為他們本身就提供了暴露 Prometheus 格式的指標資料的功能，比如 Kubernetes、Grafana、Etcd、Ceph 等。
這一節就讓我們來收集一些有用的資料。
5。1 收集伺服器指標
首先我們來收集伺服器的指標，這需要安裝 node_exporter，這個 exporter 用於收集 *NIX 核心的系統，如果你的伺服器是 Windows，可以使用 WMI exporter。
和 Prometheus server 一樣，node_exporter 也是開箱即用的：
$ wget https：//github。com/prometheus/node_exporter/releases/download/v0。16。0/node_exporter-0。16。0。linux-amd64。tar。gz $ tar xvfz node_exporter-0。16。0。linux-amd64。tar。gz $ cd node_exporter-0。16。0。linux-amd64 $ 。/node_exporter
node_exporter 啟動之後，我們訪問下
/metrics
介面看看是否能正常獲取伺服器指標：
$ curl http：//localhost：9100/metrics
如果一切 OK，我們可以修改 Prometheus 的配置檔案，將伺服器加到
scrape_configs
中：
scrape_configs： - job_name： ’prometheus‘ static_configs： - targets： ［’192。168。0。107：9090‘］ - job_name： ’server‘ static_configs： - targets： ［’192。168。0。107：9100‘］
修改配置後，需要重啟 Prometheus 服務，或者傳送
HUP
訊號也可以讓 Prometheus 重新載入配置：
$ killall -HUP prometheus
在 Prometheus Web UI 的 Status -> Targets 中，可以看到新加的伺服器：
在 Graph 頁面的指標下拉框可以看到很多名稱以 node 開頭的指標，譬如我們輸入
node_load1
觀察服務
器負載：
如果想在 Grafana 中檢視伺服器的指標，可以在 Grafana 的 Dashboards 頁面 搜尋
node exporter
，有很多的面板模板可以直接使用，譬如：Node Exporter Server Metrics 或者 Node Exporter Full 等。我們開啟 Grafana 的 Import dashboard 頁面，輸入面板的 URL（https：//grafana。com/dashboards/405）或者
ID
（405）
即可。
注意事項
一般情況下，node_exporter 都是直接執行在要收集指標的伺服器上的，官方不推薦用 Docker 來執行 node_exporter。如果逼不得已一定要執行在 Docker 裡，要特別注意，這是因為 Docker 的檔案系統和網路都有自己的 namespace，收集的資料並不是宿主機真實的指標。可以使用一些變通的方法，比如執行 Docker 時加上下面這樣的引數：
docker run -d \ ——net=“host” \ ——pid=“host” \ -v “/：/host：ro，rslave” \ quay。io/prometheus/node-exporter \ ——path。rootfs /host
關於 node_exporter 的更多資訊，可以參考 node_exporter 的文件 和 Prometheus 的官方指南 Monitoring Linux host metrics with the Node Exporter，另外，Julius Volz 的這篇文章 How To Install Prometheus using Docker on Ubuntu 14。04 也是很好的入門材料。
5。2 收集 MySQL 指標
mysqld_exporter 是 Prometheus 官方提供的一個 exporter，我們首先 下載最新版本 並解壓（開箱即用）：
$ wget https：//github。com/prometheus/mysqld_exporter/releases/download/v0。11。0/mysqld_exporter-0。11。0。linux-amd64。tar。gz $ tar xvfz mysqld_exporter-0。11。0。linux-amd64。tar。gz $ cd mysqld_exporter-0。11。0。linux-amd64/
mysqld_exporter 需要連線到 mysqld 才能收集它的指標，可以透過兩種方式來設定 mysqld 資料來源。第一種是透過環境變數
DATA_SOURCE_NAME
，這被稱為 DSN（資料來源名稱），它必須符合 DSN 的格式，一個典型的 DSN 格式像這樣：
user：password@（host：port）/
。
$ export DATA_SOURCE_NAME=’root：123456@（192。168。0。107：3306）/‘ $ 。/mysqld_exporter
另一種方式是透過配置檔案，預設的配置檔案是
~/。my。cnf
，或者透過
——config。my-cnf
引數指定：
$ 。/mysqld_exporter ——config。my-cnf=“。my。cnf”
配置檔案的格式如下：
$ cat 。my。cnf ［client］ host=localhost port=3306 user=root password=123456
如果要把 MySQL 的指標匯入 Grafana，可以參考 這些 Dashboard JSON。
注意事項
這裡為簡單起見，在 mysqld_exporter 中直接使用了 root 連線資料庫，在真實環境中，可以為 mysqld_exporter 建立一個單獨的使用者，並賦予它受限的許可權（PROCESS、REPLICATION CLIENT、SELECT），最好還限制它的最大連線數（MAX_USER_CONNECTIONS）。
CREATE USER ’exporter‘@’localhost‘ IDENTIFIED BY ’password‘ WITH MAX_USER_CONNECTIONS 3； GRANT PROCESS， REPLICATION CLIENT， SELECT ON *。* TO ’exporter‘@’localhost‘；
5。3 收集 Nginx 指標
官方提供了兩種收集 Nginx 指標的方式。
第一種是 Nginx metric library，這是一段 Lua 指令碼（prometheus。lua），Nginx 需要開啟 Lua 支援（libnginx-mod-http-lua 模組）。為方便起見，也可以使用 OpenResty 的 OPM（OpenResty Package Manager） 或者 luarocks（The Lua package manager） 來安裝。
第二種是 Nginx VTS exporter，這種方式比第一種要強大的多，安裝要更簡單，支援的指標也更豐富，它依賴於 nginx-module-vts 模組，vts 模組可以提供大量的 Nginx 指標資料，可以透過 JSON、HTML 等形式檢視這些指標。Nginx VTS exporter 就是透過抓取
/status/format/json
介面來將 vts 的資料格式轉換為 Prometheus 的格式。不過，在 nginx-module-vts 最新的版本中增加了一個新介面：
/status/format/prometheus
，這個介面可以直接返回 Prometheus 的格式，從這點這也能看出 Prometheus 的影響力，估計 Nginx VTS exporter 很快就要退役了（TODO：待驗證）。
除此之外，還有很多其他的方式來收集 Nginx 的指標，比如：
nginx_exporter
透過抓取 Nginx 自帶的統計頁面
/nginx_status
可以獲取一些比較簡單的指標（需要開啟
ngx_http_stub_status_module
模組）；
nginx_request_exporter
透過 syslog 協議 收集並分析 Nginx 的 access log 來統計 HTTP 請求相關的一些指標；
nginx-prometheus-shiny-exporter
和
nginx_request_exporter
類似，也是使用 syslog 協議來收集 access log，不過它是使用 Crystal 語言 寫的。還有
vovolie/lua-nginx-prometheus
基於 Openresty、Prometheus、Consul、Grafana 實現了針對域名和 Endpoint 級別的流量統計。
有需要或感興趣的同學可以對照說明文件自己安裝體驗下，這裡就不一一嘗試了。
5。4 收集 JMX 指標
最後讓我們來看下如何收集 Java 應用的指標，Java 應用的指標一般是透過 JMX（Java Management Extensions） 來獲取的，顧名思義，JMX 是管理 Java 的一種擴充套件，它可以方便的管理和監控正在執行的 Java 程式。
JMX Exporter 用於收集 JMX 指標，很多使用 Java 的系統，都可以使用它來收集指標，比如：Kafaka、Cassandra 等。首先我們下載 JMX Exporter：
$ wget https：//repo1。maven。org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0。3。1/jmx_prometheus_javaagent-0。3。1。jar
JMX Exporter 是一個 Java Agent 程式，在執行 Java 程式時透過
-javaagent
引數來載入：
$ java -javaagent：jmx_prometheus_javaagent-0。3。1。jar=9404：config。yml -jar spring-boot-sample-1。0-SNAPSHOT。jar
其中，9404 是 JMX Exporter 暴露指標的埠，
config。yml
是 JMX Exporter 的配置檔案，它的內容可以 參考 JMX Exporter 的配置說明 。
Spring Boot 教程和示例原始碼推薦：https：//github。com/javastacks/spring-boot-best-practice
然後檢查下指標資料是否正確獲取：
$ curl http：//localhost：9404/metrics
|6告警和通知
至此，我們能收集大量的指標資料，也能透過強大而美觀的面板展示出來。不過作為一個監控系統，最重要的功能，還是應該能及時發現系統問題，並及時通知給系統負責人，這就是 Alerting（告警）。
Prometheus 的告警功能被分成兩部分：一個是告警規則的配置和檢測，並將告警傳送給 Alertmanager，另一個是 Alertmanager，它負責管理這些告警，去除重複資料，分組，並路由到對應的接收方式，發出報警。常見的接收方式有：Email、PagerDuty、HipChat、Slack、OpsGenie、WebHook 等。
6。1 配置告警規則
我們在上面介紹 Prometheus 的配置檔案時瞭解到，它的預設配置檔案 prometheus。yml 有四大塊：
global
、
alerting
、
rule_files
、
scrape_config
，其中
rule_files
塊就是告警規則的配置項，alerting 塊用於配置 Alertmanager，這個我們下一節再看。現在，先讓我們在
rule_files
塊中新增一個告警規則檔案：
rule_files： - “alert。rules”
然後參考 官方文件，建立一個告警規則檔案
alert。rules
：
groups： - name： example rules： # Alert for any instance that is unreachable for >5 minutes。 - alert： InstanceDown expr： up == 0 for： 5m labels： severity： page annotations： summary： “Instance {{ $labels。instance }} down” description： “{{ $labels。instance }} of job {{ $labels。job }} has been down for more than 5 minutes。” # Alert for any instance that has a median request latency >1s。 - alert： APIHighRequestLatency expr： api_http_request_latencies_second{quantile=“0。5”} > 1 for： 10m annotations： summary： “High request latency on {{ $labels。instance }}” description： “{{ $labels。instance }} has a median request latency above 1s （current value： {{ $value }}s）”
這個規則檔案裡，包含了兩條告警規則：
InstanceDown
和
APIHighRequestLatency
。顧名思義，InstanceDown 表示當例項宕機時（up === 0）觸發告警，APIHighRequestLatency 表示有一半的 API 請求延遲大於 1s 時（
api_http_request_latencies_second{quantile=“0。5”} > 1
）觸發告警。
配置好後，需要重啟下 Prometheus server，然後訪問
http：//localhost：9090/rules
可以看到剛剛配置
的規則：
訪問
http：//localhost：9090/alerts
可以看到根據配置的規則生成的告警：
這裡我們將一個例項停掉，可以看到有一條 alert 的狀態是
PENDING
，這表示已經觸發了告警規則，但還沒有達到告警條件。這是因為這裡配置的
for
引數是 5m，也就是 5 分鐘後才會觸發告警，我們等 5 分鐘，可以看到這條 alert 的狀態變成了
FIRING
。
6。2 使用 Alertmanager 傳送告警通知
雖然 Prometheus 的
/alerts
頁面可以看到所有的告警，但是還差最後一步：觸發告警時自動傳送通知。這是由 Alertmanager 來完成的，我們首先 下載並安裝 Alertmanager，和其他 Prometheus 的元件一樣，Alertmanager 也是開箱即用的：
$ wget https：//github。com/prometheus/alertmanager/releases/download/v0。15。2/alertmanager-0。15。2。linux-amd64。tar。gz $ tar xvfz alertmanager-0。15。2。linux-amd64。tar。gz $ cd alertmanager-0。15。2。linux-amd64 $ 。/alertmanager
Alertmanager 啟動後預設可以透過
http：//localhost：9093/
來訪問，但是現在還看不到告警，因為我們還沒有把 Alertmanager 配置到 Prometheus 中，我們回到 Prometheus 的配置檔案
prometheus。yml
，新增下面幾行：
alerting： alertmanagers： - scheme： http static_configs： - targets： - “192。168。0。107：9093”
這個配置告訴 Prometheus，當發生告警時，將告警資訊傳送到 Alertmanager，Alertmanager 的地址為
http：//192。168。0。107：9093
。也可以使用命名行的方式指定 Alertmanager：
$ 。/prometheus -alertmanager。url=http：//192。168。0。107：9093
這個時候再訪問 Alertmanager，可以看到 Alertmanager 已經接
收到告警了
：
下面的問題就是如何讓 Alertmanager 將告警資訊傳送給我們了，我們開啟預設的配置檔案
alertmanager。ym
：
global： resolve_timeout： 5m route： group_by： ［’alertname‘］ group_wait： 10s group_interval： 10s repeat_interval： 1h receiver： ’web。hook‘ receivers： - name： ’web。hook‘ webhook_configs： - url： ’http：//127。0。0。1：5001/‘ inhibit_rules： - source_match： severity： ’critical‘ target_match： severity： ’warning‘ equal： ［’alertname‘， ’dev‘， ’instance‘］
參考 官方的配置手冊 瞭解各個配置項的功能，其中 global 塊表示一些全域性配置；route 塊表示通知路由，可以根據不同的標籤將告警通知傳送給不同的 receiver，這裡沒有配置 routes 項，表示所有的告警都發送給下面定義的 web。hook 這個 receiver；如果要配置多個路由，可以參考 這個例子：
routes： - receiver： ’database-pager‘ group_wait： 10s match_re： service： mysql|cassandra - receiver： ’frontend-pager‘ group_by： ［product， environment］ match： team： frontend
緊接著，receivers 塊表示告警通知的接收方式，每個 receiver 包含一個 name 和一個 xxx_configs，不同的配置代表了不同的接收方式，Alertmanager 內建了下面這些接收方式：
email_config
hipchat_config
pagerduty_config
pushover_config
slack_config
opsgenie_config
victorops_config
wechat_configs
webhook_config
雖然接收方式很豐富，但是在國內，其中大多數接收方式都很少使用。最常用到的，莫屬
email_config
和
webhook_config
，另外
wechat_configs
可以支援使用微信來告警，也是相當符合國情的了。
其實告警的通知方式是很難做到面面俱到的，因為訊息軟體各種各樣，每個國家還可能不同，不可能完全覆蓋到，所以 Alertmanager 已經決定不再新增新的 receiver 了，而是推薦使用 webhook 來整合自定義的接收方式。可以參考 這些整合的例子，譬如 將釘釘接入 Prometheus AlertManager WebHook。
| 7 學習更多
到這裡，我們已經學習了 Prometheus 的大多數功能，結合 Prometheus + Grafana + Alertmanager 完全可以搭建一套非常完整的監控系統。不過在真正使用時，我們會發現更多的問題。
7。1 服務發現
由於 Prometheus 是透過 Pull 的方式主動獲取監控資料，所以需要手工指定監控節點的列表，當監控的節點增多之後，每次增加節點都需要更改配置檔案，非常麻煩，這個時候就需要透過服務發現（service discovery，SD）機制去解決。
Prometheus 支援多種服務發現機制，可以自動獲取要收集的 targets，可以參考 這裡，包含的服務發現機制包括：azure、consul、dns、ec2、openstack、file、gce、kubernetes、marathon、triton、zookeeper（nerve、serverset），配置方法可以參考手冊的 Configuration 頁面。可以說 SD 機制是非常豐富的，但目前由於開發資源有限，已經不再開發新的 SD 機制，只對基於檔案的 SD 機制進行維護。
關於服務發現網上有很多教程，譬如 Prometheus 官方部落格中這篇文章 Advanced Service Discovery in Prometheus 0。14。0 對此有一個比較系統的介紹，全面的講解了 relabeling 配置，以及如何使用 DNS-SRV、Consul 和檔案來做服務發現。
另外，官網還提供了 一個基於檔案的服務發現的入門例子，Julius Volz 寫的 Prometheus workshop 入門教程中也 使用了 DNS-SRV 來當服務發現。
7。2 告警配置管理
無論是 Prometheus 的配置還是 Alertmanager 的配置，都沒有提供 API 供我們動態的修改。一個很常見的場景是，我們需要基於 Prometheus 做一套可自定義規則的告警系統，使用者可根據自己的需要在頁面上建立修改或刪除告警規則，或者是修改告警通知方式和聯絡人，正如在 Prometheus Google Groups 裡的 這個使用者的問題：How to dynamically add alerts rules in rules。conf and prometheus yml file via API or something？
不過遺憾的是，Simon Pasquier 在下面說到，目前並沒有這樣的 API，而且以後也沒有這樣的計劃來開發這樣的 API，因為這樣的功能更應該交給譬如 Puppet、Chef、Ansible、Salt 這樣的配置管理系統。
7。3 使用 Pushgateway
Pushgateway 主要用於收集一些短期的 jobs，由於這類 jobs 存在時間較短，可能在 Prometheus 來 Pull 之前就消失了。官方對 什麼時候該使用 Pushgateway 有一個很好的說明。
附錄：什麼是時序資料庫？
上文提到 Prometheus 是一款基於時序資料庫的監控系統，時序資料庫常簡寫為 TSDB（Time Series Database）。很多流行的監控系統都在使用時序資料庫來儲存資料，這是因為時序資料庫的特點和監控系統不謀而合。
增：需要頻繁的進行寫操作，而且是按時間排序順序寫入
刪：不需要隨機刪除，一般情況下會直接刪除一個時間區塊的所有資料
改：不需要對寫入的資料進行更新
查：需要支援高併發的讀操作，讀操作是按時間順序升序或降序讀，資料量非常大，快取不起作用
DB-Engines 上有一個關於時序資料庫的排名，下面是排名靠前的幾個：
InfluxDB：https：//influxdata。com/
Kdb+：http：//kx。com/
Graphite：http：//graphiteapp。org/
RRDtool：http：//oss。oetiker。ch/rrdtool/
OpenTSDB：http：//opentsdb。net/
Prometheus：https：//prometheus。io/
Druid：http：//druid。io/