Prometheus规则和Alertmanager报警

 2018年3月31日 17:06   Nick王   运维  自动化    1 评论   1423 浏览 

AA

Prometheus规则的配置

Prometheus支持两种类型的规则配置,然后定期进行评估。

这两种规则是: recording 规则和 alerting 规则。

在Prometheus的配置文件中通过rule_files加载包含详细规则声明的文件。规则文件的格式是YAML

检查规则文件的语法

想要快速的检查规则文件的语法是否有问题,可以使用promtool工具:

go get github.com/prometheus/prometheus/cmd/promtool
promtool check rules /path/to/example.rules.yml

Recording 规则

Recording规则允许你 预先计算一些常用的表达式 或者 是计算非常昂贵的表达式,并且保存他们的结果在一个新的时间序列。在每次需要的时候查询预先计算好的结果 比 执行原始表达式 要快很多。这对于Dashboard是非常有用的,当每次刷新的时候都需要反复的查询相同的表达式。

Recording 和 Alerting 规则存在于规则组中。组中的规则在正常的时间间隔内按照顺序运行。

配置文件:

groups:
  - name: example  # 组名称, 在同一个文件中必须唯一
    rules:
    - record: job:requests:sum   # 要输出到的 时间序列的名称。 必须是一个有效的 metric 名称
      expr: sum(http_requests_total) by (job)  # 要评估的表达式
      labels:   # 要添加或者覆盖的标签
        [ service: bar ]

Alerting 规则

Alerting 规则允许基于Prometheus的表达式定义一组报警条件,并且发送通知到外部的服务。

groups:
  - name: example
    rules:
    - record: job:requests:sum
      expr: sum(http_requests_total) by (job)
  - name: node_exporter
    rules:
    - alert: NodeExporterDown
      expr: up == 0
      for: 60s  # 在发出报警之前, 持续的时间, 在该时间段内会继续评估
      labels:  # 附加标签, 重复会覆盖, 值可以使用模板
        severity: page
        currentvalue: $value  # $value 存储的是当前的值
        itemname: $labels.expr
      annotations:
        summary: "Instance {{ $labels.instance }} down"  # $labels存储的是当前实例的信息
        description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

Prometheus报警配置

官网链接: https://prometheus.io/docs/alerting/overview/

Prometheus中的报警分为两部分。

Prometheus服务中的报警规则会向Alertmanager发送报警。

Alertmanager会管理这些报警,包含降噪(silencing),抑制(inhibition),聚合(aggregation)并且通过指定的方法来发送通知,比如email,PagerDuty和HipChat。

设置报警和通知的主要步骤如下:

  • 配置Alertmanager

  • 配置Prometheus连接Alertmanager

  • 在Prometheus中创建报警规则

Alertmanager一些概念

Alertmanager会处理客户端(比如Prometheus服务)发送的报警。它负责,去重、分组并且路由这些报警到正确的接收器,比如email,PagerDuty等。它还处理报警的降噪和抑制。

Grouping(分组)

分组会将类似性质的报警归类为一个单一的通知。这在一次性宕机很多系统并且产生大量的报警的时候非常的有用。

比如,在你的集群中有数百个服务器实例正在运行,当网络发生故障的时候,有可能服务实例的一大半都连不到数据。那么此时Prometheus服务中的报警规则会为该服务实例发送报警给ALertmanager。最后的结果可能就是有数百个报警发送给Alertmanager。

作为用户你可能只想要看到一个页面,就能够清楚的知道哪些服务实例受到了影响。而不是数百个垃圾通知。因此,Alertmanager可以通过他们的集群或者是报警名称来进行分组,最后发送一个压缩的通知。

可以在Alertmanager配置文件中的路由树中配置报警分组,分组通知时间线和接收这些通知的接收器。

Inhibition(抑制)

抑制是指当警报发出后,将抑制其他相关警报的发送。

例如,当警报被触发,通知整个集群不可达,可以配置Alertmanager忽略由该警报触发而产生的所有其他警报,这可以防止通知数百或数千与此问题不相关的其他警报。

抑制机制可以通过Alertmanager的配置文件来配置。

Silences(降噪)

降噪是简单地在给定时间内静音报警的方法。就像路由树一样,降噪配置也是基于matcher。传入的警报会使用所有被激活的silences进行相等或者正则表达式的匹配,如果匹配,将不会为此警报发送通知。

降噪机制可以通过Alertmanager的Web页面进行配置。

客户端行为

Alertmanager对客户端的行为有特殊的需求。

高可用

Alertmanager支持高可用的集群构建。


Alertmanager配置

Alertmanager通过命令行参数和一个配置文件进行配置。命令行参数配置不变的系统参数,而配置文件定义的是抑制(inhibition)规则、通知路由和通知接收器。

要查看所有可用的命令行参数,运行alertmanager -h

Alertmanager可以在运行的时候重新加载配置。如果新的配置格式不正确,将不会应用更改,并且会记录错误。可以给进程发送SIGHUP的信号,也可以使用URL/-/reload来重新读取配置文件。

配置文件举例:

global:
  # SMTP的相关配置
  smtp_smarthost: 'localhost:25'
  smtp_from: 'alertmanager@example.org'
  smtp_auth_username: 'alertmanager'
  smtp_auth_password: 'password'
  # 每5分钟检查一次是否恢复
  resolve_timeout: 5m

# 自定义 通知的模板的 目录 或者 文件.
templates:
- '/etc/alertmanager/template/*.tmpl'

# 路由树的根节点, 每个传进来的报警从这里开始.
route:
  # 将传入的报警中有这些标签的分为一个组.
  # 比如, cluster=A 和 alertname=LatencyHigh 会分成一个组.
  group_by: ['alertname', 'cluster', 'service']

  # 指分组创建多久后才可以发送压缩的警报,也就是初次发警报的延时.
  # 这样会确保第一次通知的时候, 有更多的报警被压缩在一起.
  group_wait: 30s

  # 当第一个通知发送,等待多久发送压缩的警报
  group_interval: 5m

  # 如果报警发送成功, 等待多久重新发送一次
  repeat_interval: 3h

  # 默认的接收器
  receiver: team-X-mails

  # 所有以上的属性都可以被子路由继承, 而子路由也可以重写它们.

  # 子路由树.
  routes:
  # 此路由会在alert标签上执行正则表达式匹配, 以捕获相关的报警.
  - match_re:
      service: ^(foo1|foo2|baz)$
    receiver: team-X-mails
    # 下面是一个危险报警的子路由. 比如. severity != critical, 会使用父节点的 team-X-mails
    routes:
    - match:
        severity: critical
      receiver: team-X-pager

  - match:
      service: files
    receiver: team-Y-mails
    routes:
    - match:
        severity: critical
      receiver: team-Y-pager

  # 此路由用来处理来自数据库的所有报警. 如果没有team来处理, 则默认为DB team.
  - match:
      service: database
    receiver: team-DB-pager
    # 受影响的数据库的组报警.
    group_by: [alertname, cluster, database]
    routes:
    - match:
        owner: team-X
      receiver: team-X-pager
    - match:
        owner: team-Y
      receiver: team-Y-pager


# 抑制规则允许在一个报警发出的时候设置一组报警静音.
# 如果已经发出的报警是危险(cirtical), 那么就让其他报警静音.
inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  # 如果alertname相同, 应用抑制机制.
  equal: ['alertname', 'cluster', 'service']


# 通知接收器列表
receivers:
- name: 'team-X-mails'
  email_configs:
  - to: 'team-X+alerts@example.org'

- name: 'team-X-pager'
  email_configs:
  - to: 'team-X+alerts-critical@example.org'
  pagerduty_configs:
  - service_key: <team-X-key>

- name: 'team-Y-mails'
  email_configs:
  - to: 'team-Y+alerts@example.org'

- name: 'team-Y-pager'
  pagerduty_configs:
  - service_key: <team-Y-key>

- name: 'team-DB-pager'
  pagerduty_configs:
  - service_key: <team-DB-key>

- name: 'team-X-hipchat'
  hipchat_configs:
  - auth_token: <auth_token>
    room_id: 85
    message_format: html
    notify: true

route

一个路由块,定义一个路由节点和他的子路由。

所有的报警最开始都会进入路由树的顶级节点,所以这个节点不能配置match。然后才会遍历子路由。如果报警与节点的任何子节点不匹配,则根据当前节点的配置参数处理报警。

配置文件案例:

# 根路由, 包含所有的参数, 如果不覆盖, 子路由将继承这些参数.
route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
  # 与下列子路由不匹配的所有报警将会保持在根路由, 并且会发送到 'default-receiver' 接收器.
  routes:
  # 所有关于 service: mysql 或者 service: cassandra 的报警 会发给 database-pager.
  - receiver: 'database-pager'
    group_wait: 10s
    match_re:
      service: mysql|cassandra
  # 所有 带有标签 frontend-pager 的报警 会匹配到这个子路由.
  # 这里使用 product 和 environment 来分组 而不是使用 cluster 和 alertname.
  - receiver: 'frontend-pager'
    group_by: [product, environment]
    match:
      team: frontend

inhibit_rule

配置文件案例:

# Matchers that have to be fulfilled in the alerts to be muted.
target_match:
  [ <labelname>: <labelvalue>, ... ]
target_match_re:
  [ <labelname>: <regex>, ... ]

# Matchers for which one or more alerts have to exist for the
# inhibition to take effect.
source_match:
  [ <labelname>: <labelvalue>, ... ]
source_match_re:
  [ <labelname>: <regex>, ... ]

# Labels that must have an equal value in the source and target
# alert for the inhibition to take effect.
[ equal: '[' <labelname>, ... ']' ]

receiver

建议使用webhook自定义通知。

# 接收器的唯一名称.
name: <string>

# 配置一些通知集成.
email_configs:
  [ - <email_config>, ... ]
opsgenie_configs:
  [ - <opsgenie_config>, ... ]
webhook_configs:
  [ - <webhook_config>, ... ]
victorops_configs:
  [ - <victorops_config>, ... ]

webhook_config

配置文件:

# 是否启用恢复报警.
[ 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 ]

Alertmanager将会发送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>"
    },
    ...
  ]
}

Prometheus配置连接Alertmanager

在Prometheus配置文件中, 配置如下内容:

alerting:
  alertmanagers:
    - timeout:    10s
    - static_configs:
      - targets:
        - 'localhost:9093'

Prometheus中报警规则配置

在Prometheus配置文件中, 配置如下内容:

rule_files:
  - 'prometheus.rules.yml'

注意: 这里可以写多个文件, 也可以写通配符。

规则文件内容如下:

groups:
  - name: node_exporter
    rules:
    - alert: NodeExporterDown
      expr: up == 0
      for: 30s
      labels:
        severity: page
      annotations:
        summary: "Instance {{ $labels.instance }} down"
        description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."



如无特殊说明,文章均为本站原创,转载请注明出处