Alertmanager部署和简单使用

Alertmanager部署和简单使用

部署

解压

[root@server01 src]# wget https://github.com/prometheus/alertmanager/releases/download/v0.15.0/alertmanager-0.15.0.linux-amd64.tar.gz
[root@server01 src]# tar -xvf alertmanager-0.15.0.linux-amd64.tar.gz -C /opt/
[root@server01 src]# cd /opt/
[root@server01 opt]# ln -s alertmanager-0.15.0.linux-amd64 alertmanager

 配置

[root@server01 alertmanager]# cat alertmanager.yml 
global:
      # 在没有报警的情况下声明为已解决的时间
  resolve_timeout: 5m
      # 配置邮件发送信息
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: '15737684975@163.com'
  smtp_auth_username: '15737684975@163.com'
  smtp_auth_password: 'wsl116002'
  smtp_require_tls: false  # 禁用tls
# 所有报警信息进入后的根路由，用来设置报警的分发策略
route:
  # 这里的标签列表是接收到报警信息后的重新分组标签，例如，接收到的报警信息里面有许多具有 cluster=A 和 alertname=LatncyHigh 这样的标签的报警信息将会批量被聚合到一个分组里面
  group_by: ['alertname', 'cluster']  
  # 当一个新的报警分组被创建后，需要等待至少group_wait时间来初始化通知，这种方式可以确保您能有足够的时间为同一分组来获取多个警报，然后一起触发这个报警信息。
  group_wait: 30s

  # 当第一个报警发送后，等待'group_interval'时间来发送新的一组报警信息。
  group_interval: 5m

  # 如果一个报警信息已经发送成功了，等待'repeat_interval'时间来重新发送他们
  repeat_interval: 5m

  # 默认的receiver：如果一个报警没有被一个route匹配，则发送给默认的接收器
  receiver: default

receivers:
- name: 'default'  # 自定义名称 供receiver: default使用
  email_configs:   # 邮件报警模块
  - to: 'wangshile@datang.com'
    send_resolved: true

创建启动文件并启动

[root@server02 opt]# vi /usr/lib/systemd/system/alertmanager.service
[Unit]
Description=alertmanager
Documentation=https://prometheus.io/
After=network.target
 
[Service]
Type=simple
User=prometheus
ExecStart=/opt/alertmanager/alertmanager  --config.file=/opt/alertmanager/alertmanager.yml
Restart=on-failure
 
[Install]
WantedBy=multi-user.target

[root@server01 alertmanager]# chown -R prometheus.prometheus /usr/lib/systemd/system/alertmanager.service
[root@server01 alertmanager]# systemctl start alertmanager

 Prometheus配置Alertmanager

添加报警规则

[root@server01 prometheus]# vi rules/node_alerts.yml
groups:
- name: node_alerts   # 组名称
  rules:
  - alert: HighNodeCPU  # 规则名称必须唯一
    expr: instance:node_cpu:avg_rate5m > 80  # 该指标是否大于80，改表达式在自定义规则文件中
    for: 60m   # 需要在触发警报之前的60分钟内大于80％，限制了警报误报或是暂时状 态的可能性
    labels:
      severity: warning
    annotations:
      summary: High Node CPU of {{ humanize $value}}% for 1 hour   # 警报的描述

prometheus配置

[root@server01 alertmanager]# vi /opt/prometheus/prometheus.yml 
global:
  scrape_interval:     15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - alertmanager:9093

rule_files:
  - "rules/*_rules.yml"
  - "rules/*_alerts.yml"

scrape_configs:
- job_name: 'prometheus'
  static_configs:
    - targets: ['localhost:9090']

- job_name: 'alertmanager'
  static_configs:
    - targets: ['localhost:9093']
	
# 基于文件的服务发现
- job_name: node
  file_sd_configs:
    - files:
      - targets/nodes/*.json
      refresh_interval: 5m

- job_name: docker
  file_sd_configs:
    - files:
      - targets/docker/*.json
      refresh_interval: 5m
  metric_relabel_configs:
  - source_labels: [id]
    regex: '/docker/([a-z0-9]+)'
    replacement: '$1'
    target_label: container_id
  - source_labels: [__name__]
    separator: ','
    regex: '(container_tasks_state|container_memory_failures_total)'
    action: drop

添加基于文件的服务发现

[root@server01 ~]# mkdir /opt/prometheus/targets/{nodes,docker} -p
[root@server01 ~]# vi /opt/prometheus/targets/nodes/nodes.json
[{
	"targets": ["10.4.7.11:9100"]
}]

[root@server01 ~]# vi  /opt/prometheus/targets/docker/daemons.json

[{
	"targets": ["10.4.7.11:8080"]
}]

[root@server01 prometheus]# kill -HUP 15916

添加之后可以在页面上看到。

警报触发

警报可能有以下三种状态：

• Inactive：警报未激活。
• Pending：警报已满足测试表达式条件，但仍在等待for子句中指定的持续时间。
• Firing：警报已满足测试表达式条件，并且Pending的时间已超过for子句的持续时间。

 Pending到Firing的转换可以确保警报更有效，且不会来回浮动。没有for子句的警报会自动从Inactive转换为Firing，只需要一个评估周期即可触发。带有for子句的警报将首先转换为Pending，然后转换为Firing，因此至少需要两个评估周期才能触发。

警报触发过程

1. 节点的CPU不断变化，每隔一段由scrape_interval定义的时间被Prometheus抓取一次，对我们来说 是15秒
2. 根据每个evaluation_interval的指标来评估警报规则，对我们来说还是15秒
3. 当警报表达式为true时（对于我们来说是CPU超过80％），会创建一个警报并转换到Pending状 态，执行for子句
4. 在下一个评估周期中，如果警报测试表达式仍然为true，则检查for的持续时间。如果超过了持续 时间，则警报将转换为Firing，生成通知并将其推送到Alertmanager
5. 如果警报测试表达式不再为true，则Prometheus会将警报规则的状态从Pending更改为Inactive

添加新警报和模板

[root@server01 rules]# vi node_rules.yml

- alert: DiskWillFillIn4Hours
    expr: predict_linear(node_filesystem_free_bytes{mountpoint="/"}[1h], 4*3600) < 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: Device {{$labels.device}} on node {{$labels.instance}} is running
              full within the next 4 hours (mounted at {{ $labels.mountpoint }})
  - alert: InstanceDown
    expr: up{job="node"} == 0  # 服务停止则报警
    for: 10s
    labels:
      severity: critical
    annotations:
      summary: Host {{ $labels.instance }} is down!

 模板

模板使用标准的Go模板语法，并暴露一些包含时间序列的标签和值的变量。标签以变量$labels形式表示，指标的值则是变量$value。
要在summary注解中引用instance标签，我们使用{{$labels.instance}}。如果想要引用时间序列的 值，那么我们会使用{{$value}}。

    annotations:
      summary: High Node CPU of {{ humanize $value}}% for 1 hour

 这会将指标值显示为两位小数的百分比，例如88.23%。

 Prometheus警报

在这里，我们添加了两个新规则。第一个是PrometheusConfigReloadFailed，它让我们知道 Prometheus配置重新加载是否失败。如果上次重新加载失败，则使用指标 prometheus_config_last_reload_successful，且指标的值为0

[root@server01 rules]# vi prometheus_alerts.yml 
groups:
- name: prometheus_alerts
  rules:
  - alert: PrometheusConfigReloadFailed
    expr: prometheus_config_last_reload_successful == 0  # prometheus是否加载成功
    for: 10m
    labels:
      severity: warning
    annotations:
      description: Reloading Prometheus' configuration has failed on {{ $labels.instance }}.
  - alert: PrometheusNotConnectedToAlertmanagers
    expr: prometheus_notifications_alertmanagers_discovered < 1  # prometheus是否连接alertmanager
    for: 10m
    labels:
      severity: warning
    annotations:
      description: Prometheus {{ $labels.instance }} is not connected to any Alertmanagers

在这里，我们添加了两个新规则。第一个是PrometheusConfigReloadFailed，它让我们知道 Prometheus配置重新加载是否失败。如果上次重新加载失败，则使用指标 prometheus_config_last_reload_successful，且指标的值为0

可用性警报

最后的警报可以帮助我们确定主机和服务的能力。第一个警报利用了我们使用Node Exporter收集 的systemd指标。如果我们在节点上监控的服务不再活动，则会生成一个警报。

  - alert: NodeServiceDown
    expr: node_systemd_unit_state{state="active"} != 1
    for: 60s
    labels:
      severity: critical
    annotations:
      summary: Service {{ $labels.name }} on {{ $labels.instance }} is no longer active!
      description: Werner Heisenberg says - "OMG Where's my service?"

 如果带有active标签的node_systemd_unit_state指标值为0，则会触发此警报，表示服务故障至少60秒，Prometheus有一个功能叫absent，可检测是否存在缺失的指标

[root@server01 rules]# kill -HUP 25041

 路由

[root@server01 rules]# vi /opt/alertmanager/alertmanager.yml 

route:
  group_by: ['instance']  # 分组报警的方式，使用instance进行分组
  group_wait: 30s
  group_interval: 5m  # 发送第一次后第二次警报的等待时间
  repeat_interval: 3h # 重复告警发送间隔时间
  receiver: email
  routes:               # 路由表
  - match:
      severity: critical
    receiver: pager     # 接收器
    routes:
      - match:
          service: application1   # 将所有severity标签与application1值匹配，并将它们发送到pager接收器。
        receiver: support_team
  - match_re:
      severity: ^(informational|warning)$  # 正则表达式匹配：匹配severity标签中的informational或warning值
    receiver: support_team
receivers:
- name: 'email'
  email_configs:
  - to: 'alerts@example.com'
- name: 'support_team'
  email_configs:
  - to: 'support@example.com'
- name: 'pager'
  email_configs:
  - to: 'alert-pager@example.com'
  slack_configs:
  - api_url: https://hooks.slack.com/services/ABC123/ABC123/EXAMPLE
    text: '{{ .CommonAnnotations.summary }}'

 路由分支

routes:
- match:
    service: application1   # 将所有severity标签与application1值匹配，并将它们发送到pager接收器。
  receiver: pager
  routes:
    - match:
	    service: application1
  receiver: support_team	

 可以看到我们的新routes块嵌套在已有的route块中。要触发此路由，我们的警报首先需要severity 标签为critical，并且service标签是application1。如果这两个条件都匹配，那么我们的警报将被路由到接收器support_team。

silence和维护

 通常我们需要让警报系统知道我们已经停止服务以进行维护，并且不希望触发警报

可以使用以下两种方法来设置silence：