三、 Prometheus：告警规则集、告警接收器、Alertmanager启动参数详解（2）

SteveRocket

已于 2023-06-17 20:59:31 修改

阅读量2.1k

点赞数 1

分类专栏：云原生&监控&可观测性&微服务&SaaS 文章标签： prometheus alertmanager 告警规则集 webhook

于 2023-03-17 18:28:51 首次发布

本文链接：https://blog.csdn.net/zhouruifu2015/article/details/129626005

版权

云原生&监控&可观测性&微服务&SaaS 专栏收录该内容

14 篇文章 15 订阅

订阅专栏

注意：后续技术分享，第一时间更新，以及更多更及时的技术资讯和学习技术资料，将在公众号CTO Plus发布，请关注公众号：CTO Plus

Awesome Prometheus alerts

Awesome Prometheus alerts：Awesome Prometheus alerts | Collection of alerting rules

维护了一套开箱即用的 Prometheus 告警规则集合，有好几百告警规则。这些规则，对每个 Prometheus 都是通用的。涉及如主机、硬件、容器等基础资源，到数据库、消息代理、运行时、反向代理、负责均衡器，运行时、服务编排，甚至是网络层面和 Prometheus 自身和集群。

节点可用内存过低示例：Node memory is filling up (< 10% left)

- alert: HostOutOfMemory
    expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: Host out of memory (instance {{ $labels.instance }})
      description: "Node memory is filling up (< 10% left)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

自定义Prometheus告警规则

Prometheus中的告警规则允许基于PromQL表达式定义告警触发条件，Prometheus后端对这些触发规则进行周期性计算，当满足触发条件后则会触发告警通知。可以通过Prometheus的Web界面查看这些告警规则以及告警的触发状态。当Prometheus与Alertmanager关联之后，可以将告警发送到外部服务如Alertmanager中，并通过Alertmanager可以对这些告警进行进一步的处理。

定义告警规则

groups:
- name: example
  rules:
  - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: high
    annotations:
      summary: High request latency
      description: description info

在告警规则文件中，可以将一组相关的规则设置定义在一个group下。在每一个group中可以定义多个告警规则(rule)。一条告警规则主要由以下几部分组成：

alert：告警规则的名称。
expr：基于PromQL表达式告警触发条件，用于计算是否有时间序列满足该条件。
for：评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
labels：自定义标签，允许用户指定要附加到告警上的一组附加标签。
annotations：用于指定一组附加信息，比如用于描述告警详细信息的文字等，annotations的内容在告警产生时会一同作为参数发送到Alertmanager。

为了能够让Prometheus能够启用定义的告警规则，需要在Prometheus全局配置文件中通过rule_files指定一组告警规则文件的访问路径，Prometheus启动后会自动扫描这些路径下规则文件中定义的内容，并且根据这些规则计算是否向外部发送通知：

rule_files:
  [ - <filepath_glob> ... ]

如图示例：

默认情况下Prometheus会每分钟对这些告警规则进行计算，如果用户想定义自己的告警计算周期，则可以通过evaluation_interval来覆盖默认的计算周期：

global:
  [ evaluation_interval: <duration> | default = 1m ]

模板化

一般来说，在告警规则文件的annotations中使用summary描述告警的概要信息，description用于描述告警的详细信息。同时Alertmanager的UI也会根据这两个标签值，显示告警信息。为了让告警信息具有更好的可读性，Prometheus支持模板化label和annotations的中标签的值。

通过$labels.<labelname>变量可以访问当前告警实例中指定标签的值。$value则可以获取当前PromQL表达式计算的样本值。

# To insert a firing element's label values:
{{ $labels.<labelname> }}
# To insert the numeric expression value of the firing element:
{{ $value }}

例如，可以通过模板化优化summary以及description的内容的可读性：

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)"

内置告警接收器Receiver

在Alertmanager中路由负责对告警信息进行分组匹配，并将像告警接收器发送通知。告警接收器可以通过以下形式进行配置：

receivers:
  - <receiver> ...

每一个receiver具有一个全局唯一的名称，并且对应一个或者多个通知方式：

name: <string>
email_configs:
  [ - <email_config>, ... ]
hipchat_configs:
  [ - <hipchat_config>, ... ]
pagerduty_configs:
  [ - <pagerduty_config>, ... ]
pushover_configs:
  [ - <pushover_config>, ... ]
slack_configs:
  [ - <slack_config>, ... ]
opsgenie_configs:
  [ - <opsgenie_config>, ... ]
webhook_configs:
  [ - <webhook_config>, ... ]
victorops_configs:
  [ - <victorops_config>, ... ]

目前官方内置的第三方通知集成包括：邮件、即时通讯软件（如Slack、Hipchat）、移动应用消息推送(如Pushover)和自动化运维工具（例如：Pagerduty、Opsgenie、Victorops）。Alertmanager的通知方式中还可以支持Webhook，通过这种方式开发者可以实现更多个性化的扩展支持。

集成邮件系统：与SMTP邮件集成

邮箱应该是目前企业最常用的告警通知方式，Alertmanager内置了对SMTP协议的支持，因此对于企业用户而言，只需要一些基本的配置即可实现通过邮件的通知。

在Alertmanager使用邮箱通知，用户只需要定义好SMTP相关的配置，并且在receiver中定义接收方的邮件地址即可。在Alertmanager中可以直接在配置文件的global中定义全局的SMTP配置：

global:
  [ smtp_from: <tmpl_string> ]
  [ smtp_smarthost: <string> ]
  [ smtp_hello: <string> | default = "localhost" ]
  [ smtp_auth_username: <string> ]
  [ smtp_auth_password: <secret> ]
  [ smtp_auth_identity: <string> ]
  [ smtp_auth_secret: <secret> ]
  [ smtp_require_tls: <bool> | default = true ]

完成全局SMTP之后，只需要为receiver配置email_configs用于定义一组接收告警的邮箱地址即可，如下所示：

name: <string>
email_configs:
  [ - <email_config>, ... ]

每个email_config中定义相应的接收人邮箱地址，邮件通知模板等信息即可，当然如果当前接收人需要单独的SMTP配置，那直接在email_config中覆盖即可：

[ send_resolved: <boolean> | default = false ]
to: <tmpl_string>
[ html: <tmpl_string> | default = '{{ template "email.default.html" . }}' ]
[ headers: { <string>: <tmpl_string>, ... } ]

如果当前收件人需要接受告警恢复的通知的话，在email_config中定义send_resolved为true即可。

如果所有的邮件配置使用了相同的SMTP配置，则可以直接定义全局的SMTP配置。

这里，以126邮箱为例，定义了一个全局的SMTP配置，并且通过route将所有告警信息发送到default-receiver中:

global:
  resolve_timeout: 5m
  smtp_smarthost: smtp.126.com:25
  smtp_from: rocket_2014@126.com
  smtp_auth_username: rocket_2014@126.com
  smtp_auth_identity: rocket_2014@126.com
  smtp_auth_password: ******邮箱登录密码********

receivers:
  - name: 'web.hook'
    webhook_configs:
      - url: 'http://127.0.0.1:5001/'
  - name: 'default-receiver'
    email_configs:
      - to: 'rocket_2014@126.com'
        send_resolved: true

这时如果手动拉高主机CPU使用率，使得监控样本数据满足告警触发条件。在SMTP配置正确的情况下，可以接收到如下的告警内容：

邮件告警

与Slack集成

Slack是非常流行的团队沟通应用，提供群组聊天和直接消息发送功能，支持移动端，Web 和桌面平台。在国外有大量的IT团队使用Slack作为团队协作平台。同时其提供了强大的集成能力，在Slack的基础上也衍生出了大量的ChatOps相关的技术实践。这部分将介绍如何将Slack集成到Alertmanager中。

Slack作为一款即时通讯工具，协作沟通主要通过Channel（平台）来完成，用户可以在企业中根据用途添加多个Channel，并且通过Channel来集成各种第三方工具。例如，可以为监控建立一个单独的Channel用于接收各种监控信息。

使用Webhook扩展Alertmanager：集成钉钉

在某些情况下除了Alertmanager已经内置的集中告警通知方式以外，对于不同的用户和组织而言还需要一些自定义的告知方式支持。通过Alertmanager提供的webhook支持可以轻松实现这一类的扩展。除了用于支持额外的通知方式，webhook还可以与其他第三方系统集成实现运维自动化，或者弹性伸缩等。

在Alertmanager中可以使用如下配置定义基于webhook的告警接收器receiver。一个receiver可以对应一组webhook配置。

每一项webhook_config的具体配置格式如下：

# Whether or not to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The endpoint to send HTTP POST requests to.
url: <string>

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

send_resolved用于指定是否在告警消除时发送回执消息。url则是用于接收webhook请求的地址。

http_configs则是在需要对请求进行SSL配置时使用。

当用户定义webhook用于接收告警信息后，当告警被触发时，Alertmanager会按照以下格式向这些url地址发送HTTP Post请求，请求内容如下：

{
  "version": "4",
  "groupKey": <string>,    // key identifying the group of alerts (e.g. to deduplicate)
  "status": "<resolved|firing>",
  "receiver": <string>,
  "groupLabels": <object>,
  "commonLabels": <object>,
  "commonAnnotations": <object>,
  "externalURL": <string>,  // backlink to the Alertmanager.
  "alerts": [
    {
      "labels": <object>,
      "annotations": <object>,
      "startsAt": "<rfc3339>",
      "endsAt": "<rfc3339>"
    }
  ]
}

Webhook初始配置详情

## 1.Alertmanager 配置文件
   global:
     resolve_timeout: 5m
     
  ## 2.route:路由分组
   route:
   #(1)用于分组聚合，对告警通知按标签(label)进行分组，将具有相同标签或相同告警名称(alertname)的告警通知聚合在一个组，然后作为一个通知发送。
   #   如果想完全禁用聚合，可以设置为group_by: [...]
     group_by: ['alertname']  #报警分组
    #(2)当一个新的告警组被创建时，需要等待'10s'后才发送初始通知。
    #    这样可以确保在发送等待前能聚合更多具有相同标签的告警，最后合并为一个通知发送。
     group_wait: 10s 
    #(3)当第一次告警通知发出后，在新的评估周期(interval:间隔)内又收到了该分组最新的告警
    #    则需等待'10s'时间后，开始发送为该组触发的新告警，可以简单理解为，group就相当于一个通道(channel)。
     group_interval: 10s
    #(4)告警通知成功发送后，若问题一直未恢复，需再次重复发送的间隔。
     repeat_interval: 1h
    #(5)配置告警消息接收者，与下面配置的对应。例如常用的 email、wechat、slack、webhook 等消息通知方式。
    #   Webhook:比如你的好友发了一条朋友圈，后端将这条消息推送给所有其他好友的客户端，就是 Webhook 的典型场景。    
     receiver: 'web.hook'
    #(6)这里还可以加入子路由
      -routes:  
       receiver: 'wechat'
       match:  # 通过标签去匹配这次告警是否符合这个路由节点；也可以使用  match_re 进行正则匹配
       severity: Disaster  # 标签severity为Disaster时满足条件，使用wechat警报

 ##3.配置报警信息接收者信息。
  receivers:
  #(1)警报接收者名称
  - name: 'web.hook'
    webhook_configs:
  # (2)webhook的路径
    - url: 'http://127.0.0.1:5001/'
  # (3)抑制规则配置，当存在与另一组匹配的警报（源）时，抑制规则将禁用与一组匹配的警报（目标）。
  inhibit_rules:
    - source_match:
        severity: 'critical'
      target_match:
        severity: 'warning'
      equal: ['alertname', 'dev', 'instance']

Alertmanger对消息头有特殊要求的，如果直接用webhook的话，需要安装一个插件封装下，才可以调用。

Alertmanager接入其他系统日志

可以通过API接口将其他系统的告警日志对接到Alertmanager中，示例如下：

curl -H "Content-Type: application/json" -X POST -d '[{
    "labels": {   # 自定义标签项
        "alertname": "CPU负载过高",     //自定义告警名称主题
        "instance": "127.0.0.1",  //实例名称，可以改为具体服务名
        "job": "无",   
        "severity": "1",    //严重等级
    },
    "annotations": {
        "summary": "短信账号全部欠费了，无法切换可用服务，发不出短信"   //告警详细信息
    },
    "startsAt": "2023-02-25T07:54:52.898371829Z",   //开始时间
    "endsAt": "2023-02-25T12:58:52.898371829Z"       //结束时间，这个参数很重要
}]'  http://127.0.0.1:9093/api/alerts

Alertmanager启动参数详解

--config.file="alertmanager.yml" 指定Alertmanager配置文件路径
--data.retention=120h 历史数据保留时间，默认为120h
--alerts.gc-interval=30m 警报gc之间的间隔
--web.external-url=WEB.EXTERNAL-URL 外部可访问的Alertmanager的URL(例如Alertmanager是通过nginx反向代理)
--web.route-prefix=WEB.ROUTE-PREFIX web访问内部路由路径，默认是 --web.external-url
--web.listen-address=":9093" 监听端口，可以随意修改
--web.get-concurrency=0 并发处理的最大GET请求数，默认为0
--web.timeout=0 web请求超时时间
--cluster.listen-address="0.0.0.0:9094" 集群的监听端口地址。设置为空字符串禁用HA模式
--cluster.advertise-address=CLUSTER.ADVERTISE-ADDRESS 配置集群通知地址
--cluster.gossip-interval=200ms 发送条消息之间的间隔，可以以增加带宽为代价更快地跨集群传播。
--cluster.peer-timeout=15s 在同级之间等待发送通知的时间
--log.level=info 自定义消息格式 [debug, info, warn, error]
--log.format=logfmt 日志消息的输出格式: [logfmt, json]
--version 显示版本号

更多资料 · 微信公众号搜索【CTO Plus】关注后，获取更多，我们一起学习交流。

关于公众号的描述访问如下链接

关于Articulate“做一个知识和技术的搬运工。做一个终身学习的爱好者。做一个有深度和广度的技术圈。”一直以来都想把专业领域的技https://mp.weixin.qq.com/s/0yqGBPbOI6QxHqK17WxU8Q

SteveRocket

关注

1
点赞
踩
8

收藏

觉得还不错? 一键收藏
打赏
0
评论
三、 Prometheus：告警规则集、告警接收器、Alertmanager启动参数详解（2）

Awesome Prometheus alerts维护了一套开箱即用的 Prometheus 告警规则集合，有好几百告警规则。这些规则，对每个 Prometheus 都是通用的。涉及如主机、硬件、容器等基础资源，到数据库、消息代理、运行时、反向代理、负责均衡器，运行时、服务编排，甚至是网络层面和 Prometheus 自身和集群。
复制链接

扫一扫