Prometheus监控神器-Alertmanager篇（四）-低调大师

Prometheus监控神器-Alertmanager篇（四）

2020-08-24 814

本章节主要讲解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/alertmanager01cp -r alertmanager/ /usr/local/alertmanager02cp -r alertmanager/ /usr/local/alertmanager03
# 复制完成以后，写入启动脚本，
# Alertmanager01cat << EOF> /lib/systemd/system/alertmanager01.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0
[Service]Type=simpleUser=prometheusExecStart=/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=debugRestart=alwaysRestartSec=1
[Install]WantedBy=multi-user.targetEOF
# Alertmanager02
cat << EOF> /lib/systemd/system/alertmanager02.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0
[Service]Type=simpleUser=prometheusExecStart=/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=debugRestart=alwaysRestartSec=1
[Install]WantedBy=multi-user.targetEOF
# Alertmanager03
cat <<EOF > /lib/systemd/system/alertmanager03.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0
[Service]Type=simpleUser=prometheusExecStart=/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=debugRestart=alwaysRestartSec=1
[Install]WantedBy=multi-user.targetEOF
# 开启systemd脚本启动systemctl enable alertmanager01 alertmanager02 alertmanager03systemctl start alertmanager01 alertmanager02 alertmanager03

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

Prometheus中的配置：

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掉一个端口，然后触发警报，看看警报是否可以正常发送。

本文分享自微信公众号 - Kubernetes技术栈（k8stech）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/u/3475597/blog/4528489

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

消息队列之推还是拉，RocketMQ 和 Kafka是如何做的？

每个时代，都不会亏待会学习的人大家好，我是 yes。今天我们就来谈一谈消息队列的推拉模式，这也是一个面试热点，例如你在简历里面写了 RocketMQ ，基本上会问你 RocketMQ 采用的是推模式还是拉模式啊？是拉模式？不是有 PushConsumer 吗？今天我们就来谈谈推拉模式，并且再来看看 RocketMQ 和 Kafka 是如何做的。推拉模式首先明确一下推拉模式到底是在讨论消息队列的哪一个步骤，一般而言我们在谈论推拉模式的时候指的是 Comsumer 和 Broker 之间的交互。默认的认为 Producer 与 Broker 之间就是推的方式，即 Producer 将消息推送给 Broker，而不是 Broker 主动去拉取消息。想象一下，如果需要 Broker 去拉取消息，那么 Producer 就必须在本地通过日志的形式保存消息来等待 Broker 的拉取，如果有很多生产者的话，那么消息的可靠性不仅仅靠 Broker 自身，还需要靠成百上千的 Producer。 Broker 还能靠多副本等机制来保证消息的存储可靠，而成百上千的 Producer 可靠性就...

2020-08-25

569

七夕情人节又双叒叕到了一年一度的中国传统情人节——七夕，那么思考一下自己有对象了吗，是否还是单身，或者想清楚怎么跟心动的ta表达心意了吗？不知道，那来看看如何利用我们的技能让女神男神刮目相看吧，说不定最后就眉目传情，就有对象了。有对象的拿去跟对象表达爱也是可以的。敲重点啦！代码贴上：（1）代码中的图形颜色，文字内容均可自己按照需求更改，是不是简单而又不失高级 import turtleimport randomdef love(x, y): # 在(x,y)处画爱心 lv = turtle.Turtle() lv.hideturtle() lv.up() lv.goto(x, y) # 定位到(x,y) def curvemove(): # 画圆弧 for i in range(20): lv.right(10) lv.forward(2) lv.color('red', 'pink') lv.speed(10000000) lv.pensize(1) # 开始画爱心lalala lv.down() lv.begin_fill() lv.left(140) lv.forward...

2020-08-25

579

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。