Prometheus和AlertManager的告警机制

本文涉及的产品
可观测监控 Prometheus 版,每月50GB免费额度
简介: 充分了解Prometheus和AlertManager的告警机制

一、上篇文章相关的配置是没有实现邮件通知的版本 以下配置是实现了邮件通知的版本


1、将所有配置由tmp目录迁移到etc目录 原因docker每次启动tmp目录内容都会被清空 所以在tmp目录中的配置不会生效


2、prometheus启动命令修改为


docker run -d -p 9090:9090 \
-v 
/etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml  \
-v
/etc/prometheus/prometheus_rules.yml:/etc/prometheus/prometheus_rules.yml \
-v /etc/prometheus/alertmanager/alertmanager_rules.yml:/etc/prometheus/alertmanager/alertmanager_rules.yml \prom/prometheus


alertmanager_rules.yml和prometheus_rules.yml配置文件在prometheus.yml中被引用

如果本地配置文件路径不对(:之前的路径)docker启动报错

如果docker中路径不对 则docker服务启动不起来


3、/etc/prometheus/prometheus_rules.yml 最新配置


(base) mengfaniaodeMBP:prometheus mengfanxiao$ cat prometheus_rules.yml 
groups:
- name: example   #报警规则的名字
  rules:
  # Alert for any instance that is unreachable for >5 minutes.
  - alert: InstanceDown     #检测job的状态,持续1分钟metrices不能访问会发给altermanager进行报警
    expr: up == 0
    for: 20s    #持续时间
    labels:
      serverity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 20s."
  #- alert: AlertProblem
  #  expr:
  "test_tomcat{exported_instance="uat",exported_job="uat-app-status",host="test",instance="uat",job="uat-apps-status"} -  test_tomcat{exported_instance="uat",exported_job="uat-app-status",host="test",instance="uat",job="uat-apps-status"} offset 1w > 5"   # 这个意思是监控该表达式查询出来的值与一周前的值进行比较,大于5且持续10m钟就发送给altermanager进行报警
  #  for: 1m  #持续时间
  #  labels:
  #    serverity: warning
  #  annotations:
  #    summary: "{{ $labels.type }}趋势增高"
  #    description: "机器:{{ $labels.host }} 
tomcat_id:{{ $labels.id }} 类型:{{ $labels.type }} 与一周前的差值大于5,当前的差值为:{{ $value }}"    #自定义的报警内容

4、/etc/prometheus/alertmanager/alertmanager_rules.yml 最新配置


(base) mengfaniaodeMBP:alertmanager mengfanxiao$ cat alertmanager_rules.yml 
groups:
 - name: test-rules
   rules:
   - alert: InstanceDown # 告警名称
     expr: up == 0 # 告警的判定条件,参考Prometheus高级查询来设定
     for: 10s # 满足告警条件持续时间多久后,才会发送告警
     labels: #标签项
      team: node
     annotations: # 解析项,详细解释告警信息
      summary: "{{$labels.instance}}: has been down"
      description: "{{$labels.instance}}: job
{{$labels.job}} has been down for more than 10s"
     #value: {{$value}}


5、alertmanager启动命令修改为


docker run -d -p 9093:9093 -v
/etc/prometheus/alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml \
-v
/etc/prometheus/alertmanager/template/test.tmpl:/etc/alertmanager/html/template/test.tmpl \
--name alertmanager 
docker.io/prom/alertmanager:latest

6、alertmanager.yml 最新配置


(base) mengfaniaodeMBP:alertmanager mengfanxiao$ cat alertmanager.yml 
# 全局配置项
global: 
  resolve_timeout: 5m #处理超时时间,默认为5min
  smtp_smarthost: 'smtp.qq.com:465' # 邮箱smtp服务器代理
  smtp_from: '15561699@qq.com' # 发送邮箱名称
  smtp_auth_username: '155669@qq.com' # 邮箱名称
  smtp_auth_password: 'qhnoixxzdca' # 邮箱密码或授权码
  wechat_api_url: 'https://qyapi.weixin.qq.com/cgi-bin/' # 企业微信地址
  #require_tls: 'false'
  smtp_require_tls: false
# 定义模板信心
templates:
  - '/etc/alertmanager/html/template/*.tmpl'
# 定义路由树信息
route:
  group_by: ['alertname'] # 报警分组依据
  group_wait: 10s # 最初即第一次等待多久时间发送一组警报的通知
  group_interval: 10s # 在发送新警报前的等待时间
  repeat_interval: 1m # 发送重复警报的周期 对于email配置中,此项不可以设置过低,否则将会由于邮件发送太多频繁,被smtp服务器拒绝
  receiver: 'email' # 发送警报的接收者的名称,以下receivers name的名称
# 定义警报接收者信息
receivers:
  - name: 'email' # 警报
    email_configs: # 邮箱配置
    - to: '3065708685@qq.com'  # 接收警报的email配置
      html: '{{ template "test.tmpl" . }}' # 设定邮箱的内容模板
      headers: { Subject: "[WARN] 报警邮件"} # 接收邮件的标题
      send_resolved: true
     # 第三方开发配置
     #webhook_configs: # webhook配置
    #- url: 'http://127.0.0.1:5001'
    #send_resolved: true
    #wechat_configs: # 企业微信报警配置
    #- send_resolved: true
     #to_party: '1' # 接收组的id
      #agent_id: '1000002' # (企业微信-->自定应用-->AgentId)
      #corp_id: '******' # 企业信息(我的企业-->CorpId[在底部])
      #api_secret: '******' # 企业微信(企业微信-->自定应用-->Secret)
      #message: '{{ template "test_wechat.html" . }}' 
# 发送消息模板的设定
# 一个inhibition规则是在与另一组匹配器匹配的警报存在的条件下,使匹配一组匹配器的警报失效的规则。两个警报必须具有一组相同的标签。 
inhibit_rules: 
  - source_match: 
     severity: 'critical' 
    target_match: 
     severity: 'warning' 
    equal: ['alertname', 'dev', 'instance']


7、模版文件


(base) mengfaniaodeMBP:template mengfanxiao$ cat test.tmpl 
{{ define "test.tmpl" }}
<table border="1">
        <tr>
                <td>报警项</td>
                <td>实例</td>
                <td>报警内容</td>
                <td>开始时间</td>
        </tr>
        {{ range $i, $alert := .Alerts }}
                <tr>
                        <td>{{ index $alert.Labels "alertname" }}</td>
                        <td>{{ index $alert.Labels "instance" }}</td>
                        <td>{{ index $alert.Annotations "description" }}</td>
                        <td>{{ $alert.StartsAt }}</td>
                </tr>
        {{ end }}
</table>
{{ end }}


二、针对以上配置有几点需要说明下


1、receivers html 中的模版名称为 模版文件中 define定义的名称

2、邮件发送邮箱配置


a、开启发送邮箱的smtp服务

微信图片_20220218210929.jpg

b、生成授权码

微信图片_20220218211036.png


三、触发告警演示效果


1)正常效果


a、2个数据源正常运行

微信图片_20220218211039.png

微信图片_20220218211042.png

b、告警规则触发状态

微信图片_20220218211045.png

c、alertmanager未收到告警页面

微信图片_20220218211048.png

2)停止node数据源

微信图片_20220218211051.png

微信图片_20220218211054.png

微信图片_20220218211057.png


其中一个10s的告警规则触发了

微信图片_20220218211059.png

另外一个20的告警规则触发了

微信图片_20220218211102.png


现在状态由inactive->pendding 未激活状态转为等待发射状态

5分钟之后发射了

微信图片_20220218211106.png

alertmanager也收到了告警通知

微信图片_20220218211109.png

报警邮件


微信图片_20220218211113.png

4:32发送第一封告警通知 持续10s prometheus没有收到node的数据

微信图片_20220218211116.png

4:37发送第N封告警通知 持续10s和20s的都没有收到node数据



3)重启启动node


微信图片_20220218211119.png

微信图片_20220218211123.png


之前的触发告警记录也都没有了


微信图片_20220218211126.png

微信图片_20220218211129.png

微信图片_20220218211132.png

4:37发送最后一封告警通知 20s规则的告警 此时10s的那个已经检测到node已经启动了 持续20s的那个还没有检测

10的那个先检测 先通知alertmanger ,altermanager先将10s的那个剔除 此时只通知20s的那个

等20s的那个检测到了 那么也就不会再发送邮件了


相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
相关文章
|
7月前
|
Prometheus Cloud Native 机器人
Prometheus告警简介
Prometheus告警简介
|
Prometheus 监控 Cloud Native
基于k8s+Prometheus+Alertmanager+Grafana构建企业级监控告警系统(下)
基于k8s+Prometheus+Alertmanager+Grafana构建企业级监控告警系统
|
1月前
|
Prometheus 运维 监控
智能运维实战:Prometheus与Grafana的监控与告警体系
【10月更文挑战第26天】Prometheus与Grafana是智能运维中的强大组合,前者是开源的系统监控和警报工具,后者是数据可视化平台。Prometheus具备时间序列数据库、多维数据模型、PromQL查询语言等特性,而Grafana支持多数据源、丰富的可视化选项和告警功能。两者结合可实现实时监控、灵活告警和高度定制化的仪表板,广泛应用于服务器、应用和数据库的监控。
263 3
|
1月前
|
数据采集 Prometheus 监控
Prometheus的告警规则
Prometheus的告警规则
94 11
|
1月前
|
Prometheus Cloud Native
Prometheus的告警处理
【10月更文挑战第31天】Prometheus的告警处理
38 3
|
1月前
|
Prometheus Kubernetes Cloud Native
Prometheus的告警配置
【10月更文挑战第31天】Prometheus的告警配置
50 1
|
1月前
|
Prometheus 运维 监控
智能运维实战:Prometheus与Grafana的监控与告警体系
【10月更文挑战第27天】在智能运维中,Prometheus和Grafana的组合已成为监控和告警体系的事实标准。Prometheus负责数据收集和存储,支持灵活的查询语言PromQL;Grafana提供数据的可视化展示和告警功能。本文介绍如何配置Prometheus监控目标、Grafana数据源及告警规则,帮助运维团队实时监控系统状态,确保稳定性和可靠性。
226 0
|
4月前
|
存储 Prometheus 监控
Prometheus 的报警机制:Alertmanager 的配置与使用
【8月更文第29天】Prometheus 是一个非常强大的监控系统,它不仅能够收集和存储时间序列数据,还能通过 Alertmanager 提供灵活的报警机制。Alertmanager 负责接收 Prometheus 发送的警报,并根据配置的规则执行相应的通知动作。本文将详细介绍如何配置 Alertmanager 以及如何使用它来实现基于 Prometheus 指标的报警通知。
945 0
|
4月前
|
存储 Prometheus Cloud Native
[prometheus]配置alertmanager和钉钉告警
[prometheus]配置alertmanager和钉钉告警
231 0
|
Prometheus 监控 Kubernetes
Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档(上)
Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档