分布式系统关注点(22)——360°的全方位监控

如果第二次看到我的文章,欢迎右侧扫码订阅我哟~  👉

每周五早8点 按时送达。当然了,也会时不时加个餐~

 

这篇是「分布式系统理论」系列的第22篇,也是最后一篇。我们来聊聊分布式系统中的最后一道保障——监控。

 

监控这个事情,有点像我们平时对人的健康体检。想要效果好、结果靠谱,就得“全面体检”,每一项都做,否则哪怕检查报告都是正常,也不代表没有问题。下面这个景象是不是很熟悉?

 

运营小姐姐问:现在系统好卡啊。

 

程序员小哥哥答:我这里不卡啊,而且从数据来看很正常。

 

运营小姐姐问:[一张截图],你看一直在加载。

 

程序员小哥哥答:你的本地网络不好吧,打开别的网站试试。

 

 ……

 

监控里的“全面体检”有个高大上的叫法,「立体化监控」。

 

但是,越全面,成本越高。所以,根据所处的时期从中挑选合适的监控方式更加重要。

 

接下去,Z哥来和你一起梳理一下那些有必要做监控的地方。最后再给你一个普适性的建议。

 

 

监控的三个层次

从监控的目标来看,监控可以分为三个层次。分别是「环境指标」、「程序指标」、「业务指标」。

 

 

环境指标

环境指标主要是网络I/O、网络延迟、磁盘I/O、磁盘占用大小、CPU使用率、内存使用率、交换分区等等。

 

它们的目的是观测程序所在的环境,是不是稳定。就好比「水培绿箩」,再怎么好养的植物,你把下面的水煮一会,都得挂。

 

 

做环境指标的监控很简单。Z哥建议你二选一就好了。

 

无脑用的话,就Zabbix吧。非常成熟的企业级监控产品。网上安装教程有很多,随便搜一下就是。

 

如果服务器多的话,将Zabbix打包到进操作系统,做成一个镜像。这样一来,一台新服务器只要是从镜像安装的,就会自动加入到监控中。

 

 

如果愿意折腾,想二次开发的话可以使用小米开源的open-falcon。项目的活跃度还不错,可以了解一下:https://github.com/open-falcon/falcon-plus。

 

虽然功能的丰富度上比Zabbix差一些,但是毕竟是国人的产品,更加符合中国国情。国内有不少互联网企业也在用,或者基于它进行了二次开发,最有名的是美团二次开发的mt-falcon的。如果决定进行二次开发的话,可以借鉴一些mt-falcon在网上的公开信息。

 

 

程序指标

程序指标除了和环境指标一样的CPU使用率、内存使用率这种“外部“表现的指标之外,还有应用程序错误数、应用程序请求量、应用平均响应时间这种”内部“表现的指标。

 

其实做监控的时候有一个痛点,是不是「无侵入」的?

 

因为一旦需要侵入到具体的程序中去编写「埋点」代码,就很麻烦,毕竟涉及到更多的人一起配合嘛,推进更困难。

 

CPU使用率、内存使用率的监控比较简单,可以直接通过shell或者cmd调用系统API获取,和前面的环境指标一样。

 

但对于应用程序错误数、应用程序请求量、应用平均响应时间的监控,这里是一个分水岭,因为这里想要做到「无侵入」的效果,需要做一些额外的工作,否则只能编写大量的“埋点”代码。

 

比如,是不是有一个网关来统一进行流量分发?是不是有一个统一的RPC框架、数据库访问框架等等。如果有这样的统一模块就好办了,直接在这些模块里增加监控功能。

 

 

举个例子,你的rpc框架是统一的,那么只要在每次方法调用前和调用后记录好相应的数据,就可用于后续统计出结果。

 

关于采集到的数据如何存储,主流的选择是将数据写入到一个「时序数据库」中。比如Prometheus,这是一个专门做监控报警的开源框架,在全球都比较火,github上有23K的star。当然你也可以选择其他的时序数据库,如InfluxDB、OpenTSDB之类。

 

再配合以一个可视化框架,比如grafana,将其中的数据展示出来,就完成了整个监控系统的搭建。网上的搭建教程也有很多,就不多说了。

 

 

如果没有统一框架的话,可以优先考虑通过AOP的方式,以此尽量降低埋点代码的编写量。

 

数据采集就在AOP切入的位置进行。

 

 

特别注意一点,由于监控产生的日志数量庞大,不建议直接与远程数据库交互。所以需要借助一些专门的日志采集和传输框架。比如flume、logstash。

 

怎么感觉一下子引入了好多新框架~,没办法,真要做好监控是挺繁琐的。

 

 

业务指标

在典型的程序员思维里,认为业务指标关我什么事。其实恰恰业务指标的监控更加的“有效”。因为业务指标出问题了,说明必然哪出问题了,不会像前面聊的两个层面的指标,可能看着好好的,但是实际业务却出了问题。

 

最近这2年在运营圈里被“爆炒”的「增长黑客」概念,本质上就是通过数据驱动的方式来做运营工作。而这背后依赖的就是一个业务指标监控系统。

 

 

每一个业务会经过的关键状态,都可以作为「业务指标」来监控。但是由于业务指标往往不具有「通用性」,所以,需要手动在程序里「埋点」。

 

因此,对业务指标的监控必然是「侵入性」的。

 

能不能不要埋点?也不是没有办法。

 

如果在一个系统的初期,比如日PV在百万以下的,直接通过业务数据库拉数据也不失为一个取巧的办法。这样就不用写什么埋点代码,简单粗暴。

 

到了成长期,直接拉业务数据库行不通了,因为会对正常的业务处理产生显著的性能影响。不过,此时还可以通过数据库层面做二次分发,将数据实时地复制到一个单独的库中,从这个库拉数据也能“撑”一段时间。

 

当然了,这些办法只能解决一部分问题。如果需要监控的业务指标不存在于业务流转的数据中(比如用户行为数据),那就没办法了,只能老老实实的写「埋点」代码。

 

 

总体来看,这三层指标恰好构成一个金字塔结构。从监控价值来看 业务指标 > 程序指标 > 环境指标。从实施的一个成本来看,也是 业务指标 > 程序指标 > 环境指标。

Z哥给你的普适性建议是,不管怎么样,环境指标先做了,毕竟投入的成本非常小,聊胜于无嘛。

 

其次,先通过直接拉db的方式监控部分重点业务指标

 

然后,再把程序指标监控补充上。

 

最后,再查漏补缺完成所谓的全方位「立体化监控」。

 

 

告警策略

可能你会觉得文章到这里结束了,其实还没,前面主要聊了监控体系的“看”。但是监控体系还有另外一个重点是“叫”。缺少了「告警机制」的监控体系更像是个“面子工程”,实际的用处比较有限。

 

当你的系统还比较小的时候,告警怎么弄都行,哪怕每一次异常都触发告警。但是随着系统的发展,告警次数一多,就麻烦了,完全被“淹没”在了告警信息的”海洋“中,特别是那种专门有个“告警群”的情况下。

 

想象一下,告警群里每分钟都在弹出新的告警,哪怕你有“三头六臂”也处理不过来……

 

所以这里需要引入一个告警策略,使得告警更加的人性化。这个机制的核心就是4点。

 

  1. 梳理不同的告警级别

  2. 制定告警频率以及做好「收敛」(主要是去重、合并数量)

  3. 决定不同的告警级别通过什么形式发出通知(短信、手机通知、邮件等)

  4. 发给谁(比如,是不是需要“轮转”或者“逐级上报”这样)

 

当然了,现在越来越多的大型开发团队开始引入AI来使得告警更加的智能化,但是离我们大多数人所处的工作场景还是有一定距离的,不用急,一步一步来。

 

 

总结

好了,来一起总结一下。

 

这次呢,Z哥主要和你聊了在三个层次上的监控做法,并且给出了个人认为相对平滑的演进路线,供你参考。

 

然后,再聊了下告警策略的制定方式。告警需要更加的人性化,如此才能让人重视。

 

希望对你有所帮助。

 

 

 

 

推荐阅读:

 


 

作者:Zachary

出处:https://zacharyfan.com/archives/759.html

 

如果你喜欢这篇文章,可以点一下右下角的「推荐」。

 

这样可以给我一点反馈。: )

 

谢谢你的举手之劳。

 

既然看到这了,送我一个「赞同」吧,支持我的创作。

想更进一步和我一起玩耍,欢迎「搜索微信公号:跨界架构师」或者在「右侧扫描」。

内容包括:架构设计丨分布式系统丨产品丨运营丨个人深度思考。

posted @ 2019-06-28 09:27  Zachary_Fan  阅读(3081)  评论(4编辑  收藏  举报