alertmanager告警规则静默（alertmanager silence静默）

本篇文章给大家谈谈alertmanager告警规则静默，以及alertmanager silence静默对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享alertmanager告警规则静默的知识，其中也会对alertmanager silence静默进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、65. 通过alertmanager接口添加静默规则
• 2、DevOps之prometheus实现优雅的告警
• 3、alertmanager-配置文件
• 4、Prometheus告警收敛
• 5、Prometheus配置alertmanager告警邮件通知

65. 通过alertmanager接口添加静默规则

[ww@prometheus001 scripts]$ cat daikuan_silences.py

#! /usr/bin/env python

# -*- coding:utf8 -*-

import datetime

import urllib.request

import urllib.parse

import requests

import json

import time

def add(matchers, username, commit):

    UTC_FORMAT = "%Y-%m-%dT%H:%M:%S.%fZ"

    now_stamp = time.time()

    startsAt = datetime.datetime.utcfromtimestamp(now_stamp)

    endsAt = startsAt + datetime.timedelta(hours=8)

    print(startsAt,endsAt)

    data = {

        "matchers": matchers,

        "startsAt": startsAt.strftime(UTC_FORMAT),

        "endsAt": endsAt.strftime(UTC_FORMAT),

        "createdBy": username,

        "comment": commit,

        #"id": "",

        #"status": {"state": "active"}

    }

    print(json.dumps(data))

    headers={'content-type': 'application/json'}

    burl="http://localhost:9093/api/v2/silences"

    r=requests.post(burl, data=json.dumps(data), headers=headers)

    print(r.text)
matchers = [{'isRegex': False, 'name': 'application', 'value': '共享带宽'},{'isRegex': False, 'name': 'hostname', 'value': 'daikuan001'}]

add(matchers, "tom", "temp")

DevOps之prometheus实现优雅的告警

目前prometheus的告警，常用的有grafana自带的告警和prometheus插件alertmanger的告警两种，这里测试下alertmanger的告警功能。

综合考虑，配合上prometheus operator，使用alertmanger，能够使监控告警这块的工作更加devops。

prometheus operator 在k8s中引入了自定义资源定义（CRSs）Prometheus、ServiceMonitor、PrometheusRule和Alertmanager。

所以在k8s中搭建好prometheus operator后，当我们需要监控一个项目时，我们的配置顺序是配置ServiceMonitor获取监控数据，配置PrometheusRule获取告警阈值，配置Alertmanager制定告警发送方式

如果我们已经完成了ServerMonitor的对象的编写，下面就要将监控好的重要数据，设置阈值，触发告警。

这里用spark 服务cpu使用率为例，介绍下PrometheusRule的写法

这样我们就完成一个PrometheusRule 资源对象的编写了，那么prometheus是怎么识别这个告警规则的呢。

我们先查看下prometheus的资源对象

kubectl get prometheus/k8s -n monitoring -o yaml

可以看到，prometheus会自动匹配标签为prometheus=k8s 和 role=alert-rules的prometheusRule的资源对象，这里我们可以体会到prometheus operator自动发现的魅力，我们只需要编写相应的告警规则yaml文件，然后apply一下，便可以制定告警。

在prometheus界面上面查看刚刚制定的告警规则

对于告警通知，需要考虑以下几点

及时性：邮件通知有时候不会注意，尤其是不在电脑面前，所以这里我们选择工作中使用的企业微信作为告警消息推送方式
简洁性：如果服务器性能等到达了一个warning值，会有很多相关的告警全部触发，所以这里我们需要配置分组、静默、抑制方案
容灾性：如果alermanger或者prometheus本身挂掉了，发不出告警怎么办，一般会采用另一个监控来监控prometheus，或者自定义一个持续不断的告警通知，哪一天这个告警通知不发了，说明监控出现问题了。很棒的一点是，prometheus operator已经考虑了这一点，本身携带一个watchdog，作为对自身的监控

创建一个alertmanger配置文件

删除之前的secret对象，并且创建新的

查看企业微信，这个时候会发现已经收到告警信息

这个watchdog便是对prometheus自身的监控。如果有需要，可以制定一条路由，匹配severity为none的告警，然后每24h重复一次，这样可以达到每天监控prometheus本身的效果，哪一天没收到watchdog，便可以知道prometheus挂了。

正常收到的告警信息

alertmanger也支持webhook告警，但是比如钉钉和企业微信机器人这类对消息头有特殊要求的，如果直接用webhook的话，需要安装一个插件封装下，才可以调用

Alertmanager还支持临时静默告警。有时候我们在处理告警，想要临时静默告警消息，或者测试环境中，进行压测，需要临时静默一段时间的告警，我们就可以直接通过Alertmanager的UI临时屏蔽特定的告警通知。通过定义标签的匹配规则(字符串或者正则表达式)，如果新的告警通知满足静默规则的设置，则停止向receiver发送通知
目前Alertmanager只支持在UI上面进行临时静默告警

当静默规则生效以后，从Alertmanager的Alerts页面下用户将不会看到该规则匹配到的告警信息，微信机器人也不会发送响应的告警消息

alertmanager-配置文件

alertmanager启动时，通过参数--config.file指定alertmanager要加载的配置文件

alertmanager启动时，常用的启动参数配置

--config.file：alertmanager要加载的配置文件，是一个yaml格式的配置文件

--web.lister-address：监听Web接口和API的地址端口

--web.external-url：用于返回alertmanager的相对和绝对链接地址，可以在后续告警中直接点击链接地址访问Alertmanager Web UI

--data.retention：历史数据最大保留时间，默认为120h

--storage.path：数据存储路径

配置文件格式

alertmanager的配置主要分为5个部分，分别是全局配置(global)、告警路由(route)、抑制规则(inhibit_rules)、接收者(receivers)、模板（templates）

1）全局配置(global)：用于定义一些全局的公共参数，如全局的SMTP配置、Slack配置等

2）告警路由（route）:根据标签匹配，确定当前告警应该如何处理

3）抑制规则（inhibit_rules）:合理设置抑制规则可以减少垃圾告警的产生

4）接收者（receivers）：接收者是一个抽象的概念，它可以是一个邮箱，也可以是微信或者Webhook等。接收者一般配置告警路由使用

5）模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板等

global:

   #可以配置alertmanager通知的目的地，比如可以配置邮件发送信息
#每个告警信息进入的根路由，用于设置告警的分发策略

route:

  #根路由不能有任何匹配器，因为它是所有告警的入口点。它需要配置一个接收器（也即receiver），以便不匹配任何子路由的告警发送出去。

  receiver: 'xxx' #告警的接收人，支持邮箱、webhook
  #将告警进行分组，避免海量告警，group_by这里指定的标签key对应的标签值相同的告警会被分到同一个组中，并且在发送告警时，聚合到一条告警中

  group_by: ['xxx']
  #当一个新的告警组被创建时，需要等待<duration的时长，然后将告警组中的告警发送出去

  group_wait: <duration
  #已经存在的告警组上一次发送告警时间是T，如果在最近一段时间内（即：<duration）alertmanager有接收到新的告警，则在T+<duration将告警组中的告警发送出去，如果T+<duration时间点没有数据，在T+<duration+<0.1duration时间点有新的告警，那么告警会立即发出，并且下一次检测发送的时间点是T+<duration+<0.1duration+<duration

  group_interval: <duration
  #已经存在的告警组上一次发送告警时间是T，如果在T ~ T+<duration时间段内告警组内都没有接收到新的告警，就在T+<duration时间点重新发送上一次发送的告警通知

  repeat_interval: <duration
  #上述属性是根路由的属性，由所有子路由继承，并且可以覆盖到每个子路由

  routes:

   #此路由对告警标签执行正则表达式匹配，以捕获与服务列表相关的告警

  - match_re:

     <label_key: <regex
   #此子路由捕获到告警时，需要通知的对象

   receiver: xxx
#抑制规则，如果发出的告警是由已发出的告警导致的，则匹配到的告警都不会被发送出去

inhibit_rules:

  #已经发出的告警的标签

- source_match:

   <label_key: <label_value

  #如果还没发出的告警满足这里的标签，并且满足source_match中标签的告警已经发出，那么target_match匹配的告警不会被发送出去

  target_match:

   <label_key1: <label_value1
#告警接收者

receivers:

- name:告警接收人名称

  <具体发送告警的目的地，支持email、webhook等
#template块保存告警模板的目录列表

templates:

  [- <filepath]

Prometheus告警收敛

什么是告警收敛？
在对节点或服务的日常监控中，收到的警报太多，如一下就几十封，或者很多不必要的邮件发来，容易导致人很麻木，这样时间久了，遇到比较严重的警报，我们也会放松警惕性。面对这种情况，alertmanager收敛可很好解决这个问题，就是当Prometheus成功的把一条告警发给了Alertmanager，而Alertmanager并不是简简单单的直接发送出去，而是合理做一些控制，这样就不会导致告警信息过多，重要告警被淹没。

打开alertmanager

创建静默

Prometheus配置alertmanager告警邮件通知

位置alertmanager告警规则静默： /etc/prometheus/prometheus.yml
修改以下内容alertmanager告警规则静默，targets填入alertmanageralertmanager告警规则静默的ip和端口

位置： /etc/alertmanager/alertmanager.yml
注意：这里用的是163的邮箱测试的alertmanager告警规则静默，开启tls加密一直没调通，不开tls可以，不开tls的smtp端口是25

位置： /etc/alertmanager/templates/email.tmpl

关于alertmanager告警规则静默和alertmanager silence静默的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 alertmanager告警规则静默的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于alertmanager silence静默、alertmanager告警规则静默的信息别忘了在本站进行查找喔。