大规模集群之告警系统实践

本文根据邓欢在2018年7月78日高效运维社区【数据库专场沙龙】现场演讲内容整理而成。

摘要：首先介绍告警的选型，而后介绍Alertmanager的实现，最后给你们介绍一下咱们的实践经验。

分享大纲：

一. 告警的选型
二. Alertmanager的实现
三. Alertmanager的实践

我今天会首先介绍告警的选型，而后介绍Alertmanager的实现，最后给你们介绍一下咱们的实践经验。

一. 告警的选型

在告警选型的时候，首先给你们介绍一下咱们的需求，而后我将会从需求出发肯定方案选型。

1.告警需求

咱们需求主要来自于三个方面：

• 告警的对接
• 告警的收敛
• 告警的可用性

咱们是一家乙方公司，一般服务于各类甲方爸爸，不一样甲方爸爸有不一样需求。好比甲方爸爸若是有本身的监控系统，但愿咱们的监控系统能与他们的监控系统进行对接。在与甲方爸爸接触过程当中咱们曾遇到这样的客户，有一天他跟咱们说他最新买的苹果手机被他换掉了，由于他的手机常常会死机，死机的缘由就是他收到了太多的告警，最后他专门买了一个安卓手机用来接收告警。因此咱们第二个告警需求，须要将告警进行收敛。

关于第三个问题，我想问下你们，假如长时间没有收到告警消息，大家是会认为本身系统运行的很完美，仍是会担忧告警系统挂掉了。若是是告警系统挂掉了，不能及时把告警发出来，那么最后这个锅到底由谁来背。你们都不但愿背锅，因此告警第三个问题须要解决告警的可用性问题。

下面分别从三个方面介绍一下每一个方面具体要解决什么样的问题。

（1）告警的对接

大多数告警经过监控系统发出，有部分告警能够经过服务直接发出，因此咱们但愿支持多样的告警源。对于多样告警目标，不一样公司可能用的办公软件都不同，有的公司用微信进行通信，有的公司经过钉钉进行接收消息，而客户但愿咱们把告警发到他们聊天工具中去。不一样人员的需求也不一样，运维人员习惯经过短信接收告警，大BOSS更喜欢用邮件接收告警，因此咱们告警对接须要解决的第二个问题是多样的告警目标。

（2）告警的收敛

你们是否遇到这样问题，收到一个告警而后开始排查问题，可是排查问题过程当中告警消息不停地发送过来。处理故障就是精神高度紧张的时候，重复告警消息发过来，不只对解决问题没有任何帮助，反而会增长运维人员压力。因此咱们要收敛过多的告警消息。

假设有一台服务器挂掉了，这台服务器首先会发送一个告警告诉你这台服务器挂掉了，这台服务器上面运行其余服务也被监控系统给监测到了，而且这些服务的告警消息也会发出来。可是实际上只有服务器挂掉这一条信息能帮助咱们解决问题，因此咱们告警的收敛解决关联告警过多的问题。

关于运维期间不但愿收到告警主要是由于运维一般会在大半夜进行，运维期间颇有可能会产生一些告警。若是大BOSS接到报警立刻打电话过来，这个压力可不小。因此这个时间段运维通常不但愿把告警发出来，所以告警收敛须要解决的第三个问题是运维期间不但愿收到告警。

（3）告警的可用性

接下来看告警可用性须要解决什么样的问题。前面咱们说过咱们不但愿背锅，因此咱们必需要实现告警系统的高可用。

关于第二个隔离的故障域，有的监控系统和告警系
统绑定在一块儿，若是监控系统挂掉，告警系统一样挂掉，因此咱们但愿监控系统和告警系统是分开部署的。

下面咱们将针对这三个方面的需求，来进行方案选型。

2.告警的选型

（1）备选方案

· Prometheus
· Open-falcon
· Zabbix

（2）方案对比

咱们从市面上调研了一些监控系统，其中比较流行的是Prometheus、Open-falcon、Zabbix。根据自身需求对这三个监控系统进行对比，首先咱们进行对接方面的对比。这三个系统它们均可以支持多通道的告警源，同时能够支持多通道的告警目标，因此在这个需求上面，这三个方案都是知足的。

关于告警的收敛。Zabbix 在告警的收敛上面没有任何的支持。Open-falcon只进行了一些简单的收敛，好比一段时间内重复的告警，它不会重复的发送。而Prometheus提供了灵活的规则，可以知足在不一样场景下的需求。可是通知次数上面，Open-falcon和Zabbix都限制了最大通知次数，Prometheus则没有最大通知次数的限制，在这一点上上面两个方案比Prometheus好一点。

第三个需求方面的支持。首先是Zabbix，监控系统和告警系统绑定在一块儿，因此它的故障域很大。Open-falcon和Prometheus，其监控系统和告警系统均可以单独的部署，因此它的故障域相对来讲要小，可是Open-falcon全部的组件都支持高可用，除了它的告警系统之外，这一点是比较遗憾的。

而后咱们还考量了一些其余的方面：

第一点是配置，Open-falcon和Zabbix都是基于模板的配置，而Prometheus提供的是一种树形的配置，咱们经过对比发现树形配置比较灵活，并且学习成本也相对较低。

第二点是语言，咱们公司的大多数产品都是使用GO语言，因此咱们但愿选择的方案可以贴合咱们的技术栈。经过以上方面的比较，咱们最终选择了Prometheus做为咱们的方案选型。Prometheus它是一整套的解决方案，它包括了监控系统Prometheus，以及告警的展现Grafana，以及它的告警系统Alertmanager。

总结：

二．Alertmanager的实现

下面为你们介绍告警系统Alertmanager的实现。

在介绍实现的时候，首先介绍一下它的架构。而后针对咱们前面提到的三点需求对接、收敛和可用性来介绍它的实现，中间可能会穿插一点它的配置。

首先，输入和输出。从输入上来看，虽然它是Prometheus一个项目，它能够接收Prometheus发出告警，也能够支持其余的监控系统发过来的告警。从输出来看，每个告警消息均可以定义不一样的接收者，从而实现咱们多元化告警目标的需求。

其次，中间的流程，Alertmanager收到告警以后会将告警进行分组，每个分组都会有进行抑制和静默过程，下面还会进行去重，因此它的收敛方式很是的丰富。

而后，高可用，从这里能够看出Alertmanager它也提供了高可用了支持。

下面咱们具体的看一下三个方面的需求如何知足。

1. 对接

对接方面的需求，首先对接须要接收不一样的告警源发送的告警。好比咱们用监控系统Prometheus，也有可能咱们本身的服务也会发送报警。同时客户但愿将不一样的告警发往不一样的接收者，因此咱们在对Alertmanager收敛以后，把告警发到不一样的接收者上面去。

Alertmanager它经过提供一个统一的API接收不一样告警。对于发送的话，在这里能够配置接收者，接收者不只仅能够是一个我的，能够是一个团体，也能够是第三方平台。对于我的而言能够配置邮件，在邮件配置里面能够配置多个邮件地址，也能够配置一个邮件地址。对企业而言能够配置微信，让告警发到大家公司微信企业号上；对接第三方平台的话，提供外部的配置，让告警发到第三方平台，好比钉钉相似的通讯工具。

2.收敛

接下来咱们看一下Alertmanager关于收敛的支持，Alertmanager收敛提供四种方式：

· 分组
· 抑制
· 静默
· 延时

第一，分组的支持。假设有一大堆关于MySQL的告警，可是但愿在分析问题时可以针对不一样的实例进行，因此能够针对不一样实例进行分组。每个告警都会被分往不一样实例分组中去，每个分组最后都会合成一个消息发送给接收者。因此最后运维人员收到的是一封封邮件，而每一封邮件都是关于一个实例的告警。经过这种方式有效的减小了告警消息数量；每一封邮件都是关于一个实例的告警，这种方式能够帮助运维排查一些问题。

举一个具体的例子。假设MySQL A产生了一个报警，另一台MySQL B，这台MySQL挂掉了，监控系统检测到IO线程和SQL也挂了。经过ID进行分组，不一样的实例分配到不一样的分组，最后运维将会收到两条告警消息，一条是关于MySQL A CPU太高的告警；另一条是关于MySQL B挂掉的告警消息。

第二，告警的抑制。假设有一台主机挂掉了，上面运行着MySQL的服务，这个时候主机挂掉和MySQL挂掉的两条告警到达Alertmanager的顺序可能不同，运维人员接收的告警顺序也可能不同。若是先收到MySQL服务挂掉的告警，排查问题的思路可能就往别的方向走了，可是实际上这不是最根本的缘由，因此咱们能够经过抑制，将主机挂掉的告警把这主机上面MySQL服务挂掉告警抑制掉，最后只收到主机挂掉的告警。这样可以把冗余信息消除掉，最后获得故障发生最本质的缘由。

这是一个具体的例子，这个例子和上面讲的是相似的。假设MySQL服务器A上面运行着MySQL服务，当这台服务器忽然宕机时候，这两条告警都会出来，可是你配置一条抑制规则，抑制掉MySQL的告警，最后收到服务器挂掉的告警。

第三，静默，假设你有一堆分别关于MySQL实例一、二、3的告警，可是出于某些方面的缘由不但愿收到关于实例1的告警，能够设置静默规则把它静默掉，最后就能再也不收到关于这台实例的告警，可是你仍然能够收到其余实例的告警，经过这种方式你能够阻止系统发送一些能够预期的告警。

举例，假设要在MySQL A上面跑一个批处理任务，这个批处理任务消耗系统资源比较大，会触发这些告警。同时你的系统中还有一台MySQL B的服务器，这个是对外提供服务的，你不但愿把它的报警给静默掉，因此能够配置一条静默规则，把MySQL A告警给静默掉，最后就收不到关于MySQL A的告警，同时其余服务不会被影响到。

第四，告警的延时，假设系统发生故障产生告警，每分钟发送一条告警消息，这样的告警信息十分使人崩溃。Alertmanager提供第一个参数是repeat interval，能够将重复的告警以更大频率发送，可是只有这个参数会带来两个的问题。第一个问题是告警不能及时收到。假设当前发送一条告警，下一次告警在一个小时以后，但在这一个小时以内系统产生了一条告警，这时告警没法被及时发出去。因此alertmanager提供了第二个参数group inteval，让报警可以及时的发送出去。

另外一个问题，当故障发生时，告警条件一个个被知足，到达Alertmanager的顺序也分前后，因此在最开始的时候可能收到多个消息。Alertmanager提供了第三个参数叫作group wait，在一个分组收到第一条报警消息以后，经过等到group wait，把故障最开始发生时候产生告警收敛掉，最后做为一条消息发送出来。

3.配置

下面咱们讲一下Alertmanager的配置，前面咱们提到Alertmanager使用的是树形配置。树形配置每个节点定义一个路由规则，匹配路由规则的告警都发送给同一个接收者，前面提到接收者能够经过不一样方式进行接收。Alertmanager的树形配置根接点，必须匹配全部告警，由于每一条告警都必须有一个接收者。

假设全部的告警中，对于MongoDB和MySQL有专门的人员在负责，因此在根节点下面配了两个子节点，分别匹配这两个报警。对于这两个服务的告警，会分别发送不一样运维人员手上。可是在全部的MySQL服务当中有两类服务是特别重要的，他们分别在group1和group2里面。因此当但愿MySQL服务出现告警，而且是属于group1时，让它发往group1的负责人；对于group2出现的问题由group2的负责人去处理；对于其余MySQL出现问题，由MySQL的运维人员去处理。若是是Zabbix，那么可能将要定义特别多的模板，相对来讲Alertmanager提供的配置比较简洁，并且也相对灵活。

这是它配置的实现，配置格式是yml的。首先须要配置接收者，而后经过这个group by定义的标签将告警进行分组。根路由下面定义了两个子节点，分别将MongoDB和MySQL的告警发给各自的负责人。在每一个节点能够设置不一样的延时时间，而且它们分组方式也能够不同。

4.可用性

这一小节将介绍Alertmanager高可用的实现方式。在Prometheus项目的官方介绍中，Alertmanager是单独部署的，每个Alertmanager它都单独接收来自Prometheus的告警，而后单独的将告警进行收敛，最后发送出去。可是会有一个问题，不一样的Alertmanager实例可能会发送相同的告警。因此在每个Alertmanager发送告警以前，它经过Gossip协议去其余实例获取当前已经有哪些告警发送出去，若是当前想发送的告警已经发送出去了，就不会再发送，从而避免多个Alertmanager发送同一个告警的问题。

三．Alertmanager的实践

下面我给你们介绍一下咱们的实践经验，首先我会给你们介绍咱们的架构，而后是咱们的调度层级，最后咱们会介绍一些关于SRE的问题。

· 架构
· 调度层级
· SRE

1. 架构

这是咱们的架构，分为核心区和受管区。

在核心区咱们部署监控组件Prometheus和告警组件Alertmanager。在受管区是咱们的数据采集服务和被监控的服务。咱们经过Agent采集不一样服务状态，Prometheus会按期从Agent收集数据，单独进行规则断定。若是知足告警规则的话，会往Alertmanager发送告警。

同时Prometheus做为一个监控组件，也提供了监控数据的来源，能够直接展现系统监控数据。咱们把Prometheus发送的告警称之为阈值告警，还有一类叫作动做告警。动做告警不像阈值告警按期采集数据获取，它就是一个动做。好比咱们高可用组件把MySQL组成切换了，它会立刻把告警发送出去。

2.调度层级

接下来看咱们调度层级，咱们使用的是经典的error kernel模型，好比咱们的MySQL实例，上面是监控客户端，监控客户端按期去MySQL实例采集数据。再上面是咱们监控管理端，监控管理端按期从监控客户端拉取数据，从而进行规则断定。若是它发送告警，会往上一层Alertmanager发送。

咱们并无采用Alertmanager自己提供的高可用实现方式。由于在咱们选型的时候，这个组件还处于活跃的开发状态，当时它的高可用并非那么的可靠，因此咱们把Alertmanager和Consul联合在一块儿，它实现了Raft协议，咱们经过Raft一致性协议来保证Alertmanager高可用。

同时咱们也实现了反向告警的机制。一般运维人员收到一条告警时候，系统必定出现一个故障，运维人员须要采起动做。可是运维人员收到反向告警不须要采起什么措施。由于收到一条反向告警，意味着整个集群正常工做，若是整个集群都不能正常工做反向告警是发不出来的。

3.SRE

接下来咱们讲一讲SRE。SRE是谷歌的站点可靠性工程，它对监控系统提出了两点建议。

第一点建议，报警信息应由系统自动解决，仅仅是当须要的时候通知用户。其实告警系统的存在彻底是由于系统的不完善致使的，若是系统足够可靠，不可能发生故障，或者能处理掉发生的故障。不能处理的时候须要发送一个告警让人员来介入，可是让人员来介入效率比较低。

第二点建议，收到报警须要用户当即执行某种操做，解决已经发生或者即将发生的问题。针对SRE建议，咱们有一些实践是遵循了它的建议，可是有一些根据咱们的实际须要，咱们并无遵循它的建议。

咱们第一个实践是遵循了它的建议，咱们以前说过告警分为阈值告警和动做告警，一般在动做告警当中服务挂掉了会发送一个告警，可是服务被拉起时告警并无解决掉，咱们遵循了报警自动解决建议，服务拉起以后把原来的告警给解决掉。

下面一个，咱们没有遵循它的SRE建议，咱们在选型的时候说过Alertmanager有个缺陷，不支持通知次数的限制。其实Alertmanager是由谷歌出来一帮人研发的，因此他们所作的工做会遵循SRE。可是实践中发现大规模集群经过Alertmanager收敛以后，发出来消息仍然可能特别多，而且过多的告警消息在运维人员解决问题的时候是并无帮助的，因此咱们为了人性化的体验，增长了最大通知次数的限制，虽然这违反了它的一些建议。

咱们下一个实践的经验是发送notice级别的告警，这一点也没有遵循它的建议。由于按照它的建议不须要运维人员介入的告警不须要发送给运维人员。可是咱们须要知道系统发生了这样一种情况，而且知道发生情况的缘由是什么，因此咱们增长了notice级别的告警。

下面是咱们的告警展现，这是咱们本身的实践。

最后给你们推荐的是《Google SRE运维解密》这本书，这本书是谷歌运维的一些经验总结，还提出了一些很好的指导建议。这本书在最近刚发布了第二版，并且最近一个月它都是能够免费下载的，你们感兴趣的话能够去看一看。

下载地址：
https://landing.google.com/sr...

谢谢你们。

PPT下载连接：
http://github.com/actiontech/...