1.前言大约一年前，我加入货拉拉，全面负责货拉拉监控系统的建设。今天给大家分享一下货拉拉在监控领域，尤其是在智能监控领域的一些成果。在正式开始之前，先简单介绍一下货拉拉的相关情况。公开资料显示，货拉拉目前在全国352个城市运营，月活跃司机66万，月活跃用户840万，日订单量超百万。霍拉拉的技术基地建立在云厂商之上，所有技术研发人员超过千人。经过历史上那段残酷高速发展的时期，霍拉拉现在使用了Java、PHP、Golang、C++等多种开发语言，每种语言使用的开发框架也各不相同。其次，火拉拉的业务场景也多种多样，比如货运、搬家、企业版等使用场景。因此，从整体上看，货拉拉技术中心的任务不仅包括推动业务的快速发展，还包括推动自身的系统治理，实现技术的统一和规范，而监控系统在这个过程中发挥着巨大的作用。今天我们先简单回顾一下AIOps和智能监控的几个概念，然后分享一个智能监控的构建框架，然后分享我们在火啦啦的一些智能监控实践，最后提出我们在实践过程中的体会和思考。2.AIOps和智能监控AIOps、Observability和Monitoring是这些术语的内涵。你应该听过很多相关的解释和分析。监控的最底层是传统监控数据的采集和展示，人在其中扮演着重要的角色。可观察性是对应用程序和系统各个层面的系统监控数据进行全面采集和展示。AIOps不等同于可观察性。更侧重于智能算法在运维领域的应用，实现自动化。而“智能监控”，我认为是可观察性和智能运维的交集。它需要利用全面、多层次的监测数据，利用人工智能算法和技术来满足监测领域的监测需求，达到监测目的。3、货拉拉智能监控构建框架让我们先看看“监控领域大图”，从监控系统的业务功能、数据元素、人员组织等方面进行简要分析。业务功能从一个监控系统的功能需求来看，需要为开发者提供应用和系统的各个维度的信息，以便分析和排查问题；还需要提供告警功能，以便用户在第一时间响应故障；既能在应急响应时提供稳定可靠的监控数据支持，又能在日常稳定运行时提供应用治理数据。数据元素监控系统涉及的数据中，日志、链接、指标数据、事件是其必不可少的输入。前三个大家应该都不陌生，事件包括应用变更事件和告警事件、业务调整、促销等业务运营侧的事件，以及云厂商运维事件和底层调整。“事件”的范围更广，内容更多样化，结构也更复杂。人员和组织监控系统的用户首先是研发运维等日常用户，也有遇到故障紧急情况冲到第一线的NOC团队，也有稳定团队负责日常生活中应用程序和系统的稳定性。而老板也是我们的重要用户。之所以专门分析我们监控的用户，是因为他们对监控系统的要求略有不同。比如我们的系统宕机了，是我们的NOC和具体的R&D冲到最前面去解决问题。但我们希望尽快恢复我们的系统。除了我们的用户，最急迫的就是老板。如果他能在手机上看到业务曲线一点一点恢复，他的心里可能会好受一些。所以老板会怎么使用监控系统也是我们功能设计的重点。特性需求从监控系统的特性需求来看，要求我们的监控数据准确，告警及时有效，数据采集、上报、显示、告警等过程自动化、高效。架构设计要求系统能够灵活应对业务系统的变化，而我们的监控数据需要开发到第三方系统，最重要的是监控系统要保证自身的稳定性和高可用性。我们通过上图展示了监控系统中的核心要素。除了在故障层面回答我们系统从指标出现到问题原因的多层次问题，各级可观测数据的应用是监控系统的核心。而我们投入大量资源和人力建设监控系统，希望从研发效率、系统稳定性、结构优化等方面受益。配合今天的主题，我们如何将AI智能技术融入监控系统，进一步提升我们的监控能力？根据货拉拉的资源和能力现状，我规划了一个智能监控的建设框架，可以作为大家结合具体公司场景的参考。1.数据在数据输入方面，除了上面提到的“MELT”四大监控数据外，还包括海量的历史数据和准确的实时数据，以及业务类型、重要性级别、申请的部门人员。、应用调用和依赖的拓扑信息，以及研发运维为应用打上标签的数据，还需要相应的机器信息、应用底层网络、机房等云资源信息等数据。2.技术1)可视化与集成将各个监控要素分离出来进行可视化展示并不困难。难点在于将各种数据整合到一个平台中，让用户在各种使用场景下都能顺畅使用，达到使用目的。这就需要一个设计良好的统一监控平台。其次，只有把我们的监控数据开放给其他系统，才能最大化监控的价值。例如，将监控数据集成到压测平台、计划平台、业务团队自身的稳定性平台中是一个普遍的需求。2）告警分析在告警分析中，我们使用Prometheus，不管告警规则多么复杂，告警基本都可以实现。但是在大量告警之后，如何实现降噪、告警聚合、变化事件的关联，是我们告警后阶段需要做的大量优化工作。其次，告警阈值的趋势预测、应用的异常检测、告警应用的关联检测也是实现智能化监控的重点领域。3）知识图谱知识图谱的内容很多，适合监控领域的是“拓扑展示”和“知识生成”。拓扑展示：比如我们可以从指标和链接中生成应用相关的数据，然后结合应用元数据和其他信息，存储到图数据库中，进行多级拓扑查询和展示。知识生成：我们可以基于图信息匹配相似的路径来生成隐性知识，或者将其与我们的人工专家知识相结合来生成关于应用程序的新知识。4）自然语言处理在自然语言处理方面，我们可以对告警文本和应用日志进行文本本体抽取，生成结构化数据；利用文本聚类技术，将众多异常日志进行分类聚合，然后Distill成metrics，添加告警等。3.功能我们可以利用上面提到的技术实现自动故障修复、自动监控检测、变更检测等功能，故障可视化和根本原因分析。4.收益我们还是希望通过智能监控进一步提升研发效率、应急响应及时性、日常运营效率。然而，冰冻三尺非一日之寒，打造智能监控是一个系统工程，是常规监控的下一步。我们可以根据公司的技术发展阶段、整体技术体系、团队的技术能力，分阶段实现目标。四、货拉拉智能监控实践1、货拉拉一站式监控平台：Monitor前面我们简单回顾了AIOps与智能监控的关系，也提到了监控系统中的四个关键要素：指标、链接、日志、事件，同时也分享了拉拉智能监控搭建框架。目前，我们有一些阶段性的成果可以与大家分享。在此之前，有必要介绍一下货拉拉的一站式监控平台——Monitor。后续智能监控的一些实现都是基于Monitor构建的。经过我们团队近两年的建设，已经构建了涵盖应用、中间件、机器、容器、云平台、终端的多层次指标监控体系；覆盖主流框架和主流中间件的全链路监控体系，打通后端到后端底层的完整链路；日志监控系统，对应用日志、访问日志、容器日志进行统一采集和展示；日志监控系统，提供丰富的告警规则，灵活的告警接入方式，多样化的分发渠道，支持云平台告警推送的告警系统；最后，我们为用户提供聚合指标链接日志告警的一站式交互平台。该平台不仅支持电脑访问，还可以在飞书等移动终端轻松查看；最重要的是，我们也把所有的监控数据都打通了，通过OpenApi提供给我们的兄弟团队和兄弟系统。接下来我们来看看它的具体情况。首先是我们每天大量使用的业务仪表板，显示详细的业务数据；二是详细的应用仪表盘，可以查看应用的HTTP、SOA、中间件、机器等详细信息；用户可以通过点击指标查看相应的数据。跟踪链接和跟踪拓扑。我们还提供所见即所得的告警配置页面，以及告警后处理的查看页面；我们开发了一个可以集成在飞书的移动端，可以很方便的查看刚刚提到的业务仪表盘、应用仪表盘、告警事件。整个监控系统的数据量如下：目前我们总共存储了7T的指标，每天添加23T的链路数据，每天添加150T的日志数据，持续运行7000+自定义告警规则。监控系统每天的独立用户在600+人左右，也就是研发中心一半的同事每天都在使用我们的系统。那么这个一站式监控系统——Monitor背后的架构是怎样的呢？1）指标我们基于普罗米修斯的生态。用户上报指标数据，经过一层采集转换后，Prometheus远程写入到vitoriametrics。我们也基于vm-alert实现了基本的告警功能。特别是，我们在数据采集层和查询层分别开发了转换组件和代理组件。前者用于裁剪用户上报的指标数据，后者用于加速查询和限额控制。2）Trace链接基于Skywalking生态，我们为用户提供TraceSDK，利用字节码注入的方式进行数据埋点，中间通过Kafka将包括AppId、timestamp、Endpoint、Tags等索引信息存储在Elasticsearch中，原始链接数据存储在HBase中。3）日志方面，我们在应用主机上使用filebeat和Logstash收集日志，由自研的消费者应用将日志写入Elasticsearch。4)数据查询API服务对应每一类数据的读取。特别是，我们最近推出了AIOpsAPI服务，它负责使用指标和链接等数据构建应用拓扑，并将其存储在图数据库中。以上是整体结构。其中，橙色组件为我们自研服务，其他为开源组件。2、以货拉拉智能监控为例下面我从一个应急响应场景来介绍智能监控的实现，这是去年货拉拉的一个常见场景。如果突然出现业务波动，就会触发告警，然后应急响应人员NOC会根据告警指示符关联的app，跳转到那个app的应用仪表盘，他可能会发现“soa”的指示符.rt”突然飙升，这意味着SOA响应时间变差了。下一步，他只需要点击曲线上的指标，就会弹出请求周期对应的Trace。从Trace链接可以看到下游某个App调用超时了。还是在这个页面，直接点击日志的链接，根据“App+TraceId”跳转找到对应的日志。他可能会通过日志找到具体的错误原因：某个配置错误。目前本App相关研发人员已参与排查过程。研发说几分钟前，他更新了一个配置。那么可以定位到这个变化是导致业务指标下降的原因。因此，手动回滚配置可以恢复业务。从告警触发到排查问题，大部分过程都可以在我们的监控平台Monitor上完成，但是还有很多环节需要人工参与，比如从业务指标到AppIdSOA指标、日志判断、变更关联等。我们自然会想，如果这些流程都自动化了，是不是可以加快故障排除的速度？因此，在我们的报警系统中，触发报警后，我们就开始自动分析的过程。会从异常数量、http或soa成功率、rt、qps等多个角度分析告警应用的健康状态。二是检测应用是否在30分钟内发生变化操作。进一步根据应用依赖拓扑分析下游应用的健康状态和变化。在用户体验方面，我们将这些分析结果推送给飞书。理想情况下，我们还可以针对具体的故障原因给出具体的操作建议，甚至关联相应的应急预案。前面提到，在触发告警后，会自动分析应用的健康状态。这些信息来自于我们为每个应用统一配置的告警模板，其中涵盖了rt、exception、JVM、infrastructure等几十条告警规则。在设置报警规则的阈值方面，除了经验值的方法外，我们最近还开发了一种基于平滑算法和机器学习来实现自适应阈值的方法。在告警降噪和聚合方面，我们实现了按告警联系间隔抑制、按告警类型聚合、按应用App聚合等多种方式。从整体的智能报警架构层次来看，我们从下到上分为四个层次。基础层：形成降噪、静音、发送记录、告警变更审计等基础能力。算法层：规划平滑算法、无阈值算法、数据异常变化时的波动检测算法、数据缺失时的插值算法等查询层：不仅有指标、应用元数据、拓扑数据查询，还有缓存模块。规则层：除了刚刚提到的全局统一告警模板外，还提供了可由产研院分叉的自定义模板和自定义规则，产研院可以自行组合告警条件和告警模型。右边的算法中心就是我们现在正在构建的模块。它将利用现有的机器学习算法，根据货拉拉独有的业务数据，训练出相应的报警模型。上面多次提到的拓扑数据是指我们利用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平台将更加丰富，实现更强的智能化和自动化。希望货拉拉技术团队在监控领域的总结能够为大家提供公司现状的参考，为大家规划监控系统的开发提供一些参考。
