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

1 背景

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

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

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

2 技术方案

我们所使用的是公司自研的监控系统。其大致实现如下图:

image.png

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

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

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

最简单的方式可以通过 ES+Kibana的方案来实现
image.png
注意;在系统没有遇到瓶颈的时候应该尽可能的用最简单的方案解决问题,每引入一个中间件便大大增加了系统的复杂度和维护成本

3 监控内容

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

  1. 请求量

请求量不仅可以用来统计接口调用的数量、QPS等信息,还可以发现系统的问题。
这里请求量主要包含两部分,一个是你自己提供的接口的请求量,一部分是你所依赖接口的请求量

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

image.png
请求量一般通过曲线图展示,可以更好的反映出来一个趋势。

  1. 响应量

响应量通常可以和请求量结合使用,如果一个接口正常响应量小于请求量,那么说明有一部分的请求是存在问题的。
image.png

  1. 耗时

接口耗时主要用来监控接口性能,同样包括你自己提供的接口的耗时和你所依赖的接口耗时。
image.png

  1. 订单量

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

  1. 响应状态

响应状态是一个很好的监控指标,它能够很好的反映我们程序的处理结果。响应状态比较适合用饼图来展示。可以很好的反映出各种状态的占比。
image.png

  1. 异常状态

同响应状态一样,异常状态的监控也具有很重要的意义。同时异常状态也是我们用户告警的重要指标之一,他可以很直观的反映出我们系统的健康状态,异常状态可以用饼图,也可以用曲线图来展示。

  1. 页面之间转化率

页面之间转化率不仅仅是用户衡量产品价值的指标,同样是我们系统监控的重要指标,如果从一个页面到另一个页面的转化率突然降低,那么极有可能是这之间出现了什么问题。

  1. 其它

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

4 告警策略

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

  1. 阈值

我们可以对请求量、订单量、异常量设定一个阈值,当每分钟每小时请求量下降到某个阈值,或者异常量达到某个阈值的时候,触发我们的告警。

  1. 环比

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

  1. 同比

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

5 监控成果

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

posted @ 2021-01-13 08:16  随心所于  阅读(5106)  评论(29编辑  收藏  举报