目录
一、前言
二、Alertmanager机制
三、alertmanager 核心特性
3.1 分组Grouping
3.2 抑制Inhibition
3.3 静默Silences
3.4 客户端行为Client behavior
3.5 高可用 High Availability（HA）
报警是监控软件的极其重要的一环，所以本专栏最后的一个知识点为报警处理。
前面已经讲了Prometheus服务器、数据采集的 exporters （导出器）、数据分析PromQL和呈现的webUI/Grafana/API、只剩下了报警处理alertmanager，这个整个基础架构就讲完了。
一、前言
我的讲解是以Prometheus的架构从中-左-右讲解的，下面是Prometheus Architecture架构图：
上图中，我圈的紫色部分在前面已经是讲解和学习了
中间部分：上和中我都讲了，在最下是TSDB从prom服务分离出来，说白了就安装一个独立的时序数据库，一般推荐安装InfluxDB，我这里就不再详解了，可以看一下《Prometheus监控技术与实践》里面有介绍。
左边部分：我讲解了左下的exporters，左上的push gateway ，完全可以自己弄了，我这里也不做讲解，《Prometheus监控技术与实践》里面也有介绍。
右下部分：讲了web UI和Grafana，API clients在grafana官方文档也会讲解，只要学过开发的，不是很难。
现在整个架构只差右上报警部分alertmanager 没有讲，讲完alertmanager ，整体上prom框架就讲完了。
二、Alertmanager机制
prom中由Prometheus server和 alertmanager 两个组件组成一个报警体系。Prometheus告警机制如下图所示：
上面的大概流程为：
- Prometheus server采集各类监控指标，然后基于PromQL对这些指标定义阈值告警规则（Rules）。
- Prometheus server对告警规则周期性地进行计算，如果满足告警触发条件，便生成一条告警信息，并将其推送到Alertmanager组件。
- 收到告警信息后，Alertmanager会处理告警，进行分组（grouping）并将它们路由（routing）到正确的接收器（receiver），如Email、PagerDuty和HipChat等，最终把异常事件的通知发送给接收者。
三、alertmanager 核心特性
Alertmanager处理由客户端应用程序（例如Prometheus服务器）发送的警报。 它负责将重复数据删除，分组和路由到正确的接收者。
在这里把AlertManager中告警的分组（Grouping）、抑制（Inhibition）和静默（Silences）核心特性进行简要介绍
3.1 分组Grouping
分组机制（Grouping）是指，AlertManager将同类型的告警进行分组，合并多条告警到一个通知中。
在实际生产环境中，如果多台设备有问题，导致它及它们关联的设备都可能发现问题，可能会导致成百上千个报警被触发，瞬间让这么多报警，使得管理员无法对问题进行快速定位。在这种情况下使用分组机制，可以将这些被触发的告警合并为一个告警进行通知。
例如，在一个Kubernetes集群中，运行着重量级规模数量的实例，即便是集群中持续一小段时间的网络延时或间歇式断开，也会引起大量应用程序无法连接数据库的故障。如果我们在Prometheus告警规则中配置为每一个服务实例都发送告警，那么最后的结果就是大量的告警被发送到Alertmanager中心。
其实，作为集群管理员，可能希望在一个通知中就能快速查看是哪些服务实例被本次故障影响了。此时，对服务所在集群或者告警名称进行分组打包配置，将这些告警紧凑在一起成为一个“大”的通知时，管理员就不会受到告警的频繁“轰炸”。告警分组、告警时间和告警接收器均是通过Alertmanager的配置文件来完成配置的。
3.2 抑制Inhibition
Alertmanager的抑制机制（Inhibition）是指，当某告警已经发出，停止重复发送由此告警引发的其他异常或故障的告警机制。
在生产环境中，例如IDC托管机柜中，若每个机柜接入层仅仅是单台交换机，那么该机柜接入交换机故障会造成机柜中服务器非UP状态告警；再有服务器上部署的应用不可访问也会触发告警。此时，可以配置Alertmanager忽略由交换机故障造成的机柜所有服务器及其应用不可访问而产生的告警。
在我们的灾备体系中，当原集群故障宕机业务彻底无法访问时，会把用户流量切换到灾备集群中，这样为故障集群及其提供的各个微服务状态发送告警就失去了意义，此时，Alertmanager的抑制机制在一定程度上避免了管理员收到过多的触发告警通知。抑制机制也是通过Alertmanager的配置文件进行设置的。
3.3 静默Silences
告警静默（Silences）提供了一个简单的机制，可以根据标签快速对告警进行静默处理。对传入的告警进行匹配检查，如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。管理员可以直接在Alertmanager的Web界面中临时屏蔽指定的告警通知。
3.4 客户端行为Client behavior
Alertmanager对客户的行为有特殊要求。 这些仅与不使用Prometheus发送警报的高级用例有关。
3.5 高可用 High Availability（HA）
Alertmanager支持配置以创建集群以实现高可用性。 可以使用--cluster-*标志进行配置。
重要的是不要在Prometheus及其Alertmanagers之间平衡流量，而是将Prometheus指向所有Alertmanagers的列表。