基于APM的智能运维体系在京东物流的落地和实践

2019 年 6 月 4 日 高效开发运维

作者|付正全

本文整理自 2019 年 QCon 北京站上京东物流架构师付正全的演讲，主要介绍了京东物流大规模实时监控平台、AIOps 和 APM 的相关实践。

为了支撑业务的高速发展，京东物流在智能运维体系的落地和构建方案上一直迭代优化、持续演进。从构建基于系统指标的实时大规模智能监控平台到融合多个部门多个监控平台的统一监控平台实践，再到基于 APM 的智能运维体系落地。通过实时告警、实时预警、故障智能处理以及全方位的应用维度数据分析，大大缩短了研发人员定位问题的效率，有力保障了大促期间各系统的平稳运行。

我们在构建这套运维体系的时候大体上分为以下三个阶段：

构建实时的大规模监控平台。这个阶段是一个从 0 到 1 的过程，从基础的 CMDB 系统建设到建设大规模实时监控平台。
第二阶段在监控平台的基础上整合了京东现有的多个应用监控系统。结合应用维度的数据整合，进一步完善了监控数据维度的同时极大提高了研发人员进行故障定位的效率。
第三阶段我们开始了 APM 和 AIOps 相关的一些尝试。

下面我会从以下几个方面来介绍今天的内容：

智能运维发展的现状和趋势
智能运维体系建设方法论
大规模实时监控平台的实践方案
智能故障定位与处理实践
APM 在京东物流的落地实践
智能运维落地规划

智能运维的发展

关于智能运维的发展，我们将发展过程分为以上七个阶段。前三个阶段从手工运维发展到面向业务服务的主动管理。第四个阶段是服务驱动，该阶段建立了统一的 CMDB 系统，这时候我们需要服务的流程化来支撑整个运维体系，比如一些工单系统等等。

运维发展的第五阶段是自动化和平台化，该阶段将运维工具、流程集成为统一的运维平台，提供资产管理、监控告警、故障处理等运维服务，此时已经构建了初步的平台化的运维体系。目前多数企业还是处在自动化和平台化的阶段。

下一阶段是数据化。监控平台、运维平台将持续产生大量的数据，这一阶段我们运维平台的主要任务就是结合大数据分析的工具和技术，挖掘数据价值。统计数据和结论反过来又可以作为实际运营决策的重要参考。

最后一个阶段是智能运维领域的趋势——AIOps。将 AI 技术应用于运维领域，在异常检测、根因分析、故障预测、智能故障处理、智能运维机器人等方面已经取得了阶段性进展。但目前实现 AIOps 真正落地的不多，各企业目前只是在 AIOps 的某几个点上去发力和探索。因此，AIOps 之路任重道远，需要学术界和运维界两方面一起努力。

面临的挑战

现在我们遇到的挑战主要有：

做传统运维的人越来越少了。传统运维依赖人工操作，有时也被戏称为“人肉运维”。目前我们京东物流已经没有做传统运维的人员了，大家全部都转向了运维开发，这也是一个趋势。在传统运维人员减少的同时，我们管理的机器数量却翻倍了，这是我们面临的一个比较大的问题。
网络拓扑日益复杂。微服务出现之后，网络拓扑关系更加复杂了，资源频繁的弹性伸缩，导致 CMDB 和其他应用信息无法做到实时管理。
运维专家资源匮乏。运维行业要求硬件、系统、网络、脚本语言、开发能力、应用运维等多领域的知识储备，一名优秀的运维专家需要长期运维工作经验的积累。另外，目前运维从业者减少也导致了运维专家尤其是有丰富经验的运维专家资源匮乏的现状。
运维平台日趋复杂。很多公司发展到一定的规模之后，因为前期的发展规划不足，可能每个部门都有自己的运维或者监控平台，平台繁多就容易形成数据孤岛，这样就造成了研发人员在使用的时候非常不便。

拓扑

以前大家可能面对的是一个应用只操作一个数据库这种传统的应用架构，而现在几乎所有的应用都已经加入了微服务架构的行列，应用之间的调用情况就变得很复杂，在定位系统问题的时候就非常被动，这也是我们面临的一个问题。

APM

APM 是近几年才兴起。据 Gartner 统计，APM 是整个 ITOM，甚至 ITSM 领域里增长最快的一个领域，有很广阔的市场前景，目前全球 APM 市场规模大大约为 60 亿美元，预计在 5 年内可以达到 90 亿美元。目前国内外的 APM 厂商已经比较多，正处于群雄逐鹿的阶段。

运维人员的角色变化

由传统运维向智能运维的转型，除了产品、技术架构的升级之外还需要运维团队由背锅、救火式的被动运维向主动发现、处理、规避问题的主动运维转变来驱动。以上说到的诸多挑战和新技术的发展倒逼运维人员主动寻求变化，不能像以前一样，一提到运维就是背锅侠或者救火队员。要改变这种被动运维的方式，首先就要转变思想：运维也可以主动。可以从哪些方面主动呢？

产品意识。现在很多公司都在提倡技术输出、产品输出。京东目前的定位也是技术驱动，不止在电商类、物流类的上有输出，运维也需要对外输出，做一些产品化，可复用的组件。
可以做一些技术运营的工作。比如把一些组件或者平台在整个公司内部推广，甚至对外推广。如果有比较好的项目还可以考虑开源，借助社区的力量进一步发展。
架构运维。包含代码、项目标准化，优化开发流程，推进项目标准实施。目前很多大型公司都在进行中台化转型，架构运维是中台战略能否落地的关键。
还可以做一些业务增值类的工作。比如对一些运维事件做智能处理，自动扩容缩容，这样可以避免很多未来的一些问题。

智能运维体系建设方法论

那么到底要如何实现智能运维的落地呢？

我觉得第一点，就是统一规划，避免重复建设。很多公司发展到一定的规模之后，由于前期运维体系的发展规划不足，可能每个部门都有自己的一套运维或者监控平台，平台繁多就容易形成数据孤岛，导致数据串不起来，无法做全面的数据分析工作。

上面这张图是京东物流的运维体系规划。最下层是资源层，包括物理资源、虚拟资源、应用、中间件以及数据库。上层是平台层。在平台层，我们建立了维护基础数据的 CMDB 系统，在 ITSM 管理方面，集成了事件管理、问题管理、值班管理等运维流程化管理模块。在 CMDB 系统基础上我们建设了大规模资源监控平台、网络监控平台以及多个运维平台。京东物流在全国 550 个大型仓库中还运营着几百个库房的集群，针对库房运维管理我们建设了库房运维和数据库运维平台。通过 DevOps 平台将 CMDB、监控、运维等多个平台数据关联起来，形成闭环，从而建立基础的运维体系。

再往上，是数据化层。在这一层，我们期望通过对监控和运维平台产生的大量数据进行分析，做趋势性的预测和智能分析，提供一些比较有价值的统计报表，来指导业务运营和决策。

最上层是 AIOps 层，我们是从三个方面去实现的：发现问题，解决问题，规避问题。基于 AIOps，我们可以在异常检测、根因分析、故障预测、智能故障处理、智能运维机器人等方面继续发力探索。在解决问题方面，可以借助 KPI 聚类分析进行告警知识库自学习和故障自动处理等。只有前两个方面做好了，才能保证提前预估故障并进行预修复从而达到规避问题的效果，这是最理想的状态。

标准化是前提。也就是说我们所有的监控平台也好，运维平台也好，都要遵循统一的开发和设计标准，这样不仅能够提升产品质量而且利于以后的扩展和维护。这里分享一下我们运维体系产品研发的原则：产品标准化、系统平台化、监控服务化、组件模块化、脚本插件化。

产品化思维。由研发思维向产品化思维转变。前面已经提到过，运维平台的用户不止是运维人员，还有大量的研发人员。因此我们要从研发的角度考虑运维产品设计，充分考虑研发需求的同时注重服务的流程化，也可以理解为需求驱动。

还有一个概念，是运维中台。现在京东也在做一些中台相关的工作，同样我们运维领域也需要中台，比如我们可以把监控数据集中处理、清洗、告警、通知、分析等主要数据处理作为中台，把统计数据、大数据分析的结论数据等封装为数据组件，这样其他的一些相关应用可以作为前台，接入到运维中台，这个方面我们也已经做了一些尝试了，取得了不错的效果。

还有就是注重业务增值。我们往往针对运维平台的设计只注重提高研发效率，而较少考虑业务增值。我们在尝试的业务增值的例子：统计服务器、网络设备、物理设备的厂商、型号以及故障率，提供故障率较高的型号报表，这样采购的时候也更有针对性。再比如提供各应用、部门的资源使用率报表以及低资源使用率榜单，以此督促资源使用率较低的应用或部门进行缩容整改。

过程改进。运维体系的建设不是一蹴而就的，需要结合过程改进的工具和方法不断迭代优化。

闭环。在整个智能运维体系中包含诸多资源管理平台、监控平台、运维平台等，平台之间在数据和流程上是分散的，在 DevOps 平台中将这些平台串连起来以达到闭环的效果。DevOps 平台贯穿运维管理的全流程，可以说是整个智能运维体系实现闭环的关键。比如我们在发布应用的时候，从应用的申请、资源的申请，到代码编译、测试，甚至到监控，变更，一直到这个机器下线、应用下线，我们都整合到 DevOps 平台，这样就做到了闭环。在做智能运维体系建设的时候，如果达不到闭环的状态，那么整个运维流程就不完善，无法实现对运维事件的实时跟踪。这样的闭环也促进了资源的生命周期管理、流程管理以及审计管理等生态建设。

大规模实时监控平台的实践方案

京东物流大规模实时监控平台从 2018 年初开始构建。我们经历了三个大的阶段：

第一阶段

针对京东物流特殊的 IT 环境，我们实现了从 0 到 1 重新建立一套完整的大规模实时监控平台。

监控平台不同于普通业务平台，普通业务平台并发量峰值大多与时间相关，或者随时间波动。监控平台最大的特点是 24*7 全时段监控，平台的压力负载情况一直处于较高的状态。所以监控平台一定要做到低延时、高并发、高可用。以下是我们架构设计考虑的关键点：

实时大数据处理、高并发
微服务化、分布式、高可用、负载均衡
产品化、标准化、组件化、插件化
可扩展、可配置
对外接口设计、数据访问安全

那我们是如何从架构方面落地实现的呢？我们将整体系统架构拆分为底层数据处理架构和业务架构，底层数据处理架构负责监控数据的采集、数据清洗、校验、告警和通知操作。业务架构负责监控数据统计分析、展现。

首先我们采用被动监控的方式，通过部署监控 Agent，把监控数据收集到 Kafka 消息队列里。消费模块从 kafka 拿到数据后转存到 jimdb（京东内部的内存数据库中间件）中，jimdb 实际是一个内存的分布式消息队列。这里加了一层 jimdb 的队列。为什么要加这层呢？因为我们如果直接消费 Kafka，Kafka 有分区的概念，不同的分区之间可以并发生产消息，但是 Kafka 的分区是消耗磁盘 IO 的，如果我们建的分区太多，这个磁盘 IO 可能就会是一个瓶颈，而且意味着我们要需要更多的硬件资源。考虑到这一点，我们增加了 jimdb 层，它是一个生产者消费者模型的分布式消息队列，理论上可以有无数个 Consumer，这些 Consumer 之间并发消费数据，从而实现并发数据处理。

1.0 版本我们还注重降本增效，从应用维度统计了所有部门、应用的资源使用率。监控平台建立起来之后，我们发现某些应用或是机器的使用率很低，资源没有得到充分利用，还有很大的优化空间。于是我们提供了一些低使用率榜单，定时发送督促各个业务条线缩容，这也是业务增值的一个体现。

第二阶段

实时监控平台 2.0 的时候，针对京东目前多个监控系统并存、监控数据没有互通的问题，我们把所有的监控平台的监控数据整合在一起，接入了京东目前所有的监控系统，包括 log 监控、Docker 监控，MDC 的监控，DBS 的数据库监控，还有调用链监控等，把数据收集起来做统一的报警和分析。一方面有助于对应用进行更加全方位的数据分析与监控状态评估，另一方面也有助于后期建立根因分析的时候结合分布式跟踪系统去构建业务拓扑。

在 2.0 版本，我们会把所有监控平台的指标收集上来之后，在应用维度做统一的整合。这样在一个应用页面，就可以看到这个应用相关的所有监控信息，比如操作系统维度的指标，数据库相关指标、应用性能相关指标以及日志相关的指标等。此外，我们还加入了日志分析的相关功能，使用的是业界比较成熟的方案：通过 agent 将日志发送到 Kafka，Kafka 里面做一些 Cluster，Filter，最后存储和索引。

第三阶段

有了前面两个大版本的支撑，我们监控平台的 3.0 版本开始向 AIOps 发力。下图是产品的大体规划。左侧是一些普通的接入服务，监控平台首先进行数据采集、清洗的工作。在数据处理层上新增了可视化、事件处理、知识库、动态检测、动态预知等模块。这些功能点属于 AIOps 领域的初级功能都已经基本实现了。其他还有数据分析，包括容量预测、趋势预测和分析，也都有所涉及，目前我们重点在 AIOps 其他领域进行探索。

预测是 3.0 版本里的一个重点，大体上分为故障预测、容量预测和性能预测。我们之前尝试了业界基于 RSTM 的一个算法，该算法是基于时序数据预测的一个经典算法，实际使用后的预测效果还是很不错的，参考下图。

在 3.0 方面，我们还做了一些可视化的事情。在备战 618、双十一期间可以把主流程关键应用的监控状态信息直观地显示在监控大屏上。任何的异常或者报警都可以实时看到。大屏左侧和右侧展示的是性能方面的数据，比如 CPU、Load、磁盘，还有数据库的一些关键指标，下面则是实时滚动的告警信息。

智能故障定位与处理实践

在故障处理方面我们比较好的一个实践是快照机制。当监测到异常时系统会在触发报警的时刻立即触发快照，在系统上抓一些现场信息，现场快照信息包含：占用 CPU 较高的线程排名、JVM 内存堆栈信息、网络信息以及磁盘 io 信息等。在发出告警通知的同时提供该快照信息的访问链接。快照页面同时也会列出该告警前后半小时内各种指标的趋势情况，供研发去定位问题。要注意的一点是我们在存储快照信息时没有把快照存到统一的服务端，而是直接存在机器里面。其原因是 JVM 内存堆栈通常较大，若将快照信息发送至远端统一存储那么势必增加网络压力，可能会影响到业务的正常运行。

另外我们也在根因分析上做了一些尝试。在做根因分析的时候，我们首先要做的就是要把指标和应用的一些关联拓扑构建出来。指标和应用的拓扑依赖关系应该如何去构建呢？这主要依赖于分布式跟踪系统进行自动探测应用拓扑。但在实际应用中，通常我们探测的拓扑关系比较复杂需要结合人工标注的方式为拓扑增加相应的权重作为拓扑依赖关系的一个修正。有了应用拓扑之间的依赖关系之后，基于大量历史告警数据进行自学习，分析每个故障时间点应用和指标之间的关联关系汇总为知识库数据，并存储到知识库系统。这个不断完善的知识库系统可以作为研发定位问题的依据，也可以作为故障自动处理的依据，还可以作为运维机器人的知识来源。同时，知识库也支持人工添加一些常见的故障以及故障原因并给予较高的分析权重。基于不断修正的业务拓扑关系，系统就可以自动找出一个或几个故障的根因。

APM 在京东物流的落地实践

关于 APM，Google Dapper 可以说是所有 APM 产品的鼻祖。基于 Dapper，近年来也出现了非常多的优秀的 APM 产品。比如商业化的 APM 厂商：New Relic/ 听云等，还有一些比较优秀的开源项目：Pinpoint/Zipkin/Cat/EagleEye/OpenTracing/SkyWalking 等。各种 APM 产品各有优劣，结合自身业务需求并充分对比分析后我们选择基于 pinpoint 进行二次开发实现 APM。它的缺点在于性能方面比 Zipkin、SkyWalking 要差一点，但是 pinpoint 也有项目不具备的优势，比如接入简单无需修改代码，再比如可以跟踪到代码级别等等。目前有很多国内外的厂商都在做 APM 的产品，如果企业计划做 AIOps 的话我们不推荐直接使用厂商的产品，因为厂商的 APM 底层数据对客户是不透明的。而自主研发 APM 平台最大的意义在于 APM 里面有大量的数据是我们可以使用的，通过对这些基础数据进行大数据分析以及数据挖掘之后，可以为 AIOps 提供很多数据来源。如果使用厂商的产品，在很多方面底层数据的使用就不是那么自由了。

下面介绍一下我们在 APM 方面的进展，我们基于 pinpoint 开发的 Jtrace 分布式跟踪系统拥有 7 大能力：

分布式事务跟踪
自动检测应用拓扑
水平扩展支持大规模服务集群
代码级别的可见性，这是相对于其他产品最大的不同，它可以跟踪方法堆栈，特别清晰。
使用字节码增强
集成了 SQLAdvisor，在抓到 SQL 之后，我们会分析到哪些是比较慢的 SQL，慢的 SQL 到底慢在哪里，我们可以通过这个给出一些优化建议
智能化采样率，基于业务访问量自动调整采样率，大大降低了业务性能方面的开销

关于性能方面，我们从以下几个方面进行了优化：

使用二进制格式（thrift 协议），高压缩比，在网络传输上可以减轻很多开销。
使用变长编码和格式优化数据记录（thrift CompactProtocol）
用常量表替换重复的 API 信息，SQL 语句和字符串
智能采样率
使用异步数据传输来最小化应用线程中止
使用 UDP 协议传输数据

优化后性能损失与目前流行的 Zipkin 相近。相对于我们获取的数据精度来说，这个是可以接受的结果。

AIOps 的落地规划

下面我们谈谈今天的最后一个主题：AIOps 的落地规划。

前面已经有提及，AIOps 主要从发现问题、解决问题、规避问题三个方面来设计和实施。对于发现问题，很多在做 AIOps 的厂商都已经做的很完善了，包括异常检测，根因分析、智能告警、性能分析、事件分析、日志分析等。对于解决问题这一块，整个业界还处在一个探索的阶段，我们的思路是以自学习结合人工标注的知识库为基础整合异常反馈、深度学习、决策树等 AI 技术，实现故障自动处理。针对非危险处理动作实施自动处理并记录日志，对于高危操作则通过流程审批确认后执行。针对规避问题这一目标，则是我们对于 AIOps 的愿景。我们希望通过对大数据的分析和预测能够对容量、性能、故障进行精准预测，并提前做好自动应对措施以避免问题的产生。如果实现了这个目标，那么 AIOps 算是真正落地了。