本章节主要讲解Alertmanager高可用的搭建与配置的详细的知识内容。

为了提升Prometheus的服务可靠性,我们会部署两个或多个的Prometheus服务,两个Prometheus具有相同的配置(Job配、告警规则、等),当其中一个Down掉了以后,可以保证Prometheus持续可用。

AlertManager自带警报分组机制,即使不同的Prometheus分别发送相同的警报给Alertmanager,Alertmanager也会自动把这些警报合并处理。

去重 分组 路由
Daduplicates Groups Route
将相同的警报合并成一个 根据定义的分组 经过路由分发给指定的receiver

虽然Alertmanager 能够同时处理多个相同的Prometheus的产生的警报,如果部署的Alertmanager是单节点,那就存在明显的的单点故障风险,当Alertmanager节点down机以后,警报功能则不可用。

解决这个问题的方法就是使用传统的HA架构模式,部署Alertmanager多节点。但是由于Alertmanager之间关联存在不能满足HA的需求,因此会导致警报通知被Alertmanager重复发送多次的问题。

Alertmanager为了解决这个问题,引入了Gossip机制,为多个Alertmanager之间提供信息传递机制。确保及时的在多个Alertmanager分别接受到相同的警报信息的情况下,不会发送重复的警报信息给Receiver.

Gossip 机制

要知道什么是Gossip机制,必须了解清楚Alertmanager中的每一次警报通知是如何产生的,下面一图很详细的阐述了警报个流程:

阶段 描述
Silence 在这个阶段中Alertmanager会判断当前通知是否匹配任何静默规则;如果没有则进入下一个阶段,否则会中断流程不发送通知。
Wait Alertmanager 会根据当前集群中所处在的顺序[index],等待 index * 5s 的时间。
Dedup 当等待结束完成,进入 Dedup 阶段,这时会判断当前Alertmanager TSDB中警报是否已经发送,如果发送则中断流程,不发送警报。
Send 如果上面的未发送,则进入 Send 阶段,发送警报通知。
Gossip 警报发送成功以后,进入最后一个阶段 Gossip ,通知其他Alertmanager节点,当前警报已经发送成功。其他Alertmanager节点会保存当前已经发送过的警报记录。

Gossip的俩个关键:

  • Alertmanager 节点之间的Silence设置相同,这样确保了设置为静默的警报都不会对外发送

  • Alertmanager 节点之间通过Gossip机制同步警报通知状态,并且在流程中标记Wait阶段,保证警报是依次被集群中的Alertmanager节点读取并处理。

搭建本地 Alertmanager 集群

启动Alertmanager集群之前,需要了解一些集群相关的参数

参数 说明
--cluster.listen-address="0.0.0.0:9094" 集群服务监听端口
--cluster.peer 初始化关联其他节点的监听地址
--cluster.advertise-address 广播地址
--cluster.gossip-interval 集群消息传播时间,默认 200s
--cluster.probe-interval 各个节点的探测时间间隔
# 直接复制之前已经安装过的Alertmanager文件夹

cp -r alertmanager/ /usr/local/alertmanager01
cp -r alertmanager/ /usr/local/alertmanager02
cp -r alertmanager/ /usr/local/alertmanager03 # 复制完成以后,写入启动脚本, # Alertmanager01
cat << EOF> /lib/systemd/system/alertmanager01.service
[Unit]
Description=alertmanager
Documentation=https://prometheus.io/
After=network.target
StartLimitIntervalSec=0 [Service]
Type=simple
User=prometheus
ExecStart=/usr/local/alertmanager01/bin/alertmanager \
--config.file=/usr/local/alertmanager01/conf/alertmanager.yml \
--storage.path=/usr/local/alertmanager01/data \
--web.listen-address=":19093" \
--cluster.listen-address=192.168.1.220:19094 \
--log.level=debug
Restart=always
RestartSec=1 [Install]
WantedBy=multi-user.target
EOF # Alertmanager02 cat << EOF> /lib/systemd/system/alertmanager02.service
[Unit]
Description=alertmanager
Documentation=https://prometheus.io/
After=network.target
StartLimitIntervalSec=0 [Service]
Type=simple
User=prometheus
ExecStart=/usr/local/alertmanager02/bin/alertmanager \
--config.file=/usr/local/alertmanager02/conf/alertmanager.yml \
--storage.path=/usr/local/alertmanager02/data \
--web.listen-address=":29093" \
--cluster.listen-address=192.168.1.220:29094 \
--cluster.peer=192.168.1.220:19094 \
--log.level=debug
Restart=always
RestartSec=1 [Install]
WantedBy=multi-user.target
EOF # Alertmanager03 cat <<EOF > /lib/systemd/system/alertmanager03.service
[Unit]
Description=alertmanager
Documentation=https://prometheus.io/
After=network.target
StartLimitIntervalSec=0 [Service]
Type=simple
User=prometheus
ExecStart=/usr/local/alertmanager03/bin/alertmanager \
--config.file=/usr/local/alertmanager03/conf/alertmanager.yml \
--storage.path=/usr/local/alertmanager03/data \
--web.listen-address=":39093" \
--cluster.listen-address=192.168.1.220:39094 \
--cluster.peer=192.168.1.220:19094 \
--log.level=debug
Restart=always
RestartSec=1 [Install]
WantedBy=multi-user.target
EOF # 开启systemd脚本启动
systemctl enable alertmanager01 alertmanager02 alertmanager03
systemctl start alertmanager01 alertmanager02 alertmanager03

启动完成后,就可以访问http://192.168.1.220:19093可以看到以下集群状态了,我这里是为了测试,本地启动了多个端口,如果是实际生产环境中,是不同节点以及不同的IP,这些根据自己的需求设计即可。

Prometheus中的配置:

  external_labels: # 联邦集群附加的Label标识,可以附加在警报中,这样用于标识警报来源于那个Prometheus
dc: prom-master
alerting:
alert_relabel_configs:
- source_labels: [dc]
regex: (.+)\d+
target_label: dc
alertmanagers:
- static_configs:
#- targets: ['127.0.0.1:9093']
- targets: ['192.168.1.220:19093','192.168.1.220:29093','192.168.1.220:39093']

配置完成以后,重启或者reloadPrometheus服务,访问http://192.168.1.220:19090/config就可以看到具体的配置信息了。

到此,Alertmanager集群配置就完成了,对于集群中的警报测试很简单,直接down掉一个端口,然后触发警报,看看警报是否可以正常发送。

Prometheus监控神器-Alertmanager篇(4)的更多相关文章

  1. Prometheus监控神器-Alertmanager篇(1)

    本章节主要涵盖了Alertmanager的工作机制与配置文件的比较详细的知识内容,由浅入深的给大家讲解. 警报一直是整个监控系统中的重要组成部分,Prometheus监控系统中,采集与警报是分离的.警 ...

  2. Prometheus监控神器-Rules篇

    本章主要对如何使用Prometheus与Alertmanager组件集成配置,以及对警报规则 Rules 的俩种类型及其模板内容进行讲解. 与Alertmanager集成 Prometheus把产生的 ...

  3. Prometheus 监控报警系统 AlertManager 之邮件告警

    转载自:https://cloud.tencent.com/developer/article/1486483 文章目录1.Prometheus & AlertManager 介绍2.环境.软 ...

  4. 图文详解Prometheus监控+Grafana+Alertmanager告警安装使用

    一:前言 一个服务上线了后,你想知道这个服务是否可用,需要监控.假如线上出故障了,你要先于顾客感知错误,你需要监控.还有对数据库,服务器的监控,等等各层面的监控. 近年来,微服务架构的流行,服务数越来 ...

  5. Prometheus监控神器-服务发现篇(二)

    本章节讲解服务发现与Relabelling的机制与范例. 通过服务发现的方式,我们可以在不重启Prometheus服务的情况下动态的发现需要监控的Target实例信息. 如上图所示,对于线上环境我们可 ...

  6. Alertmanager篇

    报一直是整个监控系统中的重要组成部分,Prometheus监控系统中,采集与警报是分离的.警报规则在 Prometheus 定义,警报规则触发以后,才会将信息转发到给独立的组件 Alertmanage ...

  7. Prometheus监控学习记录

    官方文档 Prometheus基础文档 从零开始:Prometheus 进阶之路:Prometheus —— 技巧篇 进阶之路:Prometheus —— 理解篇 prometheus的数据类型介绍 ...

  8. Spring Boot 使用 Micrometer 集成 Prometheus 监控 Java 应用性能

    转载自:https://cloud.tencent.com/developer/article/1508319 文章目录1.Micrometer 介绍2.环境.软件准备3.Spring Boot 工程 ...

  9. Kubernetes容器集群管理环境 - Prometheus监控篇

    一.Prometheus介绍之前已经详细介绍了Kubernetes集群部署篇,今天这里重点说下Kubernetes监控方案-Prometheus+Grafana.Prometheus(普罗米修斯)是一 ...

随机推荐

  1. 汇编语言从键盘输入一个字符串(串长不大于80)以十进制输出字符串中非字母字符的个数(不是a to z或 A to Z)

    (1)从键盘输入一个字符串(串长不大于80). (2)以十进制输出字符串中非字母字符的个数(不是a to z或 A to Z). (3)输出原字符串且令非字母字符闪烁显示. (4)找出字符串中ASCI ...

  2. ASP.NET Core 监听SQL Server数据库的实时信息

    1.开发环境: 开发工具:Visual Studio 2019 数据库:SQL Server2012 开发环境:.Net Core 3.1 2.使用技术: Signalr:实现消息推送 SqlDepe ...

  3. PHP fileowner() 函数

    定义和用法 fileowner() 函数返回指定文件的用户 ID(所有者). 如果成功,该函数返回用户 ID.如果失败,则返回 FALSE. 语法 fileowner(filename) 参数 描述 ...

  4. HDU Typewriter 6583 dp SAM 卡常

    LINK:Typewriter 好久没写SAM了 什么都给忘了. 写了大概2h.感觉被卡常还看了题解. 考虑dp 然后容易想到维护前面的一个j决策 尽可能小. 然后每次考虑向后加一个字符 不过不行就跳 ...

  5. Dynmaics 365 scale group

    关于scale Groups的概念,在看Dynamics crm online的时候,一直不理解缩放组scale group的概念,后来查到GP也在用这个概念,想想不就是动态扩展嘛,马上顿悟了,原来如 ...

  6. [转]Nginx限流配置

    原文:https://www.cnblogs.com/biglittleant/p/8979915.html 作者:biglittleant 1. 限流算法 1.1 令牌桶算法 算法思想是: 令牌以固 ...

  7. Springboot中如何自定义注解以及使用2例

    不说废话,直接进入正题: java自定义注解主要有3步:1.编写@interface接口2.编写@interface对应的处理方法进行处理3.调用处理方法 示例一:判断奇偶:比如有一个字段no要判断奇 ...

  8. Dubbo整合Springboot框架

    本文使用的是alibaba的Dubbo. Dubbo整合Springboot可以分为四步: 第一步:首先需要了解Dubbo官方给的建议,至少有三个工程: 接口工程:主要存实体bean和业务接口 服务提 ...

  9. 阿里出品的最新版 Java 开发手册,嵩山版,扫地僧

    说起嵩山,我就想起乔峰,想起慕容复,以及他们两位老爹在少林寺大战的场景.当然了,最令我印象深刻的就是那位默默无闻,却一鸣惊人的扫地僧啊.这次,阿里出品的嵩山版 Java 开发手册的封面就有一个扫地僧, ...

  10. java 访问修饰符与代码块

    一 访问修饰符 要想本包中的类都可以访问不加修饰符即可:  要想仅能在本类中访问使用private修饰: 要想本包中的类与其他包中的子类可以访问使用protected修饰 要想所有包中的所有类都可以访 ...