2020年工做上的最大收获——监控告警体系

1 背景

2020年工做上的最大收获就是初步完善了系统的监控告警体系。
2020年工做上可谓是很是苦逼的，项目上忙到脚打后脑勺的同时还被各类发布问题、生产故障按在地上摩擦。可怜还因疫情缘由公司福利大大缩减。
总结了一下使人头疼的问题：

1. 每次大的发布总会产生一堆的生产问题
2. 平常应用出错不能第一时间感知，老是到了客户那里才报过来

好比有一次发布后产生了一个小小的传值问题，可是会阻碍一部分客户下单，结果两天后经过客户报障才发现，最终致使大量订单损失！
整体来说就是缺少对系统的掌控，应用发布上去后，就像个黑匣子，你只知道它在运行，殊不知道里面究竟是个什么情况，也许内部已经乱的不可开交,你却一无所知，发布以后只留下一脸懵逼的你独自凌乱。以至于每次发布后的几天都是提心吊胆，有点风吹草动就慌得一比！而在互联网这个频繁发布的行业简直就是灾难
痛定思痛！终于在下半年的时候忍无可忍，决定给系统插上X光机。不只要扒掉系统这个“美女”的黑色外衣，甚至让其骨骼线条都赤裸裸的暴露在开发人员眼中。这个X光机就是监控告警体系。

2 技术方案

咱们所使用的是公司自研的监控系统。其大体实现以下图:

1. 各应用系统经过代理客户端写入Kafka
2. 持久化层服务订阅Kafka消息进行持久化，这其中Influxdb主要存储时序埋点，MySql与ES存储点的一些特性方便检索与聚合
3. UI层读取展现埋点信息，监控告警配置，主要借助两个强大的可视化工具，Graphana与Kibana。

实现监控告警体系其实就分3步：

1. 应用系统埋点
2. 可视化展现
3. 监控告警配置

最简单的方式能够经过 ES+Kibana的方案来实现

注意;在系统没有遇到瓶颈的时候应该尽量的用最简单的方案解决问题，每引入一个中间件便大大增长了系统的复杂度和维护成本

3 监控内容

技术上的实现，其实只是监控体系的第一步。最重要的部分在于监控的内容，只有作好了监控内容才算是给你的系统构建了一个良好的监控大网。而监控哪些内容，不一样的系统，不一样的业务需求都不相同，这就须要根据业务与系统的要求去制定与不断的完善。
根据咱们的经验总结了几个通用的监控点

1. 请求量

请求量不只能够用来统计接口调用的数量、QPS等信息，还能够发现系统的问题。
这里请求量主要包含两部分，一个是你本身提供的接口的请求量，一部分是你所依赖接口的请求量

• 若是你本身提供的接口的请求量忽然降低，那么说明依赖你接口的下游应用、或是前置页面极有可能除了问题。
• 而若是你本身接口的请求量正常，而所调用的第三方接口的请求量忽然降低，那么极有可能你本身的代码逻辑除了问题

请求量通常经过曲线图展现，能够更好的反映出来一个趋势。

2. 响应量

响应量一般能够和请求量结合使用，若是一个接口正常响应量小于请求量，那么说明有一部分的请求是存在问题的。

3. 耗时

接口耗时主要用来监控接口性能，一样包括你本身提供的接口的耗时和你所依赖的接口耗时。

4. 订单量

在许多系统中，订单量都是一个很重要的业务指标，也是咱们最重要的监控指标之一。

5. 响应状态

响应状态是一个很好的监控指标，它可以很好的反映咱们程序的处理结果。响应状态比较适合用饼图来展现。能够很好的反映出各类状态的占比。

6. 异常状态

同响应状态同样，异常状态的监控也具备很重要的意义。同时异常状态也是咱们用户告警的重要指标之一，他能够很直观的反映出咱们系统的健康状态，异常状态能够用饼图，也能够用曲线图来展现。

7. 页面之间转化率

页面之间转化率不只仅是用户衡量产品价值的指标，一样是咱们系统监控的重要指标，若是从一个页面到另外一个页面的转化率忽然下降，那么极有多是这之间出现了什么问题。

8. 其它

还有不少针对具体业务的监控指标，如搜索一般会有空搜率，商品会有缺货率。。。
固然，可能还有不少不足，也可能随着业务需求的变化，有些监控内容可能已通过时，又可能会须要更多监控，
这里只提供一些思路，总之针对业务上的各类场景你能够尽情去作到一切皆埋点。

4 告警策略

监控内容最好以后，监控体系并无结束，还差一步，就是自动告警。自动告警的功能Grafana和Kibana均可以提供，也能够自定义咱们想要的告警方式。
这里咱们主要的告警策略主要有三种

1. 阈值

咱们能够对请求量、订单量、异常量设定一个阈值，当每分钟每小时请求量降低到某个阈值，或者异常量达到某个阈值的时候，触发咱们的告警。

2. 环比

环比主要是与前一段时间的对比，好比这一小时(或一天)的请求量与上一小时(或一天)的请求量对比，若是小于若是小于某个阈值，就触发咱们的告警。

3. 同比

有些时候环比是不可靠的，好比，咱们系统的特性就是周2、周3、周四的请求量要远大于周5、周6、周天的请求量，此时若是拿周六的请求量和周五的请求量的去对比是没有意义的，这里就须要用到同比，即拿上周五的请求量和本周五的请求量进行对比，当小于某个阈值的时候触发告警。
注意:这里的告警和阈值并不是能够一蹴而就的，须要结合实际去慢慢调整它到一个合适的值，咱们就深感其痛。(起初就由于一些不合理的告警配置，咱们优秀的人工智能常常三更半夜给打你电话，结果一般是虚惊一场，它还比较轴，你不处理它就一直打)。

5 监控成果

历时半年，咱们对系统的监控告警体系的打造总算是告一段落。俗话说要想吃多少肉，就要先挨多少揍。这期间过程虽然是辛苦的，但成果也是巨大的。以前的问题获得了良好的解决。大部分的线上问题，第一时间就暴露了出来，有些问题在测试环境上经过监控就提前发现。这也侧面的助力咱们的测试工做。甚至在监控体系上线后一些“陈年”老bug也开始暴露出来。生产事件率大幅降低。 最重要的是每一个开发人员对系统多了一种掌控的感受，期待有一天，一群苦逼了许久的程序员能够在从此的每次发布后，轻松看着监控大盘，喝茶扯淡！