昔日教人類用火的prometheus，如今在努力報警

• 2019 年 11 月 28 日
• 筆記

原創：小姐姐味道（微信公眾號ID：xjjdog），歡迎分享，轉載請保留出處。

像我這麼熱愛野外生活的人，初冬時節，還找了個隱蔽的地方去野炊。現在的社會，為了找找到這麼一個靜謐的存在，我可謂煞費苦心。

初冬的夜，連蟲鳴聲都沒有，星空高而深遠。蜷縮在篝火旁邊，我想起了普羅米修斯。在希臘神話中，他教會人類學會使用火，徹底告別了茹毛飲血的年代。

早在2012年，還有一部叫做《普羅米修斯》的電影上演，它是《異行》的前傳，其壯麗宏大的場景讓人印象深刻。

在這無盡的時空和未知的領域面前，我一個小小程序員，真是連屁都不如。比我強大的比我用功，比如立下flag學python的潘總，他應該能勉強算得上個屁。

普羅米修斯的英文是prometheus，從這拗口的名字就可以看出，它是個舶來品。prometheus是google內部監控報警系統的開源版本，現在非常流行。

監控系統是老生常談的問題了，xjjdog在以前也專門總結過。《這麼多監控組件，總有一款適合你》，這篇長文，從多個維度上介紹了監控體系，而prometheus面向的就是metric類型的數據監控。

今天，我們要着重介紹的，就是prometheus。來勢洶洶，大有一統天下的架勢。本篇文章主要是為了引起你的興趣，並提供了很多實踐過的配置文件。說了這麼多廢話，就讓我們正式開始吧。

1、介紹

你在使用一些類似於grafana的展示組件時，能夠發現底層的數據存儲，能夠使用Prometheus，而這兩個東西明顯沒有血緣關係。在享受grafana至高無上的美麗時，應該認識到一個現實：現在的監控系統，都拆分成了非常具體的細小模塊，讓你可以根據經驗和習慣進行精細化選擇。

Prometheus生態系統由多個組件組成，其中一些是可選的。多數Prometheus組件由Go語言編寫，使這些組件很容易編譯和部署。網上很多文章翻譯的晦澀難懂，xjjdog在這裡便使用人話描述。

註：敲黑板，帶★是重點，要考 。不學沒法用

★1）Prometheus Server：主要負責數據採集和存儲，提供PromQL查詢語言的支持。注意，它同時是一個存儲！

2）客戶端SDK：支持非常多語言的類庫，越多越好。

3）Push Gateway：Prometheus獲取監控數據的主要方式是拉取模式，但總有一些瞬時發生的監控項，這種信息無法pull。所以這個組件是為了支持一些存活時間很短的事件，把這些信息進行緩衝。

4）PromDash：使用Rails開發可視化的Dashboard，用於可視化指標數據

★5）Exporter：數據採集組件，也就是一些agent。負責從目標處搜集數據，並將其轉化為Prometheus支持的格式

★6）Alertmanager：報警管理器，用於發送到正確的邏輯分組。常見的接收方式有：電子郵件，pagerduty，OpsGenie, webhook 等

7）prometheus_cli：命令行工具

8）其他輔助性工具：多種導出工具，可以支持Prometheus存儲數據轉化為HAProxy、StatsD、Graphite等工具所需要的數據存儲格式

長篇大論的扯了一通，還是逃脫不了收集、處理、展示三大部件。看了以上的介紹，你應該能夠看懂這張官方圖。看那些大框框，不要關注細節。

我們來抽取一下比較特殊的要點。 1）它獲取監控數值的方式是拉模式 2）它有一個存儲數據的時序數據庫，查詢語言靈活，但不是SQL 3）有SDK、Agent、中間網關三種數據匯總方式 4）可以使用grafana代替它自帶的醜八怪界面 5）能夠細粒度配置報警，統一管理

2、安裝和配置

了解了上面的組件，安裝配置就順利的多。先把Prometheus下載下來，然後解壓。

cd /opt  wget -c https://github.com/prometheus/prometheus/releases/download/v2.14.0/prometheus-2.14.0.linux-amd64.tar.gz  tar zxvf prometheus-2.14.0.linux-amd64.tar.gz

2.1、配置server

在安裝目錄下編輯配置文件prometheus.yml，我們解釋比較重要的部分。很多時候，我們需要監控非常多的組件，比如系統狀態、canal、kafka、jvm等等，如果將所有的配置文件都放在這裡，勢必會又臭又長，所以一般採用子配置文件的方式。注意，配置文件分了兩部分，上面的是觸發規則，下面的是主機名稱，注意區別。

各個被監控的組件，需要自行部署Exporter，然後把http接口暴露出來。

alerting:    alertmanagers:    - static_configs:      - targets: ["10.81.28.227:9093"]    # 分文件配置，我們以sys系統參數為例說明  rule_files:    - "sys_monit.yml"    - "kafka_monit.yml"  # 抓取配置  scrape_configs:    - job_name: 'prometheus'      static_configs:      - targets: ['localhost:9090']        labels:            group: "監控服務端"      - job_name: 'system'      #通過文件去動態發現配置      file_sd_configs:      - refresh_interval: 1m        files:         - sys.yml #配置文件路徑      - job_name: 'kafka'      file_sd_configs:      - refresh_interval: 1m        files:         - kafka.yml

再來看一下其中一個子配置文件sys.yml，它定義了一批要監控的機器。也就是到什麼地方去找數據。

[     {      "labels": {        "job": "shop001.web.pub.pro.ali.dc",        "instance": "system"      },      "targets": [      "10.174.88.9:9100"      ]   }  ]

然後我們啟動Prometheus：

nohup ./prometheus &

2.2、報警配置

alertmanager需要單獨下載，這種方式真是腦迴路驚奇。

https://github.com/prometheus/alertmanager/releases

報警的配置文件分為兩部分，其中一部分，放在上面的prometheus.yml文件中rule_files模塊，用來指定匹配規則；另外一部分，放在alertmanager.yml中，用來指定報警的去向。

比如，我想要把報警發送到臭名昭著的dingding，就可以這麼寫。

global:    resolve_timeout: 5m    route:    group_by: ['alertname']    group_wait: 10s    group_interval: 10s    repeat_interval: 10m    receiver: 'pro'    routes:    - receiver: 'canal'      match:        alertname: 'canal 延遲'    receivers:  - name: 'sys'    webhook_configs:    - url: 'http://10.81.28.227:8060/dingtalk/pro/send'    - name: 'canal'    webhook_configs:    - url: 'http://10.81.28.227:8060/dingtalk/canal/send'

接下來看一下規則部分，比如sys_monit.yml，你應該看到這個過程是怎麼運轉起來的了。

roups:      - name: netstat_tcp_time_wait        rules:        - alert: 主機連接數 time_wait          expr: netstat_tcp_time_wait > 60000          for: 5m          labels:            status: warning          annotations:            summary: "{{$labels.job}}"            description: "{{ $labels.instance }} time_wait > 60k(當前值：{{ $value}})"

如果你安裝了dashboard的話，應該能看到這些信息了。但是，每次更改閾值，都需要重啟server，這一部分，做的不是很好。另外，yml深層的嵌套信息，在配置繁多的時候，顯得比較雜亂。從上面的配置文件就可以看出，這些配置文件的解析，使用的是簡單的佔位符的方式。在設計報警之前，你需要知道每一個監控項的名稱，以及意義。

3、其他集成

telegraf是比較好用的數據收集agent。通常，它是通過push的方式彙報監控數據，但是通過加入幾行配置，可以把push變成pull（暴露一個專用接口）。主要的配置文件如下：

[[outputs.prometheus_client]]      listen = "0.0.0.0:9100"

以下是一個grafana主機監控的效果圖。由於它的顏值比prometheus自帶的高，所以一般都使用grafana。

但是自帶的UI也不是一無是處，比如下面查看整個系統機器狀態的頁面。

用於調試查詢語句的界面等。

另外，prometheus可以很容易的接入以下的系統：

1) springboot。參見 https://yq.aliyun.com/articles/272542

2） canal接入。在canal.properties 中添加

canal.metrics.pull.port=11112

注意：canal版本必須canal 1.1.x系列以上

End

一個監控系統，主要的難點是生態。prometheus最近幾年發展迅速，非常多的組件都對其進行了集成，這對我們來說是比較大的福音。但是，它的配置文件還是有點複雜，尤其是在管理大型機器群的時候，需要頻繁的更改配置文件，並不能夠做到自動發現。

所以，通常使用prometheus的時候，會配合很多內部系統，寫很多的shell腳本，自動更改這些配置進行重啟，盡量做到自動化。

由於涉及的配置文件，實在是太多，且配置有相對的難度。我將這些信息，放在了倉庫里。有需要的，自行參考。

https://github.com/xjjdog/prometheus-cnf-pro

清單： 1、prometheus配置，規則配置 (11個) 2、alertmanager配置 (1個) 3、telegraf (2個) 4、grafana(5個）

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高並發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。

近期熱門文章

《996的樂趣，你是無法想像的》 魔幻現實主義，關愛神經衰弱

《一切荒誕的傲慢，皆來源於認知》 不要被標題給騙了，畫面感十足的消遣文章

《必看！java後端，亮劍誅仙》 後端技術索引，中肯火爆。全網轉載上百次。

《學完這100多技術，能當架構師么？（非廣告）》 精準點評100多框架，幫你選型

《Linux上，最常用的一批命令解析（10年精選）》 CSDN發佈首日，1k贊。點贊率1/8。