01 监控：如何从业务视角出发添加监控？

你好，我是白园。今天我们就正式开启服务可靠性保障之旅。

可靠性建设是一项系统性的工程，其中包括六个关键组成部分，分别是监控、容量、变更、预案、备份，还有机制。首先，监控为可靠性提供信息支撑，是一切保障手段的基础。所以这节课，我们就来聊一下监控， 带你从业务视角出发，建立完善的监控体系。

为什么我们选择业务视角去添加监控呢？因为可靠性的最终落脚点，就是为用户提供可靠、稳定的服务， 业务视角是最贴近用户体验的视角。这就是我们选择业务视角添加监控的原因。

接下来我们看一下具体怎么做。我会结合我的经历，把我最有感触的经验、教训分享给你。

在故障中完善监控系统

在开篇的时候我就提到过，我在百度负责的就是网盘可靠性维护的工作。在刚开始接手的时候，线索很多，无从下手，而监控也就成了当时我工作的一个重要抓手。所以这里我就以我当时所做的事情为例来说说如何为业务添加监控。

这第一步就是整合信息，完善监控。当时我看了很多业务相关的文档，我发现很大的问题就是，监控的数据都是来自不同的渠道/团队，比如A同学有自己的一部分，B同学有自己的一部分，缺乏一个全局视角，获取信息以及收集信息很不方便。所以我建立了一个信息门户，把团队手中的监控数据和相关信息汇总了起来，极大提升了监控信息获取的效率。同时在整理的过程中，我发现了很多遗漏的监控点和报警设置，我们迅速行动，把遗漏的监控点进行了完善。

但只有这一步，还远远不够，后面网盘业务也陆续出现了一些故障，而我们的监控系统也在不断出现的故障中慢慢完善了。我们来看一下当时出现的几个关键故障和应对手段。

第一个故障就是一个新上线的核心功能，因为上线比较着急，前期相关的监控没有被纳入到监控体系里，导致故障没能及时被发现。这次的故障，让我们对所有功能的监控进行了 彻底地复查和补充。同时也让我意识到监控一定要保证能发现问题。
第二个故障是某个地区的IP被封禁，但由于那个地区用户流量比较小，一开始对整体的流量影响并不是很明显，所以故障没能及时被监测到，等故障后续被发现的时候已经过去了很长时间。这次故障之后，我们就进一步 细化了关键指标，把监控拆分到了各个子领域，后续有问题就通过子领域的曲线变化迅速发现问题了。这次故障让我明白监控的第二层级是能快速发现问题。
第三个故障是网盘依赖的一个下游服务出现故障，前期没有进行充分的梳理，当故障发生的时候，无法及时定位，导致定位问题的时间过长。为此，我们梳理了核心链路，在关键上下游节点增加了监控。这次故障让我明白监控的第三层级是能快速定位问题。
第四次故障是机房故障，非常严重，故障发生的时候同步而来的是大量的报警。面对大量的报警信息，我们没办法及时提取关键信息来做出判断，所以也就没办法迅速评估故障的影响，无法 快速决策。 这次故障让我明白监控的第四个层级是能快速做出影响评估，为决策提供有效的信息支撑。

从这些故障中，我们其实就可以看到优秀监控体系应具备四个能力。

能发现异常：也就是要保障监控的召回率，监控体系首先要保障一定能发现异常，如果监控无法发现异常一切都没有意义。
快速发现异常：也就是要保障监控的时效性，监控和报警的响应速度直接影响故障的恢复速度。好的监控一定要保证快速发现问题。
快速定位问题：在快速发现问题的基础上，优秀的监控体系还应该能迅速定位问题的根源。不仅仅是识别问题，更重要的是能够指出问题的具体位置。
给出影响评估：对于大规模故障，监控体系不仅要能发现和定位问题，还应能提供准确的影响评估。这有助于决策者快速了解故障对业务的影响范围，从而制定相应的应对策略。

案例：如何为网盘业务添加监控？

具体怎么做呢？大原则就是 要从业务需要出发，从解决问题出发。 接下来我会以网盘业务为例，介绍一下怎么添加监控。

统一监控门户

当面对复杂局面的时候，我建议你先进行一次全面的监控整理。这个过程本质上是 从混沌走向有序的转变。监控数据分散在不同的地方，你把它们集中起来进行分类，往往能激发新的灵感。

以网盘业务为例，我们把涉及的所有监控按照不同的板块进行划分，每个版本可以以超链接的方式跳转到不同的地方。在这里我们划分为六个板块。

业务指标板块：网盘业务相关的所有指标监控的链接。
网盘的上下游板块：网盘依赖的数据库、Cache等相关监控的链接。
基础设施板块：网盘业务部署的机房、网络等相关监控的链接。
变更板块：网盘所有的变更列表以及上下游的变更列表。
其他板块：容量、压测、预案等相关链接。
业务说明文档：网盘业务的文档说明相关链接。

构建业务监控大盘

业务监控大盘的重要性在于它可以实时且直观地帮助我们去判断当前业务的整体情况。如果大盘稳定就说明这个时候没有大的故障，如果大盘不稳定，说明这个时候已经有故障或者异常出现了。

为了让大盘看上去更清晰，我建议你给每个功能创建一个面板。在设计这些面板的时候，首先需要关注的是请求量，重点关注同环比，我们可以用红色、蓝色和绿色线条表示今天、昨天、上周。其次是成功率、容量、P99响应时间，这里我们只需要关注实时数据就可以了，这样做能够确保监控的时效性，同时也能看到同环比。

这里我展示了网盘最重要的四个指标：上传、下载、列表、登录的请求量。你可以看一下我给出的示意图，我分别用三条线段，表示了今天、昨天还有上周网盘这4个关键指标的变化情况。

进一步细化及拆分核心指标

在第二步中，我们关注整体流量的变化，但没办法捕捉到局部问题，比如刚刚提到的某个地区运营商的流量被封禁。这个时候我们就需要进一步的分解和细化核心指标，在这种情况下，表格可能更适用，因为它们能够更清晰地展示具体的细节。你可以看一下表格，我们通过类比，能够发现北京地区移动的趋势跟电信、联通明显不一致。

梳理和细化核心链路

我们需要做的一个事情就是，寻找业务请求的主干和支流。主干就是核心节点和核心链路，支路就是一些非核心的调用和服务。

还是拿网盘上传来说，我们需要把对业务的理解，抽象出一个最小的链路，当出现问题的时候，可以第一时间定位到出问题的地方。比如我给出的示意图，请求从客户端到LVS到nginx，再到应用服务A1->B1->C1，是主要节点和主要链路，B2、B3等是支路。

注：LVS 四层接入，nginx七层接入，A1、B1、C1为调用链路里面的关键服务。

主干监控

A1->B1->C1 这条链路，首先我们需要关注的是流量。如果主干流量正常，那么潜在的问题相对容易控制。相反，如果主干流量出现异常，问题就非常严重了，因为主干上的服务一般情况下是不可以降级的，一旦降级整体的效果就会有严重的影响。而支流上的服务是可以降级来恢复的。除了流量，主干上还需要关注容量、请求成功率、P99等等实时指标。

这里我也给出了一张示意图，通过图片可以看到，A1->B1->C1 这一条主要链路的请求量、调用的成功率、可用性，还有延迟情况，此外，你也可以根据你们业务的情况，把CPU利用率、内存使用情况等也监控起来。

支流监控

而对于支流的监控，考虑到成本，我们可以不监控它的流量，只加上可用性、延迟、利用率三个指标的实时情况就可以了，你可以看一下示意图，这里Ax、Bx、Cx、Dx代表不同层次的节点集合。这里可能你会问，为什么支流监控不包括流量监控呢？

其实，也可以监控流量，不过成本会很高，也会大大增加监控的复杂度，而发现问题的概率并没有质的提升。所以不监控支流的流量，是在发现问题的概率，和监控的复杂度之间做出的权衡。

统一添加基础指标

好了，在完成对核心指标和关键链路的监控后，我们需要给非核心指标和非核心的服务添加监控。这一步的目的，是确保监控体系没有遗漏任何重要的环节。所以这一步就需要一并去关注和添加服务状态监控、基础指标汇总、变更信息汇总等等。我们可以创建一个监控仪表盘，集中展示这些非核心指标，我给出了一个示例，你可以参考。

第六步是关键信息的提取、汇总和初步判断

在面对大规模故障的时候，迅速判断影响范围和程度是监控体系的关键能力。这包括识别受影响的功能、性能下降的程度，还有累积的影响时长，同时区分是上游还是下游的问题。为了实现这一点，我们可以从功能、服务和基础设施三个层面进行信息汇总。

还是以网盘服务为例，我们可以这样操作：

功能层面：监控上传下载功能，记录当前流量、同环比、故障开始时间以及累计损失。这能够帮助我们对故障影响做出初步的判断。
服务调用层面：汇总和分析服务调用失败的情况，以便快速定位问题。
基础设施层面：识别故障机器，并分析这些主机是否存在共同特征，比如是否位于同一网络段，从而帮助我们确定故障的根源。

通过这种分层汇总的方法，我们可以有效地监控当前的系统状态，及时响应故障，减少业务影响。

优化监控报警

刚刚我们主要讲了怎么添加监控，所以这里不得不提到另一个关键问题，就是报警优化，可能你之前也遇到过信息爆炸和报警膨胀的问题，那我们可以怎么去优化报警呢？这里我给你几条建议。

报警分级：根据监控的重要性，把报警分成不同的级别。对于关键监控，可以设置更高级别的报警，并通过电话等方式通知相关人员。对于其他比较常规的报警，可以通过电子邮件，或者即时通讯工具来通知。比如网盘业务是这么分级的，核心功能的流量波动是P0，非核心功能流量波动是P1，单机故障或者磁盘上涨是P2。P0报警一般都有电话通知，P1是短信通知，如果P1长时间不处理，会上升为P0。

报警信息合并：把相同或相似的报警信息进行合并，以减少重复报警，我们可以在报警平台里面采取一些报警抑制，比如同一个服务在1分钟内，同时有可用性、延迟、CPU等多个报警，就可以合并成一条；也可以采用top-n报警优化，只展示最严重的前n个报警，帮助团队集中注意力处理最关键的问题。

调整报警阈值：合理设置报警阈值，可以避免因小幅度波动而频繁触发报警。同时，确保报警系统能够捕捉到真正的异常。比如发现很多业务经常抖动1～2分钟就恢复了，这个时候你可以配置为连续3～5分钟异常报警。

报警规则优化：定期审查和优化报警规则，确保它们仍然符合当前的业务需求和系统状态。

报警响应流程：我们应该建立有效的报警响应流程，确保团队能够及时、有效地处理报警。比如设置上升机制，Oncall同学没有接手，上升到leader，如果再没人接手就继续上升，一直上升到部门负责人。

小结

这节课我们学习了如何从业务角度出发去添加监控，还和你分享了监控的四个层次，分别是能否发现异常、能否快速发现异常、能否定位问题、能否给出准确的影响评估。此外还有六个步骤，如果你已经完成了这些操作，现在就可以跟着我再来回顾并检查一遍。

统一监控入口：我们需要打造一个集中的监控平台，把所有监控数据汇总到这里，方便管理和分析。
构建业务大盘： 构建统一的业务大盘可以快速感知当前业务核心指标的整体情况。
核心监控的细分：对于关键指标，我们要确保监控的准确性和及时性。这里我们对核心指标进一步细化到子领域，并添加报警策略。这样我们能够在一分钟内迅速判断核心指标是否存在异常波动。
清晰梳理核心链路：我建议你梳理并关注的核心链路不超过10个，以确保在3分钟内完成问题定位。这不仅有助于快速响应，也能体现工程师对业务的理解能力。
全面的监控指标：我们强调监控指标的全面性，对于任何发现的遗漏都要及时补充，包括功能可用性、服务调用、CPU利用率、硬件故障、变更记录等多个方面。
关键信息的汇总与提取：在监控体系中，我们要注意将关键信息提炼并汇总，以便在大规模故障发生时，能够在1～3分钟内完成信息整合，为快速决策提供支持。

这些策略的目的是构建一个高效、全面且响应迅速的监控体系，以确保业务的稳定运行。

不过想要保障监控的长期可靠，我们日常还需要做一些关键动作。

比如：

日常巡检：定期检查监控体系，确保监控系统正常运行，及时发现并解决问题。
报警响应： 此外还要建立一个有效的报警响应流程，确保报警信息能够迅速被处理。
定期总结：通过日、周总结机制，回顾监控数据，分析系统表现，识别潜在风险。
问题复盘：对于已经发生的问题，进行深入地复盘分析，从中学习经验，优化监控策略。

通过这些机制的持续运作，我们可以不断优化监控体系，提高监控系统可靠性和有效性。更重要的是，监控需要得到团队的持续关注和使用。如果监控被忽视，那么它很快就会失去它应有的价值。因此，确保监控得到适当的维护和更新，是保障它长期运行的关键。

思考题

除了课程中我们提到的办法，你还有什么好的策略来保障核心指标的异常能及时被发现呢？你也可以根据我们这节课添加监控的流程，梳理一下你自己业务线的监控节点和重要指标。

欢迎你把你思考的结果分享到评论区，也欢迎你把这节课的内容分享给其他朋友。我们下节课再见！

欢迎加入课程交流群