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

若是第二次看到个人文章，欢迎关注个人我的原创公众号「跨界架构师」哦～

每周五11：45 按时送达。 固然了，也会时不时加个餐～

这篇是「分布式系统理论」系列的第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，我的微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。本文首发于公众号：「 跨界架构师」（ID：Zachary_ZF）。 <-- 点击后阅读热门文章
按期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。

若是你是初级程序员，想提高但不知道如何下手。又或者作程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注个人公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思惟导图。

若是你是运营，面对不断变化的市场一筹莫展。又或者想了解主流的运营策略，以丰富本身的“仓库”。欢迎关注个人公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思惟导图。