Docker+Prometheus+Alertmanager+Webhook釘釘告警

原創 爱是与世界平行 2020-06-19 14:00

Docker+Prometheus+Alertmanager+Webhook釘釘告警

相關內容原文地址：

簡書：fish_man：alertmanager 釘釘告警配置
CSDN：哎_小羊_168：Prometheus 監控報警系統 AlertManager 之郵件告警
博客園：𝖑𝖚𝖘𝖙4𝖑𝖎𝖋𝖊：釘釘報警-prometheus-alertmanager

Docker+Promethues+Grafana環境的安裝，可參考網上相關博文或我的Promethues相關欄目，經實踐全部已經行得通。

此博文主要記錄AlertManager+Webhook的安裝及配置，均採用docker方式，告警郵箱感覺認爲現在不是很常用，所以告警對象爲釘釘機器人。

報警機制：
在 prometheus 中定義你的監控規則，即配置一個觸發器，某個值超過了設置的閾值就觸發告警， prometheus 會推送當前的告警規則到 alertmanager，alertmanager 收到了會進行一系列的流程處理，然後發送到接收人手裏。

Alertmanager 主要用於接收 Prometheus 發送的告警信息，它支持豐富的告警通知渠道，例如郵件、微信、釘釘、Slack 等常用溝通工具，而且很容易做到告警信息進行去重，降噪，分組等，是一款很好用的告警通知系統。

1、環境部署

1.1 二進制部署

# 二進制包下載
https://github.com/timonwong/prometheus-webhook-dingtalk/releases
wget https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v0.3.0/prometheus-webhook-dingtalk-0.3.0.linux-amd64.tar.gz

# 啓動服務
./prometheus-webhook-dingtalk --ding.profile="webhook1=https://oapi.dingtalk.com/robot/send?access_token={替換成自己的dingding token}"

1.2 docker部署

1.2.1 webhook

docker pull timonwong/prometheus-webhook-dingtalk

# 啓動容器
docker run -d -p 8060:8060 --name webhook timonwong/prometheus-webhook --ding.profile="webhook1=https://oapi.dingtalk.com/robot/send?access_token={替換成自己的dingding token}

1.2.2 alertmanager

docker run -d --name alertmanager -p 9093:9093 -v /home/prometheus/alertmanager.yml:/etc/alertmanager/alertmanager.yml prom/alertmanager:latest

2、 配置文件

2.1 alertmanager配置文件

alertmanager.yml

global:
  resolve_timeout: 5m
route:
  receiver: webhook
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 5m
  group_by: [alertname]
  routes:
  - receiver: webhook
    group_wait: 10s
receivers:
- name: webhook
  webhook_configs:
  - url: http://localhost:8060/dingtalk/webhook1/send  
    send_resolved: true

詳細註釋版本：

global:
# 在沒有報警的情況下聲明爲已解決的時間
  resolve_timeout: 2m
# 配置郵件發送信息
  smtp_smarthost: 'smtp.qiye.aliyun.com:465'
  smtp_from: 'your_email'
  smtp_auth_username: 'your_email'
  smtp_auth_password: 'email_passwd'
  smtp_hello: 'your_email'
  smtp_require_tls: false

  # 所有報警信息進入後的根路由，用來設置報警的分發策略
route:
# 這裏的標籤列表是接收到報警信息後的重新分組標籤，例如，接收到的報警信息裏面有許多具有 cluster=A 和 alertname=LatncyHigh 這樣的標籤的報警信息將會批量被聚合到一個分組裏面
  group_by: ['alertname', 'cluster']
# 當一個新的報警分組被創建後，需要等待至少group_wait時間來初始化通知，這種方式可以確保您能有足夠的時間爲同一分組來獲取多個警報，然後一起觸發這個報警信息。
  group_wait: 30s

# 當第一個報警發送後，等待'group_interval'時間來發送新的一組報警信息。
  group_interval: 5m

 # 如果一個報警信息已經發送成功了，等待'repeat_interval'時間來重新發送他們
  repeat_interval: 5m

# 默認的receiver：如果一個報警沒有被一個route匹配，則發送給默認的接收器
  receiver: default  # 優先使用default發送

# 上面所有的屬性都由所有子路由繼承，並且可以在每個子路由上進行覆蓋。
  routes: #子路由，使用email發送
  - receiver: email
    match_re:
      serverity : email  # label 匹配email
    group_wait: 10s
receivers:
- name: 'default'
  webhook_configs:
  - url: http://localhost:8060/dingtalk/webhook1/send  
    send_resolved: true # 發送已解決通知

- name: 'email'
  email_configs:
  - to: '[email protected]'
    send_resolved: true

2.2 prometheus配置文件

prometheus-config.yml

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets: ["localhost:9093"]
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  - "rules.yml"
  # - "second_rules.yml"

3、AlertManager 配置郵件告警

AlertManager 默認配置文件爲 alertmanager.yml，在容器內路徑爲 /etc/alertmanager/alertmanager.yml，默認配置如下：

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']

簡單介紹一下主要配置的作用：

  1. global: 全局配置，包括報警解決後的超時時間、SMTP 相關配置、各種渠道通知的 API 地址等等。
  2. route: 用來設置報警的分發策略，它是一個樹狀結構，按照深度優先從左向右的順序進行匹配。
  3. receivers: 配置告警消息接受者信息，例如常用的 email、wechat、slack、webhook 等消息通知方式。
  4. inhibit_rules: 抑制規則配置，當存在與另一組匹配的警報（源）時，抑制規則將禁用與一組匹配的警報（目標）。
    那麼，我們就來配置一下使用 Email 方式通知報警信息，這裏以 QQ 郵箱爲例，配置如下：
global:
  resolve_timeout: 5m
  smtp_from: '[email protected]'
  smtp_smarthost: 'smtp.qq.com:465'
  smtp_auth_username: '[email protected]'
  smtp_auth_password: 'xxxxxxxxxxxxxxx'
  smtp_require_tls: false
  smtp_hello: 'qq.com'
route:
  group_by: ['alertname']
  group_wait: 5s
  group_interval: 5s
  repeat_interval: 5m
  receiver: 'email'
receivers:
- name: 'email'
  email_configs:
  - to: '[email protected]'
    send_resolved: true
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

將其中幾個關鍵的配置說明一下：

  1. smtp_smarthost: 這裏爲 QQ 郵箱 SMTP 服務地址，官方地址爲 smtp.qq.com 端口爲 465 或 587，同時要設置開啓 POP3/SMTP 服務。
  2. smtp_auth_password: 這裏爲第三方登錄 QQ 郵箱的授權碼，非 QQ 賬戶登錄密碼，否則會報錯，獲取方式在 QQ 郵箱服務端設置開啓 POP3/SMTP 服務時會提示。
  3. smtp_require_tls: 是否使用 tls，根據環境不同，來選擇開啓和關閉。如果提示報錯 email.loginAuth failed: 530 Must issue a STARTTLS command first，那麼就需要設置爲 true。着重說明一下，如果開啓了 tls，提示報錯 starttls failed: x509: certificate signed by unknown authority，需要在 email_configs 下配置 insecure_skip_verify: true 來跳過 tls 驗證。

修改 AlertManager 啓動命令，將本地 alertmanager.yml 文件掛載到容器內指定位置。

$ docker run -d
	--name alertmanager
	-p 9093:9093 
	-v /root/prometheus/alertmanager.yml:/etc/alertmanager/alertmanager.yml
	prom/alertmanager:latest

4、Prometheus 配置 AlertManager 告警規則

在 Prometheus 配置 AlertManager 服務地址以及告警規則，新建報警規則文件 node-up.rules 如下：

$ mkdir -p /root/prometheus/rules && cd /root/prometheus/rules/
$ vim node-up.rules

groups:
- name: node-up
  rules:
  - alert: node-up
    expr: up{job="node-exporter"} == 0
    for: 15s
    labels:
      severity: 1
      team: node
    annotations:
      summary: "{{ $labels.instance }} 已停止運行超過 15s！"

該 rules 目的是監測 node 是否存活，expr 爲 PromQL 表達式驗證特定節點 job=“node-exporter” 是否活着，for 表示報警狀態爲 Pending 後等待 15s 變成 Firing 狀態，一旦變成 Firing 狀態則將報警發送到 AlertManager，labels 和 annotations 對該 alert 添加更多的標識說明信息，所有添加的標籤註解信息，以及 prometheus.yml 中該 job 已添加 label 都會自動添加到郵件內容中.
然後，修改 prometheus.yml 配置文件，添加 rules 規則文件。

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - 172.30.12.39:9093

rule_files:
  - "/usr/local/prometheus/rules/*.rules"

在這裏插入圖片描述
Prometheus Alert 告警狀態有三種狀態：Inactive、Pending、Firing。

  • Inactive：非活動狀態，表示正在監控，但是還未有任何警報觸發。
  • Pending：表示這個警報必須被觸發。由於警報可以被分組、壓抑/抑制或靜默/靜音，所以等待驗證，一旦所有的驗證都通過，則將轉到 Firing 狀態。
  • Firing：將警報發送到 AlertManager，它將按照配置將警報的發送給所有接收者。一旦警報解除，則將狀態轉到 Inactive，如此循環。

5、AlertManager 配置自定義郵件模板

AlertManager 也是支持自定義郵件模板配置的，首先新建一個模板文件 email.tmpl。

$ mkdir -p /root/prometheus/alertmanager-tmpl && cd /root/prometheus/alertmanager-tmpl
$ vim email.tmpl

{{ define "email.from" }}[email protected]{{ end }}
{{ define "email.to" }}[email protected]{{ end }}
{{ define "email.to.html" }}
{{ range .Alerts }}
=========start==========<br>
告警程序: prometheus_alert <br>
告警級別: {{ .Labels.severity }} 級 <br>
告警類型: {{ .Labels.alertname }} <br>
故障主機: {{ .Labels.instance }} <br>
告警主題: {{ .Annotations.summary }} <br>
告警詳情: {{ .Annotations.description }} <br>
觸發時間: {{ .StartsAt.Format "2019-08-04 16:58:15" }} <br>
=========end==========<br>
{{ end }}
{{ end }}

簡單說明一下，上邊模板文件配置了 email.from、email.to、email.to.html 三種模板變量，可以在 alertmanager.yml 文件中直接配置引用。這裏 email.to.html 就是要發送的郵件內容，支持 Html 和 Text 格式，這裏爲了顯示好看，採用 Html 格式簡單顯示信息。下邊 {{ range .Alerts }} 是個循環語法，用於循環獲取匹配的 Alerts 的信息，下邊的告警信息跟上邊默認郵件顯示信息一樣，只是提取了部分核心值來展示。然後，需要增加 alertmanager.yml 文件 templates 配置如下：

global:
  resolve_timeout: 5m
  smtp_from: '{{ template "email.from" . }}'
  smtp_smarthost: 'smtp.qq.com:465'
  smtp_auth_username: '{{ template "email.from" . }}'
  smtp_auth_password: 'xxxxxxxxxxxxxxx'
  smtp_require_tls: false
  smtp_hello: 'qq.com'
templates:
  - '/etc/alertmanager-tmpl/email.tmpl'
route:
  group_by: ['alertname']
  group_wait: 5s
  group_interval: 5s
  repeat_interval: 5m
  receiver: 'email'
receivers:
- name: 'email'
  email_configs:
  - to: '{{ template "email.to" . }}'
    html: '{{ template "email.to.html" . }}'
    send_resolved: true
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

上邊模板中由於配置了 {{ .Annotations.description }} 變量，而之前 node-up.rules 中並沒有配置該變量，會導致獲取不到值，所以這裏我們修改一下 node-up.rules 並重啓 Promethues 服務。
$ vim /root/prometheus/rules/node-up.rules

groups:
- name: node-up
  rules:
  - alert: node-up
    expr: up{job="node-exporter"} == 0
    for: 15s
    labels:
      severity: 1
      team: node
    annotations:
      summary: "{{ $labels.instance }} 已停止運行!"
      description: "{{ $labels.instance }} 檢測到異常停止！請重點關注！！！"

6、prometheus告警規則rules.yml

6.1 cpu_over.yml

groups:
- name: CPU報警規則
  rules:
  - alert: CPU使用率告警
    expr: 100 - (avg by (instance)(irate(node_cpu_seconds_total{mode="idle"}[1m]) )) * 100 > 90
    for: 1m
    labels:
      user: prometheus
      severity: warning
    annotations:
      description: "服務器: CPU使用超過90%！(當前值: {{ $value }}%)"

6.2 memory_over.yml

groups:
- name: 內存報警規則
  rules:
  - alert: 內存使用率告警
    expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes+node_memory_Buffers_bytes+node_memory_Cached_bytes )) / node_memory_MemTotal_bytes * 100 > 80
    for: 1m
    labels:
      user: prometheus
      severity: warning
    annotations:
      description: "服務器: 內存使用超過80%！(當前值: {{ $value }}%)"

6.3 node_down.yml

groups:
- name: 實例存活告警規則
  rules:
  - alert: 實例存活告警
    expr: up == 0
    for: 1m
    labels:
      user: prometheus
      severity: warning
    annotations:
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."

踩坑點：

在這裏插入圖片描述

釘釘機器人的安全設置，我增加了IP限制，導致多次訪問不成功，由於必須添加安全設置，所以添加自定義關鍵字的限制，添加了如下關鍵字：alert、promethues、alertmanager、webhook。可自行決定添加幾個。

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

wmi_exporter+Prometheus+Grafana

wmi_exporter+Prometheus+Grafana 原文地址： CSDN：NRlovestudy：Windows 下搭建 wmi_exporter+Prometheus+Grafana 服務器性能監控平臺 wmi

爱是与世界平行 2020-06-19 14:00:45

Prometheus自定義監控內容

Prometheus自定義監控內容一、io.micrometer的使用1.1 Counter1.2 Gauge1.3 Timer1.4 Summary二、擴展 相關內容原文地址： 博客園：Throwable：基於Promethe

爱是与世界平行 2020-06-19 12:57:18

Spark 應用監控告警-Graphite_exporter

爱是与世界平行 2020-03-19 20:41:51

Prometheus+Grafana通過kafka_exporter監控kafka

爱是与世界平行 2020-03-19 20:41:51

Prometheus和Zabbix的對比

爱是与世界平行 2020-03-17 20:07:29

Prometheus+Grafana監控SpringBoot

爱是与世界平行 2020-03-17 20:07:29

Prometheus-process exporter-進程監控

Prometheus-process exporter-進程監控1、下載安裝2、修改配置文件3、啓動 相關內容原文地址： 博客園：落燁無痕：process exporter 配置項解釋 huandada：Prometheus —

爱是与世界平行 2020-06-19 12:57:18

Spark的運行指標監控

".driver.BlockManager.disk.diskSpaceUsed_MB")//使用的磁盤空間 ".driver.BlockManager.memory.maxMem_MB") //使用的最大內存 ".driver.

爱是与世界平行 2020-06-19 12:57:18

Prometheus 監控之 Blackbox_exporter黑盒監測

Prometheus 監控之 Blackbox_exporter黑盒監測1、blackbox_exporter概述1.1 Blackbox_exporter 應用場景2、blackbox_exporter安裝2.1 Docker方

爱是与世界平行 2020-06-19 12:57:18

Prometheus配置文件

爱是与世界平行 2020-04-03 12:19:14

Spring Boot 微服務應用集成Prometheus + Grafana 實現監控告警

爱是与世界平行 2020-02-25 01:46:56

Zabbix系列優秀博文

爱是与世界平行 2020-02-22 00:24:26

Docker監控平臺prometheus和grafana，監控redis，mysql，docker，服務器信息

爱是与世界平行 2020-02-22 00:24:26

wmi_exporter+Prometheus+Grafana

wmi_exporter+Prometheus+Grafana 原文地址： CSDN：NRlovestudy：Windows 下搭建 wmi_exporter+Prometheus+Grafana 服務器性能監控平臺 wmi

爱是与世界平行 2020-06-19 14:00:45

Prometheus自定義監控內容

Prometheus自定義監控內容一、io.micrometer的使用1.1 Counter1.2 Gauge1.3 Timer1.4 Summary二、擴展 相關內容原文地址： 博客園：Throwable：基於Promethe

爱是与世界平行 2020-06-19 12:57:18