一次令人窒息的云事故，逼我们肝出这个智能监控平台……

柯圣 2023-08-23 10:28:00

本文根据柯圣老师在〖2023 Gdevops全球敏捷运维峰会-北京站〗现场演讲内容整理而成。（文末有PPT获取方式，不要错过）

作者介绍

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

大家好，本次分享主题《适配多云环境，货拉拉智能监控平台的设计与实践》主要由三部分组成：

多云架构下的一站式监控平台
服务运维与研发的监控平台
面向未来的监控基础能力

去年2022 Gdevops广州站上，我分享了《货拉拉一站式监控平台从0到1的建设过程》，这次继续把我们做的一些新成果、新经验、新实践分享给大家。

一、多云架构下的一站式监控平台

1、Monitor 监控平台架构

首先，我们来看看货拉拉一站式监控平台 Monitor 的一些数字指标。除了第八个“每日报警信息”外，其他指标和去年相比都翻了一番。

我们采集了指标、链路和日志，并集中展现到同一个监控平台monitor 上。监控场景上，包括我们提供的应用Applications、还包括机器和容器的指标，也有各种中间件（DB、Redis）等相关的数据，还有云产品和网络上的指标数据。

我们的用户既可以在PC电脑上访问到 Monitor，也可以在手机上查看他的指标、处理他的报警。

右侧的第一个大屏，是我们的稳定性团队以前每天7×24小时会时刻盯着一个业务核心大屏（现在都是基于报警做自动化应急，不用人肉盯屏）；下面的应用监控就是一个对应用的典型的监控场景，左侧提供了丰富的异常、HTTP、SOA、核心中间件和机器等相关的指标，我们的研发可以一目了然获取他的应用所有的监控信息。

我们有 14,000 条报警规则在一直在运行，但是去年我们用了很大的精力，来做报警的降噪，所以每天发出的报警信息大约只有 4000 条。我们的研发会更少地被打扰到，而故障真正来临时的关键时刻，他可以及时地做出响应。

再简要说明一下，我们在指标方面是基于 Prometheus 生态，再额外的开发了一个 Transformation 组件，来过滤和增强上报的指标。我们用 Victoriametrics 做持久化存储。

在 Trace 方面，我们是基于 skywalking，用字节码增强的方式，无侵入式地实现了绝大多数开源中间件和内部中间件的 Trace 链路。

在日志方面，我们通过 Filebeat 采集机器上的日志文件，经由我们实现的 LogProxy 组件，将数据过滤和路由分别存储到 Elasticsearch 和 ClickHouse。

在右侧的应用层，我们既支持简单易用的 Monitor UI，也提供 Open API 供第三方系统集成。

2、多云架构下的云监控

上面简要介绍货拉拉一站式监控平台的一些基本情况，现在正式讲讲“多云架构下”，我们做了什么，先从一次事故讲起。

去年四月份一个平静的下午，突然间各种应用的报警像潮水一样涌出来，应用异常、调用超时，再看到前面的NOC大屏我们的核心业务曲线都纷纷掉地，应急流程开始拉群排查。我们的DBA团队发现DB集群很多节点都挂了，感觉像是大面积的机房节点异常。

此时我们联系上了云上厂商的TAM（客户技术经理）进行开工单、云侧排查，确认了是机房内上百个机架的机器全部挂掉。找到云，已经十几分钟过去了。

但是，知道了原因，这样机房级别的底层故障让我们也无力回天，几十分钟过去了，业务掉地，我们基础设施团队已经着手开始将DB数据整体迁移重建的方案了。

所幸，云厂商服务最终恢复，业务也开始回升。但是故障整整持续了整整55分钟。

这个事故给了不仅仅是启示，而是再次打破了我们的幻想。首先，云上资源都会有不可用的可能，架构和高可用时要面向失败设计。所以，后来我们技术中心提出了“多可用区高可用的架构设计”。

对我们监控团队而言，云上的状况一无所知，这是不可接受的。

云上的资源必须监控起来，再难、再复杂也要做。

接下来的工作就简单而枯燥。由于货拉拉业务覆盖全球，使用的云厂商有五家，接下来的工作就是一个个去对接云厂商的云监控。

大概经过了两三个月的建设，我们监控覆盖了5家云厂商，采集了包括SLB、OSS、CDN、高防等23个云产品包，还额外去做了网络可用性探测—如 Smokingping 这样的一些网络之间的监控，还配置了七十多项报警规则。

这样一番操作下来，才真正地把云和他们的云产品都管控的起来，之前是云上出了任何问题都是一抹黑，需要走工单慢慢地等，现在我们是能够提前于云供应商，知道他们出了问题，我们做到把黑盒的云变成了可控的云。

3、业务的秒级监控

去年，我们团队也把监控日志的架构升级到了 2.0 的版本，即实现了成本的减少，也简化了架构，通过设计交互友好的日志查看页面，并且将用户在日志上的使用习惯从 Kibana 转移到 Monitor 上。

特别的是，我们引入了 ClickHouse 存储结构化的日志，采集了 Nginx 的 AccessLog，对请求异常进行了通用监控和报警。

紧接着，新的业务需求就来了。

我们的研发在下单的监控场景，希望把详细的订单数据监控起来。一个订单数据包括车型、下单城市、营销类型等等十多个监控维度，还希望把每次的订单价格也记录下来。

但是基于 Prometheus 的指标监控方案，很快就会面临维度爆炸的存算压力。以前我会说：你这个需求做不了，研发只能悻悻而去。

现在不同了，我们引导研发，将这样的数据单独收集后写入 Clickhouse，就像上右图，可以像 Prometheus 一样集成到 Monitor 上。

配置看板和报警时，也是类似 SQL 式的点选操作。他如果像查看曲线详情，点击曲线就能查看对应的日志全文。

基于日志统计的最大好处，统计数据的时间粒度不再受限于 Prometheus 的采集周期。

我们只需要调整查询 SQL 的 interval 监控，就能展示每秒、甚至每毫秒的业务数据，从而实现业务的秒级监控。

4、全方位的统一监控平台

再讲一个用户使用 Monitor 来处理他的报警的典型流程。

我们的研发大多数在飞书上接收报警卡片，这张卡片上会附带对应报警曲线。

手机上点击它，就能进入移动版 Monitor，研发就可以在地铁上或者通勤的路上查看他应用的详细信息。

当然，真的报警来了，第一时间是确认报警或者组织应急。所以，研发可以直接点击飞书卡片进行报警确认或者拉起一个生产故障应急事件——随后会触发拉人、起故障事件等自动化的应急流程。

当然，触发方式我们提供了电话、短信、飞书加急等方式；为了分担应急的压力，我们开发了值班和排班轮转功能，保证一定能够通知人，通知到正确的人。

报警触发之后，研发如何排查呢？得益于强大的自研中间件体系，产研只要接入一个货拉拉版本的 Spring-Boot，从 HTTP、SOA 到缓存和 DB，再到线程池和 JVM，所有的中间件指标都有，哪里出了问题一目了然。

研发发现指标异常之后，只要点击曲线，就能查看对应请求的 Trace 采样。或者想查看完整的调用链路，我们也提供完整的拓扑展示。

看链路能知道问题大概出在哪段代码，想要查看异常情况，研发同样只需要点击链路视图上的 Log 链接，就能跳转到日志详情。这里同样得益于货拉拉中间件在输出日志时，将 TraceID 默认写在了日志里。

所以，不管是报警处理、故障排除还是日常监控，研发在 Monitor 上一站式地完成他的工作。

二、服务运维与研发的监控平台

通过两年的建设，Monitor 功能已经极其丰富而强大，但是做出来的产品就是用户需要的么？能够解决用户的问题吗？能够通过监控帮助稳定性建设吗？

为了服务好我们的用户，需要从产品设计和用户需求出发，因此我们开发了很多进阶功能。

1、从研发的需求出发

首先是报警。报警除了要报得准、报得少之外，用户实际希望报警无处不在，但是又不想去配置报警规则。

所以，我们开发和配置了 180 多个通用报警规则，覆盖机器、容器、网络、JVM、中间件零零总总各种指标。一旦某个应用有问题，就自动推送到应用的 Owner。

实现了研发的应用可以“裸奔”上线，“身家性命”完全交给监控平台。

当然，光有通用指标自然难以满足业务个性化的监控需求，所以我们对标 Grafana，希望研发能配置出丰富业务指标大盘。

PromQL 不会写，我们开发了类似 SQL 语言的，通过鼠标点选就能配出复杂 PromQL 查询语句的指标编辑页面。

最为重要的是，我们有 3 大数据中心，将近 10 个发布环境，如果每个环境都要重复配置一遍，那用户肯定是崩溃的。所以我们开发了跨环境同步，将测试 A 环境，同步到测试 B 环境。这还不够，我们又开发了“一键同步”功能，实现一次性更新到所有环境。

货拉拉从 2013 年成立，现在已经 10 年了，我们也是从“刀耕火种”的原始监控模式逐步演进而来的，研发还保留着人肉巡检的“好习惯”。

每天上午和下午的高峰期，各核心团队都会轮值选择一名研发遍历一遍它所有的应用的监控。从异常到RT，从 MySQL 到 Redis，确认无异常之后，再在飞书里报备“今日高峰期巡检后无异常”。

这样重复性的工作，能不能被替代呢？当然可以。

我们开发了定时截图功能。研发只要配置上它的看板地址和定期时间，我们就将 Monitor 截图推送到它指定的飞书群中。

就是这么一个简单的功能，现在已经有 200 多份订阅，每天还不时有用户来咨询用法。

我们的报警已经非常强大了，95% 稳定性事件能在 5 分钟内发现，国内货拉拉365 天连续无故障，用户每天闷头写代码都不会错过任何风吹草动，为什么这个小功能这么多人用呢？

后来我看了货拉拉投资的电影《保你平安》，才突然明白：用户每天看到飞书群里面推送的业务大盘截图，图的就是一个“心安”。每天群里看到那张图，就知道自己的应用在稳稳地运行中，公司的业务在稳健发展着。

所以，这个巡检的功能虽小，但是用户体验的提升非常大。

2、服务业务架构的监控

前面我提到那次让整个技术中心难以磨灭的云厂商引起的故障，为了避免类似故障后只能干瞪眼的场景，技术中心决定实施“多可用区间高可用”的架构设计。

与其他很多业内公司的“异地多活”、“同城多活”等容灾方案，“多可用区间高可用”成本代价最小，因为它没有占用冗余的资源，而且对研发最为优化。

我所在的基础设施团队对网关改造后进行流量控制，研发只要升级中间件，就能实现“多可用之间高可用”。

但是，对于监控领域，要实现“多可用区”的可观测性可不容易。最首要的所有指标数据都需要增加一个“可用区 Zone” 的维度。

还好我们开发了一个 Prometheus 采集代理组件，有它根据机器的 Zone 信息，将所有机器和容器指标、应用的自定义指标都加上了 Zone 的 Label，避免了对开源的 node-exporter、kube-stat-metric 这样的组件的改造。

第二，研发进行了“多可用区”改造后，就特别想知道自己改造情况，有没有跨可用区的异常调研。为了满足这样的需求，我们也特别调用可用区加入调用拓扑，让研发有能力立刻确认。

传统时期，我们都是孤立地看业务指标，具体的业务形态都是存在我们的脑海之后。所以，我们将应用调用拓扑数据存到了图数据库之后，就想能不能把业务的真实拓扑也展示出来？

因此，后来就有了业务大图的功能。

研发能够选择业务指标，将下单、接单、履约这样的完整业务链路串联起来，集中地展示到它的业务指标看板大屏上。

3、智能报警助力稳定性建设

最后来讲讲智能报警，是怎么帮助货拉拉做好稳定性的。

我们的报警很好创建。在指标查看时，点击指标的右上角“创建报警”，它会带上那条指标的查询语句，选择阈值或者算法，再选择对应的报警订阅组，报警就能生效了。

所以，报警数量就到了上万条。但是稳定性团队就犯难了，这么多报警怎么做统一管理呢？

我们就开发了“动态分发”功能，针对是否AppId、部门、报警等级等能过滤所有报警信息，再次推送到新的报警通知渠道。

稳定性团队能够专注在关键和核心的报警上，报警也能实现推送到正确的人了，接下来还有报警太多的问题。

举例而言，一台容器的 Node 节点了会触发机器失联报警，上面运行的十几个 Pod 会触发容器心跳报警，对应应用可能会触发请求异常的报警。

可见，一个事件就可能触发出几十条报警风暴。在真正的故障来临时，过多的报警反而会影响故障的处理时效。

所以，我们开发了“标签合并”功能。我们以 15 秒为窗口，查看期间触发的报警，尝试以 AppId、报警规则、Host、IP 等维度将这些报警“聚合”起来，取聚合后的最高评分，将报警信息聚合起来。

像刚才那个场景，就只会发一条报警，告诉 NODE 挂了，且十几个 POD 都挂了，这样就能大幅减少报警风暴的问题。

在报警规则方面，我们还开发了 5 种无阈值的算法。研发配置报警时，不用拍脑袋估算阈值，只需要填写波动率、检测趋势就可以了。

通过我们提供的“数据回放“功能，研发可以根据过去 7 天的数据，来检验配置的是否合适。

另外一个与报警紧密相关的场景，就是真正故障来临时。过去我们都是人肉排查：“是不是你发布了？”“那你呢？”……后来我们将这个流程实现了自动化。

首先，故障发生后，应急流程会自动触发所有变更操作的分析，列出30 分钟内的变更。

其次，检查所有核心业务的关键指标。例如，HTTP、SOA 的成功率和 rt 是否有巨大波动。

上图的例子就是故障发生后，推送的信息显示：“没有变更；但是三个核心应用调用某个地图供应商的服务异常。”

如此，立刻就锁定了问题原因，后续我们切换并降级这个地图供应商，业务立刻就恢复了。

整个事故发现 1 分钟，定位估计 1～2 分钟，恢复 5 分钟。

另外，虽然我们的研发都养成了发布后巡检一遍应用的习惯，但也总会有意外，所以，我们做了个发布后巡检的功能。只要发布完成，就持续为他检查 41 个指标项以及日志中的异常数量，如有异常波动，就立刻推送到应用的开发与运维。

这样的智能报警能力，既能让研发安心实现功能需求，又能保证应用和业务的稳定性。

三、面向未来的监控基础能力

1、GPT+监控？

ChatGPT 的横空出世，不仅可能将引爆人工智能的革命，可能也会颠覆我们基础设施层面各个产品的功能设计。

我先讲一个 GPT 和稳定性场景集成的例子，来说明它的潜力。

我们每天都会在飞书中群发稳定性日报。当天的值班人员会到稳定性平台上，人工统计当天发生的故障或隐患，再粘贴一份稳定性 Tips（来自一份稳定性知识库）。

在使用 GPT 后，这些工作就可以自动运行了。

首先，我们直接访问稳定性平台的页面，获取 source code，清晰 html 去除 css 等冗余信息，就可以发给 GPT，让他过滤出当天的故障事件。

再以稳定性知识库里面的内容为素材，让 GPT 生成一段有趣而吸引人的小故事。

这样再讲上面两步的结果组装成，稳定性日报。

这个小例子，能说明 GPT 有着超越普通人的数据分析能力、文本生成能力，只要想象力无限，GPT 与现有的场景集成可以改变我们的工作方式。

所以 GPT 在监控领域有哪些可能性呢？

首先，在 ChatGPT 最擅长的知识生成领域，对于通用的开源组件，它能很好地解答常见问题。

例如，我们经常需要向用户解释 node-exporter 采集的各种指标的含义，就可以由ChatGPT 代劳。

而它的文本生成能力，也可以应用于报警后的应用状态分析。例如，我告诉他应用现在的一些指标信息，以及对应判断规则。以前人工判断应用健康状态的步骤，就能自动运行。

这些 GPT 的能力，如果和报警和发布的流程自动化的结合起来，将解放我们现在硬编码的很多判断逻辑。

由于 GPT 的能力实在太新了，有些集成还在开发之中，下面介绍三个已经实现的集成 Demo。

首先是监控客服，我们这边将 GPT 与飞书机器人做了一个集成。因为我们报警的指标实际上来自开源的一些组件，很多同事过来问这个指标、那个指标到底是什么意思。这个场景直接去问 GPT，它应该有它这些通用的知识，可以帮助我们来回答这些内容。

第二个是周报的自动生成，这个是将飞书机器人和飞书的文档、多维表格的数据打通，能够去到我们项目管理表格上的内容，自动生成一个可读性更好的周报。

第三个是我们发布平台和GPT集成，也就是如果我们的研发发布或编译编译失败时，他会带上对应的一些编译失败的信息以及应用的一些元数据信息。问下 GPT，它就会告诉到底是大概什么原因以及如何解决。

2、总结与展望

我们监控平台实际上也是从好几年“刀耕火种”的状态（拿一些开源组件把它们搭起来），到后来我们这边开发了一站式的监控平台 Monitor，目前我们也融入了一些智能的要素，和现有相关的系统做了一些自动化的打通。

而在监控平台的建设挑战上，因为研发希望监控数据是越来越多、越来越细，但是成本永远是有限的。所以在成本治理、数据处理架构的升级、有效监控数据的选择，都需要投入精力去应对。

其次，智能化技术的发展，永无止境。新技术日新月异，我们怎么样把那些技术和我们的场景把它整合起来，这是一大难点。实际上，我们不仅是在做技术、做平台，但多是在做产品，怎么样去洞察用户的需求，怎么样和用户具体的使用场景结合起来，其实是考验我们产品设计的能力。

后续我们也计划出一个“智能报警建设”的专栏，会通过“货拉拉技术”和“dbaplus社群”官方公众号进行分享，欢迎大家多多关注、继续交流~

点击此处获取本期PPT(提取码：0628)

一次令人窒息的云事故，逼我们肝出这个智能监控平台……

降本的Kubernetes何时成了“成本刺客”？

YouTube如何利用MySQL支撑24.9亿用户？

人肉运维100次后，年底出了P0级故障……

关于国产数据库我不得不说

分库分表，可能真的要退出历史舞台了！