Prometheus实现系统监控报警邮件

Prometheus实现系统监控报警邮件

简介

Prometheus将数据采集和报警分成了两个模块。报警规则配置在Prometheus Servers上，
然后发送报警信息到AlertManger，然后我们的AlertManager就来管理这些报警信息，聚合报警信息过后通过email、PagerDuty、HipChat、Slack 等方式发送消息提示。本文演示通过email发送告警信息。
中文技术文档：https://www.prometheus.wang/alert/install-alert-manager.html
在Prometheus中一条告警规则主要由告警名称和告警规则两部分组成：
告警名称：用户为告警规则命名
告警规则：告警规则由PromQL进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警
Prometheus服务器根据报警规则将警报发送给Alertmanager，然后Alertmanager将静默（silencing）、抑制（inhibition）、分组聚合（aggregation）等消息通过Email、钉钉等发送通知。

报警流程

Prometheus配置监控规则
监控对象触发阈值
阈值超出持续时间
推送告警到Alertmanager
Alertmanager处理告警信息
1）分组(group)：类似告警合并为一个通知。
2）静默(silences)：不通知，系统升级时使用。
3）抑制(inhibition): 只通知一次，相同内容不再通知。
Alertmanager发送通知到媒体，邮箱，钉钉，企业微信等接收到通知

Alertmanager特性

分组聚合：分组将同一类型的报警归类单个报警通知 。适用于当系统宕机导致大量报警被同时触发，此时分组机制可将这些被触发的告警合并为一个告警通知，避- 免一次性发送大量告警通知。

静默：提供了一个简单的机制可以快速根据标签对告警进行静默处理。特定时间不会发送告警通知。

抑制：指当警报发出后，停止重复发送由此警报引发其他错误的警报的机制。如网络不可达，导致其他服务连接相关警报。

安装Alertmanager

下载二进制文件

wget https://github.com/prometheus/alertmanager/releases/download/v0.24.0/alertmanager-0.24.0.linux-amd64.tar.gz
tar zxvf alertmanager-0.24.0.linux-amd64.tar.gz
mv alertmanager-0.24.0.linux-amd64 /usr/local/alertmanager

创建alertermanager服务

vim /etc/systemd/system/alertmanager.service
[Unit]
Description=alertmanager
Documentation=https://prometheus.io/
After=network.target

[Service]
User=root
Type=simple
#不能有单引号和双引号
ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml --storage.path=/usr/local/alertmanager/data --web.listen-address=:19093 --cluster.listen-address=0.0.0.0:19094 --web.external-url=http://192.168.1.108:19093
Restart=on-failure

[Install]
WantedBy=multi-user.target

启动服务：

systemctl daemon-reload
systemctl start  alertmanager
systemctl enable alertmanager
systemctl status alertmanager

访问 192.168.1.108:19093 为alertmanager管理页面：
端口号为你再alertmanager，service中配置的端口

Alertmanager配置

配置文件详解，以邮箱告警为例：

vim /usr/local/alertmanager/alertmanager.yml
#邮件发送者
global:
  resolve_timeout: 30s
  smtp_smarthost: 'smtp.qq.com:465' 
  smtp_from: '[email protected]' 
  smtp_auth_username: '[email protected]' 
  smtp_auth_password: 'xxxxxxxxvpobcee' # QQ邮箱授权码，需要在设置，开启SMTP服务，然后复制授权码到这里
  smtp_hello: '@qq.com'
  smtp_require_tls: false

templates:
  - '/usr/local/alertmanager/tmpl/email.tmpl'  #增加templates配置 不填写，有默认模板
route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 5m
  receiver: 'email'
  routes:
  - receiver: dingtalk-webhook
    group_wait: 10s
  - receiver: email
    group_wait: 10s
receivers:
  - name: 'email'
    email_configs:
      - to: '*****@163.com'
      	html： '{{ template "email.html" . }}' # 发送邮件的内容（调用模板文件中的） 如果使用默认模板，这个“html”可以不添加
        send_resolved: true
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

项目	Value
global	全局设置，这里为邮件发送者的配置
smtp	邮箱smtp设置
group_by	通过alertname的值对告警进行分类
group_wait	第一次产生告警，等待10s，组内有告警就一起发送，内有其他告警就单独发出
group_interval	第二次发生告警，先等待2分钟，2分钟后还没有回复就进入repeat_interval
repeat_interval	再最终发送消息前再等待5分钟，5分钟后还没有回复就发送第二次告警
receiver	接受者，再receivers中选择一个
receivers	定义接受者们，可定义多个
name	接受者名字，将被receiver选择
email_configs	邮箱接受者设置
html	发送邮件的内容（调用模板文件中的）
send_resolved	是否发送告警解决的通知
inhibit_rules	抑制设置，即哪些告警发通知，哪些不发
source_match	源匹配的告警将被通知
severity	严重程度为critical ，重要的告警将被通知
target_match	目标匹配的告警不被通知
severity	严重程度为warming，警告的告警将被通知
equal	匹配哪些对象的告警

编辑报警模块，可用默认模板：

vim /usr/local/alertmanager/tmpl/email.tmpl
{{ define "email.html" }}
{{- if gt (len .Alerts.Firing) 0 -}}{{ range .Alerts }}
<h2>@告警通知</h2>
告警程序: prometheus_alert <br>
告警级别: {{ .Labels.severity }} 级 <br>
告警类型: {{ .Labels.alertname }} <br>
故障主机: {{ .Labels.instance }} <br>
告警主题: {{ .Annotations.summary }} <br>
告警详情: {{ .Annotations.description }} <br>
触发时间: {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }} <br>
{{ end }}{{ end -}}

Prometheus规则

新建规则文件，配置分组信息，告警阈值和时间，告警标签和注释等。
指标表达式采用PromQL语句，多数指标单位为bytes字节，需要转换成KMG，例如2M=210241024。
Prometheus规则文件，对于邮箱，钉钉或企业微信，该文件通用：

vim /home/prometheus/prometheus/rule/tcp_time_wait.yml
groups:
- name: 主机Tcp TimeWait数量过多告警
  rules:
  - alert: 主机Tcp TimeWait数量过多告警
    expr: node_sockstat_TCP_tw >= 100	 # 大于100 做测试用，正常是5000
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "Tcp TimeWait数量大于100, 实例: {{ $labels.instance }}，当前值：{{ $value }}%"

检验prometheus报警规则文件，显示SUCCESS：

/home/prometheus/prometheus/promtool check rules rule/tcp_time_wait.yml
Checking rule/qtalk_auth.yml
  SUCCESS: 1 rules found

Prometheus配置
配置Prometheus文件，alertmanagers服务器的IP和端口，prometheus服务器规则文件的路径：

vim /home/Prometheus/prometheus/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: ["192.168.1.108:19093"]
           #- alertmanager:["192.168.1.108:19093"]

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
 - "rule/*.yml"
  # - "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=` to any timeseries scraped from this config.
  - job_name: "prometheus"

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ["localhost:9090"]

  - job_name: 'process'
    static_configs:
      - targets: ['192.168.1.108:9256']

重启Prometheus服务：

systemctl restart prometheus.service

邮箱告警

查看Prometheus

Prometheus首页，Alerts选项，可以查看告警信息：

报警状态分3种：

inactive：没有异常。
pending：已触发阈值，但未满足告警持续时间（即 rule 中的 for 字段）。
firing：已触发阈值且满足条件并发送至 alertmanager。
pending状态，阈值触发了，但再观察30m秒(for: 30s)。

firing状态，30秒过后还超出阈值，则发送至alertmanager。
查看Alertmanager
只有在Prometheus中Firing的警告才会传到Alertmanager，进入首页查看。

查看邮箱

至此，一个简单的基于Prometheus的系统监控及报警通知的服务都搭建完成，利用这样一套监控通知体系，可以让系统运维人员早早的知道系统健康度，保证系统高可用。