【prometheus】alertmanager 配置文件示例

global:
  # The smarthost and SMTP sender used for mail notifications.  用于邮件通知的智能主机和SMTP发件人。
  smtp_smarthost: 'localhost:25'
  smtp_from: 'alertmanager@example.org'
  smtp_auth_username: 'alertmanager'
  smtp_auth_password: 'password'
  # The auth token for Hipchat.    Hipchat的身份验证令牌。
  hipchat_auth_token: '1234556789'
  # Alternative host for Hipchat.
  hipchat_api_url: 'https://hipchat.foobar.org/'

# The directory from which notification templates are read.  从中读取通知模板的目录。
templates: 
- '/etc/alertmanager/template/*.tmpl'

# The root route on which each incoming alert enters.    每个传入警报进入的根路由
route:
  # The labels by which incoming alerts are grouped together. For example,
  # multiple alerts coming in for cluster=A and alertname=LatencyHigh would
  # be batched into a single group.
  #
  # To aggregate by all possible labels use '...' as the sole label name.
  # This effectively disables aggregation entirely, passing through all 
  # alerts as-is. This is unlikely to be what you want, unless you have
  # a very low alert volume or your upstream notification system performs
  # its own grouping. Example: group_by: [...]
  
  # 传入警报分组在一起的标签。例如，群集= A和 alertname = LatencyHigh的多个警报将会出现
 被分成一组。
  # 要按所有可能的标签聚合，请使用“...”作为唯一的标签名称。
  # 这有效地完全禁用了聚合，按原样传递所有警报。这不太可能是您想要的，除非您的警报音量非常低或您的上游通知系统执行
  group_by: ['alertname', 'cluster', 'service']

  # When a new group of alerts is created by an incoming alert, wait at least 'group_wait' to send the initial notification.
  # 当传入警报创建新的警报组时，至少等待'group_wait'发送初始通知。
  # This way ensures that you get multiple alerts for the same group that start firing shortly 
  # after another are batched together on the first  notification.
  # 这种方式可确保您为同一组获得多个警报，这些警报会在第一个通知上另一个批处理后立即开始触发
   group_wait: 30s

  # When the first notification was sent, wait 'group_interval' to send a batch
  # of new alerts that started firing for that group.
  # 发送第一个通知时，请等待'group_interval'发送一批为该组开始触发的新警报。
  group_interval: 5m

  # If an alert has successfully been sent, wait 'repeat_interval' to  resend them.
  # 如果已成功发送警报，请等待'repeat_interval'重新发送。
  repeat_interval: 3h 

  # A default receiver
  receiver: team-X-mails

  # All the above attributes are inherited by all child routes and can overwritten on each.
  #  所有上述属性都由所有子路由继承，并且可以在每个子路由上覆盖。
  
  # The child route trees.
  routes:
  # This routes performs a regular expression match on alert labels to catch alerts that are related to a list of services.
  # 此路由在警报标签上执行正则表达式匹配，以捕获与服务列表相关的警报。
  - match_re:
      service: ^(foo1|foo2|baz)$
    receiver: team-X-mails
    
  # The service has a sub-route for critical alerts, any alerts  that do not match, i.e. severity != critical, fall-back to the  parent node and are sent to '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

  # This route handles all alerts coming from a database service. If there's  no team to handle it, it defaults to the DB team.
  # 此路由处理来自数据库服务的所有警报。如果没有团队可以处理它，则默认为数据库团队。
  - match:
      service: database
    receiver: team-DB-pager
    # Also group alerts by affected database.
    group_by: [alertname, cluster, database]
    routes:
    - match:
        owner: team-X
      receiver: team-X-pager
      continue: true
    - match:
        owner: team-Y
      receiver: team-Y-pager


# Inhibition rules allow to mute a set of alerts given that another alert is firing.
# 抑制规则允许在另一个警报触发时静音一组警报。
# We use this to mute any warning-level notifications if the same alert is  already critical.
# 如果相同的警报已经很关键，我们使用它来静音任何警告级别的通知。
inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  # Apply inhibition if the alertname is the same.  如果警报名称相同，则应用禁止。
  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

原文链接：https://github.com/prometheus/alertmanager/blob/master/doc/examples/simple.yml

最后

以上就是坚定溪流为你收集整理的【prometheus】alertmanager 配置文件示例的全部内容，希望文章能够帮你解决【prometheus】alertmanager 配置文件示例所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。