微服务之监控初探

作者简介

刘伟伟    百度高级研发工程师

负责百度智能运维产品（Noah）监控平台的设计和研发工作，在系统监控、业务监控等方向有广泛的实践经验。

多年之后，这名少年站在无数聚光灯前，准会想起那个遥远的下午。

这天，少年所要接手的系统是公司最新研发的某金融类产品，摆在面前的是一张画满了各种形状和符号的A4图纸，顺着箭头的方向，他依次看到了“服务注册”、“服务发现”、“负载均衡”以及“服务网关”等熟悉的词汇，同时纸张的主要位置整齐地画满了相互独立的方格，用交错的线条连接，这不由得让他想起校招面试中默写Dijkstra算法求解最短路径的画面。少年摇头会心一笑，定下了心神，开始仔细地端详这张图。

他知道，这是一张“微服务”的系统架构图。

他不知道，一道不眠之门，即将向他敞开。

那些年的系统架构经历了几代的发展，终于来到“微服务”时代。谈论“微服务架构”似乎成为了架构师们永远不会过时的话题，相对于以往的“单体架构”和“SOA架构”，人们总是毫不吝啬地一遍又一遍赞美着它的优点：

• 可以更细粒度拆分服务，各服务职责单一，降低系统复杂性，且易于开发和理解

• 可以更加精准的制定每个服务的优化方案，提高系统可维护性

• 可以根据需要对每个服务独立扩展，提高部署灵活性

• 适用于互联网时代，产品迭代周期更短

讨论的热潮方兴未艾，少年也在此时遵循着先进的架构理念，投入了紧张地迭代研发过程中。四个月过去了，伴随着明确的团队分工、精准的模块划分，该产品的各项功能逐渐完善起来，DAU也随着运营的深入推广一步步上涨。正当大家欢呼雀跃的时候，少年却莫名感到了一种前所未有的压力。

眼前的系统架构图纸已经从A4变为了A2，除了更详细的文字和符号标注之外，最明显的区别就是代表模块的方格数量已经从17个涨到了103个，面对着不断增长的模块数量，少年握拳托住了略微沉重的额头，思考着当前系统在“微服务架构”下已经面临的运维问题。故障处理是运维的重要工作，故障首先要发现和诊断才能进行止损和恢复。故障发现和诊断依赖监控系统，这个A2图纸所有模块都要进行监控管理确实是一个大工程：

• 监控配置的维护成本高：尽管职责单一，但是每个模块仍需添加完备的可用性监控，比如进程监控、端口监控、异常监控等，针对每项数据指标，还需添加不同阈值的异常检测。

• 报警误报率较高：常规报警功能基本为恒定阈值，较为复杂的还有同环比检测，但面对模块众多的微服务架构，如何针对不同特征的指标配置较为准确的检测阈值，不仅严重依赖人工经验，而且随着模块的频繁变更，指标的检测阈值也会变化，维护成本极高。

• 缺少全局故障诊断大盘：面对海量数据，如何迅速提取有效信息进行全局故障诊断，明确故障的范围，涉及的模块，找到故障触发的诱因和根因，进一步缩短服务止损和服务恢复的时间。

“叮——！”

短信提醒声刺耳地想起，手机上又出现了几十条未读的报警短信，少年简单翻看了下，并未从五花八门的异常列表中快速找到问题所在，如往常一样，他翻起身熟练地打开电脑，开始细致的查看每一条报警内容......

二十分钟后，少年揉了揉发胀的额头，盯着刚刚恢复正常的系统，睡意又漫出了双眼，恍惚中仿佛听到拥挤的报警短信仍在手机上咧嘴叫嚣。他不由深吸一口气，决定先将睡意强行赶到一边，“工欲善其事必先利其器”，如果微服务架构是一个高效运行的漆黑车间，那么少年此时就像点着一根火柴在检修设备，不仅效率极低，而且始终不得车间全貌。

他要寻找一道光，照亮车间，照亮微服务。

少年突然意识到一套高效的监控方法能够极大地降低运维微服务系统的人力成本，这样才能解放精力投身到更多的设计和研发工作。正好近日楼上监控小组的伙伴们送来一本监控书籍，不妨看看再说。

面对一套完整的微服务架构系统，是否具有完备的全栈监控能力至关重要。

少年根据指引细细回想了一遍自己曾在系统上零零散散加过的所有指标，总结出了如下分类：

通过以上分析，首先需要制定一套在微服务监控场景下完备的、可真实反映服务状态的监控标准。接入的微服务框架的服务，通过满足该监控标准，即可实现对微服务的全栈监控。

当标准产生之后，我们引入监控模板的这一工具，通过监控模板的预置的监控配置，实现监控标准中所要求的监控采集、报警、通告配置快速地应用到每一个微服务模块中。当监控标准升级时，仅需修改监控模板中的指标采集方式、报警阈值和通告配置，即可对所有模块的监控生效，使配置监控的流程更加清晰、简单。

监控指标虽然有了，但是如何有效判定数据异常，也是一件让人头痛的事情。

不同业务的监控指标特征各异，根据数据波动的情况，有平稳数据、周期性波动数据和非周期性波动数据三类，传统固定阈值类算法并不能适用于所有类型业务指标的监控场景，需要针对不同的数据特征选择采用突升突降类检测算法和同比类检测算法，但如上文所述，在微服务架构下，成千上万的业务指标给策略选择和参数配置带来了很大的困难。

针对这些问题，百度Noah监控平台在研发了针对不同特征数据的智能异常检测算法后，推出了参数智能配置算法展开。

对于微服务架构系统而言，即使每个模块仅添加少数几个核心指标的监控，上百个模块的指标总量也会达到千甚至万级别，在此场景下，如何合理地实现指标分级关联展示，对于服务状态全景掌握至关重要。在百度Noah监控平台中，仪表盘服务为全局掌控微服务状态，提供了解决方案。为微服务场景量身定制的仪表盘展示界面，有助于更加便捷、快速的进行故障定位和模块数据分析。

首先，需要一个覆盖所有模块黄金指标（流量、平响、可用性）的全局性报表，可以快速概览所有模块的实时状态以及同环比指标上下浮动的情况。

其次，对于每个模块，还会单独自动生成核心指标的历史趋势图，以及天、周同比数据。上文中提到的微服务监控多维度特性在仪表盘中也可得到充分的展示。如下图展示了平响、超时数据的分机房、分平台波动趋势，以及模块内按照接口维度展开的监控详情数据。

此外，除了仪表盘关联分析视图，百度Noah监控平台更进一步地研发了黄金指标自动排查算法，上文中所有模块已统一采集了平响、流量等黄金指标，当故障发生时，黄金指标排查模块可从数百个接口的数千个指标中排查根因指标，经过异常检测、聚类和排序等处理流程，最后根据模块的异常实例个数、异常分布和异常严重程度进行根因推荐，快速定位故障根因所在。

如在以下产品中，运维同学在某时刻收到了核心可用性报警，开始查看仪表盘，确认故障，同时启动黄金指标排查。

黄金指标排查模块在排查根因后，推荐了3个疑似根因接口并按照异常程度排序，生成如下推荐结果页，大大加快了根因定位速度。

看完这些，少年合上书，沉思了10秒中......

一周之后，少年坐在工位前构思着最新的设计，手机放在尚有余温的咖啡旁边，安静的让他还是不太习惯。对比前几个月被漫天的报警从半夜吵醒，被繁琐的故障定位绕的头昏脑胀，如今的他只需简单地打开几个页面，即可有效洞察整个系统的运行状态，心中不由安稳了一些。

而那张由A4变为A2的系统架构图纸，在阳光的照射下多了几行简单而有效的运维备注：

• 所有模块全量核心监控自动生效，无需人工配置

• 核心指标自动匹配检测算法、参数，提升故障发现召回率和准确率

• 海量数据分级展示仪表盘自动生成，系统运行状态一目了然