一、前言

大约是一年多前，我加入到货拉拉，全面负责货拉拉的监控体系建设。今天想与大家分享交流一下货拉拉在监控领域，特别是智能监控领域的一些工作成果。

在正式开始前，我简要介绍一下货拉拉的相关情况。

【资料图】

据公开资料，目前货拉拉已在全国 352 座城市开展业务，月活司机66万，月活用户 840万，每日单量超百万。而货拉拉的技术底座建设在云厂商之上，所有技术研发人数超千人。在历史的野蛮快速发展时期过后，现在货拉拉使用着如Java、PHP、Golang、C++等多种开发语言，每种语言中使用的开发框架也不尽相同。

其次，货拉拉的业务场景也是多样的，有货运、搬家、企业版等使用场景。

因此，整体上货拉拉技术中心的任务既包括推动业务快速发展，也需要推动自身的系统治理，实现技术统一化和规范化，而监控系统在这个过程中发挥着巨大的作用。

今天我们首先简要地回顾AIOps与智能监控的几个概念，其次分享一个面向智能监控的建设框架，再分享一些我们在货拉拉中的智能监控实践，最后提出我们在实践过程中的经验与反思。

二、AIOps与智能监控

AIOps、Observability、Monitoring这几个术语的内涵，大家应该听过很多相关的解释与分析。

最低层次的Monitoring就是传统的监控数据的收集和展示，人是其中重要的参与角色。而Observability则是全方面地采集和展示应用和系统各个层次的系统性的监控数据。AIOps不等价于Observability，它更侧重于智能算法在运维领域的应用，实现自动化。

而“智能监控”，我认为就是可观测性与智能运维的交集。它需要使用全方面、多层次的监控数据，利用人工智能的算法与技术，在监控领域满足监控的需求，实现监控目的。

三、货拉拉的智能监控建设框架

我们来看下“监控领域大图”，从一个监控系统的业务功能、数据要素、人员组织等方面进行简要的分析。

业务功能

从一个监控系统的功能需求上，它需要为研发人员提供应用、系统的各维度信息以进行分析和排障；它也需要提供报警功能，让用户能第一时间响应故障；它既能在应急处理时提供稳定可靠的监控数据支持，也在日常稳定性运营时提供应用的治理数据。

数据要素

从监控系统涉及的数据上，日志、链路、指标数据、事件，是它必不可少的输入。前三者大家应该很熟悉，而事件既包括了应用的变更事件、报警事件，也可以包括业务运营侧的业务调整、促销等事件，也可以包括云厂商的运维事件、底层调整等。“事件”的范围更广，内容多样化，结构更复杂。

人员与组织

监控系统的使用方首先是研发和运维等日常使用者，也有在故障应急时冲在第一线的NOC团队，也有在日常时负责应用和系统的稳定性建设的稳定性团队，以及老板也是我们重要的使用方。

之所以特别分析我们监控的使用方，是因为他们对监控系统的需求略有差异。比如，如果我们的系统挂了，冲在最前面去解决问题的是我们的NOC和具体研发。但是希望我们系统尽快恢复的，除了我们的用户之外，最急迫的就是老板。如果他能在手机上看到业务曲线一点一点地恢复，他的心脏或许会好受一些。因此老板会如何使用监控系统，也是我们功能设计的重点。

特性要求

从监控系统的特性要求上，要求我们的监控数据准确、报警及时有效，数据采集、上报、展示、报警等流程自动且高效，在架构设计要求系统能够灵活响应业务系统的变化，而我们的监控数据需要开发给第三方系统，最重要的也就是监控系统要保证自身的稳定性和高可用。

我们通过上图展示监控系统中的核心要素。除了要回答我们系统在故障层面从指标表象到问题原因的多层次问题外，应用各个层面的可观测性数据是监控系统的核心。而我们投入大量资源与人力建设监控系统，就是希望在研发效能、系统稳定性、架构优化上有所收益。

切合今天的主题，我们如何在监控系统中集成AI的智能技术，进一步提升我们的监控能力？

我根据货拉拉的资源与能力现状，规划了一份智能监控的建设框架，可以供大家与具体公司场景结合时参考。

1、数据

在数据输入方面，除了前面提到的“MELT”四种监控数据，还要包括海量的历史数据和精确的实时数据，也需要应用的业务类型、重要等级、部门人员等元数据信息，应用之间调用依赖的拓扑信息，研发运维给应用标注的标签数据，也需要对应的机器信息，应用底层的网络、机房等云资源信息等各种各样的数据。

2、技术

1）可视化与集成

如果把各个监控要素分开来做可视化展示，并不难。难点在于把各种数据整合在一个平台之中，在多种使用场景下用户都能顺畅使用，并实现它的使用目的。这需要一个精心设计的统一化的监控平台。

其次，我们的监控数据只有开放给其他系统，才能最大化地实现监控价值。例如，监控数据集成到压测平台、预案平台、业务团队自己的稳定性平台中常见的需求。

2）报警分析

在报警分析上，我们使用了Prometheus，无论多复杂的报警规则基本都能实现报警。但是海量报警之后，如何实现降噪、报警聚合、变更事件的关联是我们需要在报警后阶段做的很多优化工作。

其次，报警阈值的趋势预测、应用的异常检测、报警应用的关联检测，也是将智能技术在监控落地的重点领域。

3）知识图谱

知识图谱中的内容很多，适配于监控领域的是“拓扑展示”和“知识生成”。

拓扑展示：例如，我们可以从指标、链路上生成应用依赖数据，再结合应用的元数据等信息，存储到图数据库中，进行多层次的拓扑的查询和展示。

知识生成：我们可以根据图的信息，匹配相似路径，生成隐含的知识，或者和我们人为的专家知识结合，生成新的关于应用的知识。

4）自然语言处理

在自然语言处理方面，我们可以针对报警的文本、应用日志，做文本本体提取，生成结构化的数据；使用文本聚类的技术上，可以将众多异常日志归类聚合，再将它提炼成指标，加入报警等。

3、功能

我们能借助前文提到的技术实现自动故障修复、自动监控检测、变更检测、故障可视化、根因分析等功能。

4、收益

我们依旧希望通过智能监控进一步提升研发效能、应急处理时效、日常运营的效率等方面。

然而，罗马不是一天建成的，建设智能监控是一个系统性的工程，是常规监控的下一步。我们可以随着公司的技术发展阶段、整体技术体系、团队的技术能力，分阶段实现目标。

四、货拉拉的智能监控实践1、货拉拉的一站式监控平台：Monitor

前面我们简要回顾了AIOps与智能监控的关系，也提到了监控系统中的四个关键要素：指标、链路、日志、事件，也分享了一个货拉拉的智能监控建设框架。目前我们有一些阶段性的成果，可以分享给大家。在此之前，我需要介绍货拉拉的一站式监控平台——Monitor，后续智能监控的一些实现都是构建在Monitor之上的。

经过我们团队将近两年的建设，已经建成了覆盖应用、中间件、机器、容器、云平台、端上的多层次的指标监控系统；一个覆盖了主流框架、主流中间件的全链路监控系统，打通了从端上到后端底层的完整链路；一个统一采集和展示了应用日志、访问日志、容器日志的日志监控系统；一个提供丰富报警规则、灵活报警触达方式、多样化分发渠道、支持云平台报警推送的报警系统；最终我们提供给用户一个一站式的汇聚了指标链路日志报警的交互平台，这个平台既支持电脑端访问，也能轻松在飞书等移动端查看；最重要的是，我们还开放了所有的监控数据，通过OpenApi提供给我们的兄弟团队和兄弟系统使用。接下来我们来看看它的具体情况。

首先是我们日常重度使用的业务大盘，展现着详尽的业务数据；其次是详细的应用大盘，可以查看应用具体的HTTP、SOA、中间件、机器等详细信息；用户通过点击指标就能查看到对应Trace链路，以及Trace拓扑。

我们也提供了所见即所得的报警配置页面，以及报警后处理等查看页面；开发了能集成在飞书中的移动端，刚才提到的业务大盘、应用大盘、报警事件等都能轻松查看。

整个监控系统的数据量如下：目前我们存储着7T的指标总量，每日新增23T的链路数据，每日新增150T的日志数据，持续运行着7000+个自定义报警规则。监控系统的每日独立用户约600+人，也就是研发中心一半的同事每天都会使用我们的系统。

那么这一套一站式的监控系统——Monitor，背后的架构是怎么样的？

1）指标

我们基于Prometheus的生态，用户上报指标数据，经由一层采集的转换层之后，由Prometheus remote write到victoriametrics中。基础的报警功能我们也基于vm-alert来实现。

特别的是，我们在数据采集层和查询层，各开发了一个transformation组件和proxy组件，前者用来剪裁用户上报的指标数据，后者用来加速查询和限流管控。

2）Trace链路

我们基于Skywalking的生态，提供给用户Trace SDK，以字节码注入的方式做数据埋点，中间经由Kafka，将包括AppId、时间戳、Endpoint、Tags等索引信息存储于Elasticsearch中，链路原始数据存储于HBase之中。

3）Log方面

我们使用filebeat和Logstash去采集应用主机上的日志，自研的consumer应用将日志写入到Elasticsearch中。

4）数据查询

每种数据对应的API服务去做读取。

特别的是，我们最近引入了AIOps API服务，它负责利用指标、链路等数据构建应用拓扑，存储于图数据库之中。

以上就是整体架构。其中，橙色组件是我们自研的服务，其他都是开源的组件。

2、货拉拉的智能监控举例

接下来，我将从一个应急处理的场景介绍智能化监控的落地实践，这是去年常见于货拉拉的一个场景。

如果突然有一个业务波动，它会触发一个报警，接着应急处理人员NOC会根据报警指标关联的App跳转到那个App的应用大盘，他可能会发现“soa.rt”这个指标突然飙高，这意味着SOA响应时间已经恶化。

下一步，他只需要在曲线上点击指标，就能弹出对应请求时段的Trace，从Trace链路上可以看到下游某个App调用超时。

它还是在这个页面上，直接点击日志的Link，就根据“App+TraceId”跳转找到对应的日志。他可能通过日志，找到具体的错误原因：某个配置出错了。

现在这个App的相关研发人员已经参与到故障处理的过程中来，研发说几分钟前，他更新了个配置。那么就可以定位，这个变更就是导致业务指标下跌的原因了。所以，人工回滚配置，就能恢复业务。

从报警触发到故障排查的大部分流程，在我们的监控平台Monitor上都能完成，但是仍有很多人工参与的环节，如从业务指标到AppId的SOA指标、日志的判断、变更的关联等。我们会自然而然地想到，如果这些流程自动运行，不就可以加快排障的速度吗？

因此，在我们的报警系统中，在触发报警后，我们就开始自动分析的流程。

它会分析报警应用的健康状况，从异常数量、http或soa的成功率、rt、qps等多角度分析。其次，检测应用在30分钟内有无变更操作。再进一步根据应用依赖拓扑，分析下游App的健康状态和变更。

在用户的感受上，我们将这些分析的结果推动到飞书中。

理想情况下，我们还能针对具体的故障原因，给出具体的操作建议，甚至关联上对应的应急预案。

刚才提到报警触发后会自动分析应用的健康状况。这个信息来自于我们为每个应用统一配置的报警模版，它覆盖了rt、异常、JVM、基础设施等几十个报警规则。

在报警规则的阈值设置上，除了经验值的办法之外，我们最近也在开发基于平滑算法和机器学习的方式，以实现自适应的阈值。

在报警降噪和聚合上，我们实现了按照报警触达的间隔抑制、按照报警的类型进行聚合、按照应用App聚合等多种方式。

从整体的智能报警的架构层次上看，我们自下而上划分了4个层次。

基础层：将降噪、静默、发送记录、报警变更审计等形成基本能力。算法层：规划平滑算法、无阈值算法、数据异常变化时的波动检测算法，数据缺失时的插值算法等。查询层：既有指标、应用元数据、拓扑数据的查询，也有缓存模块。规则层：除了刚才提到的统一的全局报警模板，也提供产研能fork出自己版本的自定义模板，以及自定义规则，产研能自己组合报警条件、报警模型等。

右侧的算法中心是我们现在在建设的模块，它会利用现有的机器学习算法，根据货拉拉特有的业务数据，训练出对应的报警模型。

前面数次提到的拓扑数据，就是我们通过AIOps-API组件，分析应用元数据、依赖数据等，按照知识图谱的思路，生成了以App为中心的本体设计。其中存储了14种本体，16种关系。

这一套数据生成之后，我们能够分析出：

总是出故障的是哪些应用，是哪个部门的稳定性比较差，哪些研发负责的应用稳如磐石？应用间相互调用的拓扑图中间件的上游的使用情况……

在监控平台的集成上，我们在应用大盘中集成了应用拓扑图，用户可一眼看到这个应用的依赖，以及实时的QPS和RT。在业务大盘中，我们将核心业务的实时业务数据可视化，方便业务团队的查看。

根据我们安全生产团队的统计数据，在核心应用的监控覆盖率上达到了100%，报警的覆盖率100%。根据今年 3～5月的故障数据，整体货拉拉的服务可用性是99.98%，10+起生产故障中，100%是5分钟通过报警发现，89%是20分钟内定位问题，78%的案例是在25分钟内止损恢复。

3、经验与反思

最后，我们也分享一些踩坑后获得的经验。

1）最重要的是在设计埋点规范时，一定要提前设计，预留好足够的扩展性，否则未来就要做痛苦的兼容工作。

2）要面向用户设计。例如，对运维来说，Prometheus确实很好用。但对于研发人员就未必了，一知半解的各种指标名，好用但难于精通PromQL，更别说让研发去手写PromQL语句配置报警了。所以我们提供了类SQL的PromQL的查询封装语法、所见即所得的报警配置页面，这些都是从用户体验角度出发，设计一个好用的监控系统必须考虑的。

3）要让系统简单透明，并告诉用户如何自助排查各种监控问题。

4）合理取舍成本和收益。监控是有成本的，是否有必要采集所有数据、哪些是最有价值的数据，这些问题都需要我们提前规划。

五、总结与展望

最后我也用一张图总结一下货拉拉在监控领域的变革历史。

1、小厂（过去）

当我们还是小厂时，我们的研发人数不多。监控系统也是由运维团队从零搭建起来的，想的是怎么快就用什么。所以，当时我们选用了开源的Prometheus、Skywalking、ELK、Grafana把我们的应用监控起来。因为是不同的产品，监控的各个要素分布于不同的系统上，产研在排障上体验不好，还是手工登录机器、或者凭经验排查居多。

2、中厂（现在）

到了第二个阶段，我们货拉拉现在也发展成了“中厂”的规模。建设监控领域的职责，也从运维团队转移到了专门的监控团队上。

监控团队的首要任务就是要开发一个一站式的监控平台，把下层的各个监控要素整合到同一个产品上，将信息有效整合起来，让监控体现出真正的价值。

之前我们选用的开源产品（如Prometheus、Skywalking等）还在继续使用，不过我们现在有了更多的技术储备与精力去改造他们，添加和优化其中的数据处理逻辑，从监控视角上为业务的飞速发展做长期规划。在AIOps方面，我们也结合具体需求场景做了一些尝试。

此时，技术中心的人员结构上，运维团队更加专注于底层运维，SRE和NOC团队成立了之后专注于整体的系统稳定性建设。而DevOps团队建设了强大的CMDB与云管平台，屏蔽了底层云厂商的细节，确保我们上层的监控系统能够快速推广到多云环境中。

3、大厂（未来）

在不远的“之后”，随着货拉拉业务的飞速发展，技术中心很可能继续发展成若干个研发中心，那么此时更需要监控团队把监控能力打造为一种基础能力，使其能够在更多差异化场景下快速复用。

这里我也预测一点变化：在技术中心扩大到一定规模后，单一的一个监控平台无法满足用户多样化的需求，很可能会分化出独立的链路平台、日志平台、稳定性平台等。此时也需要把监控能力视为基础能力，其中对数据的采集、处理、分析等环节需要能复用到其他系统中。

在“未来”，我们也会有精力自研时序数据库、链路和日志等系统，更好地匹配我们的业务需求。而AIOps平台和DevOps平台会更加丰富，实现更强的智能化、自动化。

希望货拉拉技术团队在监控领域的一个总结能供大家参照当前公司所处的状态，为大家规划监控系统发展思路时提供一些参考。​

关键词： 监控系统 技术中心 应急处理 机器学习