货拉拉智能监控实践：如何解决多云架构下的故障应急问题？

原创货拉拉柯圣 TakinTalks稳定性社区

# 一分钟精华速览 #

在月活超千万的大规模业务背景下，货拉拉遭遇了多云环境下的监控碎片化、规划无序等问题。为了应对这些挑战，货拉拉开发了一站式监控平台——Monitor。该平台的部署有效地实现了对核心应用的监控和报警全覆盖，显著提高了应急响应的效率：超过72%的云应急事件能在5分钟内被识别和处理，同时，接近80%的事件能在1分钟内被检测到，并有近70%的事件在5分钟内得到准确定位。详细的解决策略和方法，请参阅文章正文。

作者介绍

货拉拉监控平台负责人——柯圣

TakinTalks 稳定性社区专家团成员，货拉拉监控平台负责人。曾任职于携程、饿了么的核心中间件团队，深入参与多个自研日志平台、监控平台、时序数据库等系統的研发，深耕可观测性领域近 10 年。目前在货拉拉技术中心负责整体监控体系与监控平台建设。

温馨提醒：本文约7500字，预计花费12分钟阅读。

后台回复 “交流” 进入读者交流群；回复“1221”获取课件；

背景

在我加入货拉拉的技术团队之前，货拉拉已经使用开源的监控产品搭建了初步的监控体系。例如，使用 Prometheus 用于数据的采集和存储，用 Elasticsearch 用于日志的查询与存储，以及基于 SkyWalking 上报链路数据。然而，即使这些开源产品在各自的领域都非常成熟和被广泛使用，但对于我们的研发团队而言，他们在排查问题、查看应用、分析日志时，都需要在各个平台之间不断切换。这样的监控体系给他们带来了强烈的割裂感，使得监控体验相当糟糕。

此外，这些监控产品的维护工作一直由运维团队负责，但对他们来说，监控只是他们众多职责中的一小部分。因此他们并没有足够的动力去做公司的定制化需求，或者与我们内部的系统进行整合。这使得监控平台的发展举步维艰，前景迷茫。

业务诉求

货拉拉的服务已拓展至国内超过 360 个城市，拥有超过 90 万月活跃司机和逾 1000 万月活跃用户，技术研发团队规模超过 1000 人。作为同城物流行业的领头羊，我们迫切需要一个能够支撑大规模业务的监控平台，以确保业务的连续性和稳定性。

技术诉求

考虑到货拉拉的底层基础设施部署在多云环境中，包括国内的阿里云、华为云、腾讯云以及国际云服务商如 AWS 和 Azure，我们的监控平台需要具备强大的适配性和足够的灵活性。它应能够消除不同云服务间的差异，确保应用层面的稳定运作，并提供实时、全面的监控数据，随时捕捉业务运行状况。

综上所述，我们需要自研一个一站式的监控平台，这个平台能够适配多云环境，能够提供全面和实时的监控数据，还需要提供良好的用户体验，让研发团队在排查问题时不再感到割裂和困扰。同时，我们也需要一个专门的团队来维护和优化这个监控平台，使它能够更好地服务于我们的研发团队和运维团队。

一、货拉拉一站式监控平台做了哪些设计？

1.1 分析监控系统诉求

面对上述的技术挑战，我们需仔细分析监控平台的建设方向。这张图是我的个人思考。它明确了监控平台的关键业务功能、目标定位及必需的数据要素，并展示了如何利用这些要素服务于用户和公司团队。我们的设计目标是确保平台能够满足特定的性能要求，从而提升服务质量。

监控系统的业务功能主要包括：收集全面的应用数据，提供实时报警通知以快速介入处理问题，保障应用的连续运行。它还承担着 7x24 小时的值守任务，支持日常运营和架构优化。

对于数据要素，我们要关注日志、链路、指标以及事件，尤其是那些与发布和运维相关的关键事件，对于紧急响应和报警至关重要。

用户群体方面，研发和运维团队是监控系统的主要用户。其次是安全生产团队，他们依靠监控数据快速定位和处理问题。稳定性团队则依赖于关键应用的监控数据或核心业务数据实现全天候监控。同时，管理层对稳定性和应用统计数据也十分关心，他们需要信心来确认公司的业务在正常运作。

监控系统的性能要求是及时性、准确性、高效率，并且能够支持自动化的触发策略和报警降噪功能。配置和报警规则必须具备灵活性和动态扩展性，以应对多变的故障场景。此外，监控数据的开放性对于整个技术中心都是必要的，以便其他系统将监控集成入内部系统，实现监控对业务的支持力度。

为此，我们成立了专门的监控团队，招募资深人才，专注于监控产品与平台的开发，目标就是消除研发团队在多个系统间切换的不便，提供最好的用户体验。

1.2 监控平台 Monitor 概览

货拉拉的智能监控平台我们称之为 Monitor。历经一年多的开发，Monitor 就已具备丰富的功能：提供了从应用和中间件到端上数据的全面指标监控；链路监控方面，我们采用了 SkyWalking 作为基础，精准采集关键业务数据；日志监控不仅涵盖了应用日志、访问日志以及容器日志，还引进了秒级日志处理技术，实现了指标数据、报警和看板的无缝对接。

Monitor 的报警系统采用了灵活的通用报警规则和动态阈值算法，支持通过电话、短信、飞书邮件等多种渠道进行报警通知，保证信息的及时传递。报警分发系统可以精确地绑定到指定的团队、应用负责人或者研发部门，确保信息准确送达。云平台的报警功能我将在本文后半部分详细介绍。

作为一站式平台，Monitor 提供了统一的用户界面，将链路、指标和日志数据集成于一体，用户可以在同一平台上关联查询和跳转，极大提高了工作效率。平台还包括了报警配置和运营看板等功能，进一步优化了用户体验。

为了满足移动办公的需求，我们还开发了移动端应用并集成到飞书中，使得研发人员在任何地点都可以通过手机迅速获取应用状态，进行初步诊断，指导应急人员响应或验证业务变动。

Monitor 监控平台还提供了稳定的开放数据服务，确保了与兄弟团队和其他系统的高效协同工作。

（实际上 NOC 团队无需 7x24 小时盯屏，现在只需要关注报警提示即可）

（支持通过拓扑视图清晰查看完整的业务调用链）

（支持研发人员仅需点选就能快速设定报警规则，涵盖预设值和算法）

1.3 Monitor 核心功能详解

下面，我将详细介绍如何通过 Monitor 的核心功能有效解决故障排查场景。

以接收报警为例，一旦触发了配置的报警，用户会立刻收到一个包含交互按钮的飞书通知卡片。用户可以通过交互按钮确认收到或正在处理报警，系统将自动暂停后续通知一段设定时间，自动进入静默模式。

如果是故障隐患或系统冒烟等紧急情况时，用户同样只需点击按钮，我们的自动化应急流程就开始启动。具体流程是应急系统会立刻集结相关业务团队和核心应用负责人进入一个新建的讨论组，迅速开展线上故障的紧急处理。如果是不太严重的报警，用户或许会选择单独处理，例如他会直接跳转至应用监控仪表板，进一步分析异常上升的原因。插一句，得益于我们出色的 Java 中间件团队，一旦接入我们的货拉拉自研的中间件，所有类似 HTTP、SOA、DB、Redis 请求等操作都会自动上报相关链路和指标数据。

在应用监控仪表板上，用户可以查看相关的指标和曲线图，只要点击异常曲线，即可查询到对应时间点的链路采样数据。这些数据能帮助用户初步判断故障可能源自链路的哪一部分。我们 Java 中间件在记录日志时已经默认加入了 TraceID，用户可以方便地利用 TraceID 通过快捷链接跳转到详细的日志信息，从而深入分析链路错误和异常升高的根本原因，有效地解决问题。

以上是 Monitor 在应用监控方面一个标准的使用流程。

1.4 Monitor 系统架构简述

接下来，我简要介绍一下 Monitor 监控平台的系统架构。在架构的数据层，我们采用了基于 Prometheus 生态的开源产品进行指标数据的收集。我们的应用程序会自动向 Prometheus 上报数据，而 Prometheus 则负责采集这些指标信息。此外，我们开发了一个被称为“Transformation”的组件，其目的是为了优化和精简指标数据的采集。为了增强指标数据的集群可用性，我们还开发了一系列 API 服务，以方便对这些指标数据进行查询。

在中间的链路层，我们利用了基于 SkyWalking 的 SDK 来自动实现链路打点和数据上报，其中上报的数据将由我们开发的一套系统进行消费和处理。

对于业务日志方面，非结构化的日志将被写入 Elasticsearch（ES）。从今年上半年开始，我们将结构化的日志（如，Nginx 的访问日志）存储到 Clickhouse 中，这样能与我们的指标看板更加紧密的整合。同时，我们也开发了专门的日志查询 API，便于执行日志数据的搜索和查询工作。

在用户交互层面，即用户可见的各种页面和前端交互，这些都依赖于后端 API 的数据支持来完成查询与分析操作。我们的报警系统也使用这些 API 来进行数据分析，并且我们通过 API 向外提供监控数据的访问。

以上针对监控架构的介绍相对简略，但它概括了 Monitor 系统从数据收集到用户界面的整个工作流程。

二、多云架构下，怎么做好云产品的监控？

在融合了多种云服务提供商的多云架构中，有效地监控云产品至关重要。面对云服务，我们必须正视一个问题：云服务真的可靠吗？实际情况告诉我们，云服务提供商的故障时有发生：

2023 年 11 月 12 日，阿里云经历了一次故障，影响了钉钉、语雀等服务。
2023 年 6 月 6 日，微软的服务遭遇中断，Outlook、Teams、OneDrive 等服务均受到影响。
2023 年 2 月 7 日，Azure 东南亚数据中心的一个可用区因冷却系统故障而影响了新加坡的多个机构。
2022 年 12 月 18 日，阿里云香港区域的一处机房冷却系统失效，导致港澳地区多个政府和企业业务中断。

即便云服务商承诺了高水平的服务级别协议（SLA），然而一旦云平台发生故障，对于那些业务重心依赖于云的企业而言，后果可能是灾难级别的。

对货拉拉而言，我们采用了华为云、腾讯云、阿里云等多个云厂商的服务，形成了多云架构。我们对云产品，如 ECS、ACK 集群或 SLB 负载均衡等服务有着深度的依赖性，它们性能的任何波动都可能对我们的核心业务造成显著影响。在应急响应方面，我们也曾遭遇过云厂商处理效率不尽如人意的情况。例如，故障报告的流程曾需要在他们的平台上提交工单，并且与云服务提供商进行多轮来回沟通。虽然现在我们能够获得专属的技术服务经理（TAM）的支持，但云服务商的内部运作机制对我们来说依旧如同黑盒。

不论是单一云服务还是采用多云架构，如何提升云服务的可靠性始终是一个热门话题。这可能牵涉到架构设计演进，如实行多云多活策略、定期开展灾难恢复演练，或是强化技术文化等等关键步骤。但关键在于，我们不能对云服务有不切实际的期待--期待“云总是可用”。这些观念的改变都需要从更高层次的架构出发，或是公司战略层面来进行深思熟虑地决策变革。

2.1 云监控体系建设整体策略

建立云的监控体系时，监控团队需要首先保证云产品能够被有效监控。这项工作虽然单调，但却是保障云服务运行的基石，主要包括数据采集、看板配置和报警设置三大环节。

数据采集环节尤为复杂，每个云服务商提供的产品 API、数据格式和限制都不尽相同。我们必须细心且耐心地采集每一项指标，确保它们能够被正确地存储至 Prometheus。一旦数据采集完毕，接下来便是根据产品类型配置相应的数据看板。随后，我们为这些指标配置报警规则，并将报警通知发送给负责不同云产品的各个团队，比如运维团队或安全团队。

经过半年的不懈努力，我们的监控范围已经扩展至五大云服务商，包括了 23 个云产品的监控，并配置了超过 70 条报警规则。简而言之，我们把不透明的云环境变得清晰可控。有时，我们甚至能在云服务商自身察觉之前，先行发现如网络波动等问题，云服务供应商对我们的反应速度也会感到意外。因此，在采用云服务前，建立完善的云监控体系是首要任务。

2.2 多云架构下的监控平台特色能力

在多云架构环境下，打造一个既统一又丰富的云监控体系是一项挑战。我们需要在保障有效监控云产品的同时，应对构建过程中的复杂性和困难。

货拉拉的报警系统具备强大的报警处理能力，每天运行着大约一万四千个报警规则。然而，这也引出了一个难题：报警规则的增加可能导致触发的报警数量激增。报警数量的增多不仅会增加研发和运维团队的负担，而且还可能降低报警的实际效用，导致整体的报警能力受损。

因此，在构建报警体系时，我们的目标不仅是增加报警规则的种类，更重要的是要减少误报，提高报警的精准度，通过进一步的分析和智能算法的集成，帮助研发团队快速定位并解决问题。我们将持续深入这些关键议题，以确保我们的报警体系既高效又准确。

2.2.1 事件报警功能

背景：

在多云架构背景下，落地一个既有效又可靠的事件报警系统是一个关键且充满挑战的任务。举例来说，对于运维团队而言，他们需要从不同云平台推送的海量且多样化的告警信息中迅速识别出关键事件。例如，从阿里云到 AWS，我们面对的报警信息的形式变化多端，有的通知甚至像一篇英文小说一样，要从中提炼出核心信息颇不容易。

难点：

自动化处理这些不同来源的云告警和运维事件存在显著难度。尽管可以通过硬编码规则或手动在飞书群和钉钉应用中解析及转发告警信息，但这些方法效率低下，且容易出错。随着云服务的增加，这种方法的低效率和错误率只会进一步加剧。

解决方案：

为了应对这些挑战，我们的监控团队开发了一种新的事件报警框架。

在此框架之前，我们可能会设置一个 Webhook 直接将阿里云的告警信息推送至飞书。现在，我们引入了后端处理的事件报警机制，这不仅能复用现有报警平台的各项功能，还拓展了原有的触达方式，增加了如电话、短信或加急通知等渠道。对应的动态分发特性能省去了手动分析和转发步骤，报警平台会自动集成 API 来执行相关操作。此外，我们的报警升级机制能在事件未被及时处理时，自动通知到应用责任人的上级或管理层。对于值班人员而言，通知现在只会发送给当前值班的运维人员，而非全体成员。

当接收到 Webhook 推送时，我们利用基于 Go 语言的 text/template 库实现了一套动态事件报警规则。例如，如果我们只关注 AWS RDS 的特定指标，我们只需配置相应的规则，这个规则就会自动过滤符合条件的云事件再触发报警。为了从繁杂的信息中提取关键数据，模板库能够帮助我们筛选出重要字段，并以 Markdown 格式清晰地展示，使得信息的呈现更为直观。我们还集成了自定义函数，比如根据资源标识符定位 App ID，进一步提高事件推送的精确度。

落地效果：

这一机制的推广实施大幅提升了云报警和运维事件处理的集成度和效率。它不仅明确了处理流程，还为未来新的云厂商或云产品的集成提供了便利。运维团队只需简单地在用户界面上新增或更新规则，就能快速应对新情况，显著降低了手动维护的工作量和时间成本。

2.2.2 应用报警模板

在 Monitor 中，应用报警模板的功能至关重要。该功能是在前文提到的货拉拉自研的 Java 框架的基础上（接入了货拉拉所有的核心应用），实现了对所有核心应用的监控 100% 覆盖。对于报警这一环节，我们通过精心配置的大量通用报警规则同样实现了全方位的监控。我们细化并配置了大约 180 项报警规则，这些规则覆盖了各式服务与资源，包括但不限于 HTTP、SOA、JVM，以及 SLB 流量、ECS 实例、CPU 使用率、磁盘使用率等关键性能指标。

这一系列通用报警规则设计能够与所有中间件及基础设施组件自动对接。一旦触发报警，系统便能够根据 IP 信息快速查询到对应的 App ID，并将通知直接发送至该 App ID 的负责人。这种报警模板机制的一大优势在于其默认的激活状态，这意味着即使是新部署的应用，也能自动被纳入监控体系中，无需手动设置。

由此，这套高效的监控与报警体系极大地减轻了开发人员的负担。他们可以专注于产品测试和业务开发，而在监控和报警维护方面几乎无需投入额外精力，这都得益于货拉拉中间件自动进行数据上报和报警模板的自动配置与运行。

2.2.3 发布检测功能

背景：

由于我们的业务高峰通常出现在白天，因此发布操作往往安排在晚间。这样的安排虽然减少了对日常运营的干扰，但不可避免地带来了一个问题：开发人员在完成夜间发布后，往往会忘记对监控数据进行仔细检查，从而可能会造成潜在的故障或隐患。

解决方案：

为了避免这种情况，我们专门开发了发布检测功能。一旦发布操作完成，系统便会立刻自动运行一系列检查流程，包括流量变化、数据库读写状态、响应时间（RT）波动，以及异常和错误率的激增等关键指标，并且会对 CPU 和内存使用情况进行异常监控。特别是，如果检测到类似 Error 或 Exception 日志数量的异常增加，报警平台同样会进行报警。目前，我们已经实现了 41 项相关的检查规则。

如上图右侧的消息卡片示例，这里的某 App ID 完成了发布，借助曲线图就可以清楚看到异常指标的立即上升。此时，系统会立即通知该 App ID 的负责人员。这样一来，负责人就无需手动检查每个应用的监控大盘了。有了这样的报警机制，开发人员可以快速地采取措施，如回滚或其他必要的补救操作，以防止问题进一步扩大。

落地效果：

发布检测功能自上线以来，整体准确率已超过 70%，并且成功发出了 300 多次有效预警。

2.2.4 人工降噪

去年，我们专注于优化人工降噪流程。采取的一项措施是，一旦某人接收并确认了报警（ACK），系统就会记录上报警已开始处理，并停止关于该报警时事件的后续通知。这个确认过程可以简单地通过消息卡片中的按钮实现。用户能通过选项将报警临时静音，比如延迟一小时或六小时，以便有时间解决问题。

我们还引入了另一项提升用户体验的功能：当用户在飞书群中直接回应报警时，系统将此视为开始处理报警，之后中断后续通知，减少对研发的干扰。这些工作流程的改进大约降低了 45%的报警通知数量。

此外，我们还开发了一个报警大盘。因为随着报警规则的不断增加，用户往往不清楚哪些报警正在不停触发。有了报警大盘，用户可以清晰地看到触发中的报警，并以此去调整报警规则或进行相应处理，这进一步减少了大约 30%的报警数量。

落地效果：

综合这些优化后，我们成功减少了 61.5%的报警数量，显著提升了研发的报警体验。

2.2.5 自动降噪

背景：

单一故障点可能会激发一连串的报警风暴。以一台宿主机宕机为例，这类事件会即刻引发心跳丢失警报，并可能影响多个容器实例，进而触发一系列关联警报，如服务不可达或 App ID 访问异常。这样一来，原本一个事件，最终会发出数十条报警消息。

解决方案：

去年，我们为解决这一挑战投入了大量精力，开发了一种智能合并策略。

我们注意到，这些报警往往存在共同特征，例如相同的 App ID 或 IP 地址。以前这些报警会以多条消息的形式发送，现在我们通过自动合并机制，能够把它们整合在同一个报警卡片中。比如，一旦检测到心跳服务故障，我们就会停止发送重复通知，转而通过合并相关报警消息来提供更清晰的总体情况。这种方法的优势在于，它使得用户意识到问题可能不局限于单一应用，而是源自更深层次的基础设施故障。

报警系统的特色功能和工具还有很多想和大家分享讨论，但鉴于篇幅限制，这里无法一一详述。

落地效果：

这样的策略在平时可以减少约 20%的报警数量，在报警风暴时则能减少大约 58%。总的来说，我们降噪的效果能够将报警数量减少到只有三分之一，也就是 30.8%。

三、总结与展望

3.1 应用情况概览

3.2 稳定性成果总结

在监控领域，我们达成了全面监控核心应用的目标，实现了 100%的监控覆盖率。2023 年，我们共处理了 18 起由云产品引发的应急事件，其中大多数在 5 分钟内被发现并响应，体现了我们在云产品监控上的有效性。当然，这一数据仍有提升空间。

在应急响应能力上，我们把标准提升至“一分钟发现，五分钟定位，十分钟止损”。今年共记录到 21 起冒烟事件，主要涉及非核心业务链路，我们在 79%的事件中做到了 1 分钟内发现，在 69%的事件中实现了 5 分钟内定位，42%的事件在 10 分钟内采取了有效止损措施。数据反映出我们在应急管理方面的成长，稳定性指标的年终趋势图清晰展示了我们在这一年的持续进步。

3.3 监控平台展望

货拉拉监控平台已经从初始的手动操作进化到现今的自动化和智能化。如果谈及未来的展望，我希望能够将 AI 技术融入到货拉拉监控平台中，使其成为我们平台的一个代名词，AIOps 是我们建设监控平台的下一个方向。（全文完）