开发者学堂课程【3天吃透 Prometheus：Alertmanager 告警】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18450
Alertmanager 告警
内容介绍：
一、告警功能概述
二、Prometheus 监控系统的告警逻辑
三、部署 A lertmanager
四、Alertmanager 基础配置示例
五、组合 Prometheus 与 Alertmanager
六、告警规则
七、添加告警规则
八、告警模版
九、告警路由
一、告警功能概述
大家知道一个监控系统，用指标或者叫数据的采集、存储、展示和告警四种功能。
对于 Prometheus 而言，大家发现即便他有自己内建的表达式浏览器，但事实上它只适合做调试用，它只是一个表达式浏览器。我们对于某些表达式的编制到底是否能能够按照我们所期望的方式工作，他给我们提供了一个调试接口。我们要展示需要放置在 graph and 这样的展示接口中实现的。
同样的逻辑， Prometheus 对于告警的功能依然一样，没有自我实现。它也需要分开到另外一个组件中来完成，而且我们曾经提到过这个组件叫做 alert manager。正常情况下，前者也就是我的 Prometheus server 自身仅负责基于所有的告警规则，跟记录规则很相像，记录规则是用来定义指标生成的新规则的，而告警规则通常是一个布尔表达式，一个布尔表达式的结果要么为false或 true。如果对应的告警规则的返回值为false，就意味着它满足我们的条件。而满足这个条件通常是用于表达有异常事件发生，所以等到的值正常应该都是false，一旦为true，它就会生成一个所谓叫做告警通知信息，借助于告警规则生成告警的通知，这个告警通知会通知给谁呢？
事实上， Prometheus server 是作为 alert manager客户端，必须告诉 Prometheus server alert manager 究竟在何处，所谓叫在何处，也就意味着我们可以认为 alert manager 提供了告警服务。 Prometheus server 要调用这种服务，使得将其告警功能得以完成。 alert manager 既然是一个独立的服务，那么它也依应该是Prometheus，可拿来被当做监控 target 的组件之一。
因而，我们完全可以基于 Prometheus server 定制一些规则去发现 alert manager。而我发现对发现的 alert manager 两个不同的功能，一把它对接为自己告警的服务端，二把它对接为自己监控的目标target，在这里我们要需要做两项配置，alert manager 它独立于 Prometheus server 之外，是因为 alert manager 自己还能接受其他对应的监控系统的告警功能，所以它是要说它的目的是为了做一个更具通用性的告警服务器，我们写的应用程序，只要调用了 alert manager 的API，也完全可以借助于 alert manager 完成告警功能。alert manager 都要注意的是，所谓时间告警，无非就是把发生了异常事件的这个事件本身通知给对应事务的管理人员，或者对应事务的负责人。因此，通常情况下，无非就是通过某一种媒介， alert manager 通过某一种媒介把通知信息送给媒介上能够接收通知信息的端点，这里端点不是指的 front 网络端点，而是指能够接收通知信息的接收人。我们通常把它称叫receiver，注意概念叫做接收人。比如，如果我们要通过邮件发送告知通知信息，就意味着我们必然有一个邮件服务器，而后能够把邮件转发到用户的邮箱当中去就可以了。同样的，如果通过 wechat 来发通知信息，我要指定一个微信账号，用微信的购服务接口进而把消息通知给微信账号上去。这是一个告诉系统的基本功能。但事实上，我们的 alert manager 除了能够对基本能完成告警的通知之外，它还能被告警通知进行。比如某一个监控的服务器不是它监控的第二监控，如果某一个监控的 target 发生故障了，如果 target 自己故障， target 之上的所有指标可能都会异常。再比如，如果我们将某个交换机发生故障， permission server 通过交换机才能接入的那些所有 target 采集的指标记录都一定会异常的。所以在这种情况之下，我们可以实现基于这些高级功能做分组去重来，包括还有移植等，避免一个告警大量的信息给用户发过去。turning up 交换机出了问题，不见得每个 target 都出了问题，但是我们得知道，交换机出了问题以后，一定它会导致采集指标时，这些被监控 target 的指标都异常了。这就意味着被监控对象彼此间可能会有一定的依赖关系。如果我们定义出依赖关系来，被依赖的指标异常了，依赖这个指标的其他指标就不用再报警了。就像刚才说过，交换机宕机了，我只需要报告给管理员降级宕机了。不用把交换机宕机之后被影响的这些服务器也都报告一遍，因为服机可能并没有出故障。反正你抓的指标一长，管理员可能一会就看上去那么多告警信息就故障。所以大家一定要理解，这里的逻辑其实很关键。因此它要抑制，它要分组，它要去重等，而且还应该根据路由规则，将对应的告警路由到不同的 receiver 上，它是合理的。再比如，在我们的公司内部，可能公司的规模比较大，但是统一纳入到同一个监控系统中进行监控的。但是在公司内部， MySQL 服务器等等，有专门的 DBA 来负责我们的，比如像rocket、 MQ 或者Kafka，有专门的几个管理员来负责我们消息对应的运维工程师。很显然，我们应该在监控时，如果发现了 DB 异常，可以没必要通知给所有英文工程师，所以我可以给你服务，或者给你标签。我用标准来判断一下究竟是哪个服务，或者哪一组，哪种组件发生故障。我们给它路由到发送给不同的 receiver 上，让他们怎么描述的？对应的数据库服务器发生故障就应该送给DDA。消息队列服务器发生故障就应该送给消息队列的运维工程师，如果长时间不能解决，我们可以送给消息队列运维工程师的负责人，再让你送给c、t、o，这是可以的。但你送给d、b、a，可能问你相关性并不是特别大。不过有时候真的发生大面积故障或者有些严重故障，我们很有可能需要召回所有的运维工程师来成立一个临时故障恢复战时管理小组，会要指挥办公室，大家分工每个人从哪些角度来进行排查问题，各司其职，各自分工的都达到快速找到问题，解决问题，那个时候可能每个人都要回一线，很显然还是那句话，告警只是第一步，解决问题真正定位出问题了并解决问题才是第二步。
但是很重要的是，在这做监控系统，大家发现还有有意的模拟系统故障的。生产环境当中，比如像作为一个电商战略来讲，服务器发生故障是很严重的事件，通常这个时候一旦发生故障，我们很有可能的时候在背负着极大心理压力下，可能如果此前没有经历过充分演练，整个人就慌了，整个团队可能就无头苍蝇一样乱撞。因而运维工程师应该有一定的所谓的运维管理规范，这是要靠行政制度来保证的。发现问题最之后，那么多大吉利的问题，我们应该有哪些人能响应。而且最好我们在实现故障报损的时候，就能对故障程度进行一些简单的分级，再不然就是一线职守人能做分级，分级完以后，他可以有权限去召集或者去触发相关的人员立即回到现场。当然可能不一定真的到公司来，不在家基于网络成立协作小组解决问题也是有可能的，但是告警也是第一步，而且也非常重要的一步，更重要的是，我们也期望在告警这一关就能够把问题本身定位出意的，或者反映出七七八来。
二、Prometheus 监控系统的告警逻辑
因此，正常情况下，我们在 Prometheus 当中要想使用告警功能，首先就要提示应用程序和纳入到监控器有用来。而在配置逻辑上，我们需要在 alert manager 上定义出原有个描述，定义出合理的receiver，而后再去根据我们对应的告警机制，通过路由规则把合理的信息路由给合理的receiver。
所以这个图我们大小画出来就描述变成意思，Prometheus 上定义 alert rule，同时 Prometheus 上也指明了谁是 alert manager。因此 alert rule 触发的告警通知会到达 alert manager，而后到达我们 alert manager 上路由标的根路由，我们的人一旦一个交换机出了故障，收了上百个告警信息，大家一定要了解好，这是告警功能的概念。因此正常情况下，我们在 Prometheus 当中要想使用告警功能，首先就要预置 Prometheus 成为 alert manager，告警客户端到底要收口。反过来， alert manager 也利用程序同样也跟纳入过监控系统中来，而在配置逻辑上，我们需要在 alert manager 上定义出，根据我刚才的描述，定义出合理的receiver，而后再去根据我们对应的告警机制，通过路由规则把合理的信息路由给合理的receiver。所以这个图我们大体上划出来，描述Prometheus定义 alert rule，同时 Prometheus 上也指明谁是 alert manager。因此若触发的告警通知会到达 alert manager，而后到alert manager，路由表根部有对入口，名称叫根路由。它整体会生成一个路由树，你看到就像一棵树一样有分叉。接着，在每一个子路由上，我们通常是由 match 来匹配通知信息的某一部分或者某些特征。 match 就跟我们地址的路由表一样，就根据报文的目标Ip 地址来匹配，这有更灵活的匹配机制，我们要根据路由，报警信息当中的某一些特征，这个特征就是指你的报警的标签，而报警的标签就是你对应的指标。时间序列的标签等于我们叫降标列，一旦一个告警被触发以后，告警会自动复制它相关的时间序列上的所有标签。因而看到的标签就跟时间序列是相同的，所以我们就可以根据它的标签什么之类的来加一些过滤条件，如果能匹配到就送给receiver。底下定有receiver，所以报文就通过媒介送给receiver。因此每一个 receiver 应该有具体的定义，我们应该指明它的媒介是什么。比如，如果是邮件，邮件是邮箱地址，要指明邮件服务器是谁，首先要把邮件送给服务器，而后接收人是谁，就是接收的邮件地址是谁，有没有抄送人等等。如果是微信也一样，你要指明我们要调微信服务器的 web hook，叫 web 钩子，是哪儿通道给地址，指定的微信账号是什么，有无抄送人等等。定一个 receiver 就类似于格式，因而一旦 match ，我们指定某一个receiver，对应的高级信息就会调用他的通知媒介送给他的接受人了。如果我们定对应的告警信息已经匹配到了第一个 receiver 之上，还有没有匹配第二个，还有匹配第三个，后面后续的要不要再继续检查，是完全可以根据我们自己定义的逻辑来实现，比如我们要想实现告警升级，也是可以做到的。刚开始触发告警的时候，我们可以给他附加一些别的标签什么之类的。或者有些判断条件，刚刚附加一个告警的时候，我们定它的严重级别，比如像是 warning 是警告级别，好长时间没解决，我就给它升级了，升级成比如像 alert 或者是 emergency the recritical。类似于这种描述严重等级的级别也能做到。
接着一旦我们可以找到这样一个逻辑之后，正常promises 的告警功能就可以工作。有时候对应的状态转换可能就是偶尔的一次状态转换，真正发生的严重事情。所以我们说 alert root 评估出来某一个异常发生的时候，不应该第一时间就去报警，因而我们通常可能会不能持续一个时间窗口，比如异常值。对应的告警规则的表达式采样结果为true，我们是会有异常发生的。 true 持续了 2 分钟还没下去，甚至持续了 5 分钟仍然没下去。我认为它可能是真出现问题了，所以要稍微再等上一段时间。这是 permission 定义的，一旦第一次触发的时候，我们就把它进入，把它置为叫做跟这个告警就一定触发出来了。但这个告警不会立即送给了 connect manager 去发送，而是先在我的 permission server 暂存一会儿。这个暂存的状态，我们为什么要pending？告警会被 pending 到此处，一旦超出了我们应该 pending 的最长时长，这个告警信息就真的会被fired，就被发出去了，这就是 promises 的基本的告警逻辑。我们也可以通过 group 将告警规则进行统一定义。将多个规则并在一个组当中，以实现分组的功能。分组可以将多个告警信息、多个告警通知合并成一个。在某些情况下，比如像系统宕机导致大量的告警被触发的时候，一个节点到另一节点之上肯定有运行的服务，各个指标都一定会异常的。刚才给大家说过这个概念，所以像这种情况下，我们做分组，可以只发一次，它可以只触发一次，我们也可以做抑制。所以抑制指的是当一个告警发送完以后，你马上隔了 2 秒钟，因为其他逻辑又触发了，还要再发一次。可以等一段时间再重复发送告警信息。甚至我们也可以静默。这个功能叫静默，比如我们每一周三晚上凌晨 1 点钟例行维护，我们把服务器停了几台，给他做个检查什么之类的，这个时候服务器平台是要告警。我们为了避免这种例行违规的期间要告警，我们可以给他定制静默期间，在这段时间内触发的任何异常状况都不要告警，这叫静默。是我来看看怎么去部署 elephant manager，怎么去把我们的告警功能给它应用起来。先部署好 alert manager，而后我们再去试图写报警规则。
三、部署 Alertmanager
部署 alert manager 的方式跟前面部署 permission server 一样，你可以下载合理的格式的程序包到本地来。
官方提供的都是 go 程序，它都是 tag 格式打包的，所以下过来展开到自定目录下。因为是由 go 研发的，所以都是单一二级程序，我直接运行就行，它本地有一个配音的配文件，我们在配组件中定义好物流，定义好receiver 。
比如想要提到的分组、抑制、静默等功能。主要分组抑制静默语法而言，我可以用来用名义或者通过他的 m 撤来进行定义。所以我们先去部署manager 仍然以 method 1为这一版。我把 method 1 自己这个节点也当做是我们的告警服务的运行节点。等于是我们此前重新下载好的一个程序包，应该已经是比较新的版本了。 direct manager 0. 21. 0 的版本好，下载位置仍然在 Prometheus 的官方站点上，它会像Grandma。Grandma 自己是一个独立的项目，它有自己独立的网站。而 alert manager 跟 model exporter 等一样，都是由 permissions 来维护的。所以我们要到 permission 的站点上去下载。我们展开 learning manager， 点say，依然把 user 弄走保持切换。我看到一个程序文件，这是程序一个配置文件，一个是用来能够去命行对接到服务上设置静默功能的一个客户。比较重要的投放工序分静默不能静默功能的配置。它的功能只有 am tool。 alert manager 简称为 am tool，命令行客服端就能写程序。
打开 alert manager，点一，然后做一些简单的编辑。可以看到它大体上也就用这样几个字段组成。看顶级字段第一 global 大家明白，这是全局配这段 brute 路由。这是根路由，顶级的 root 叫根路由，底下可以配各根子路由，像 roots 之类的。当然我们也可以不给这直接指定receiver，就意味着所有告警都发给同一个接受人。这个接口人是谁？底下使用receiver，又有一个顶级字段来定义 1 到多个receiver。
比如这里使用的是 web hook， web 钩子，从调对应的服务，由这个服务来决定该怎么发动进行。当在这上面通常应该还有如果是个，如果是钉钉，还有钉钉的接收人地址，如果是 Wechat 接收人地址等等。接着叫 intense Ross，我叫静默规则，叫抑制规则。哪些情况下我们应该对相应的告警应该进行抑制，以免他发送过多的告警信息，导致接收人被告警洪流所淹没，所以记住按 4 个定级字段global， root receiver 和 inhales rows，而且最后的一个配置，如果没有遇到可以不用定义，用一个最为简单的配置。
