UGeek大咖说第七期，京东商城监控负责人潘莹作客直播间主讲——京东商城可观测体系的落地与实践
直播过程中，潘老师为我们列举了云原生时代，在微服务、容器化和规模化领域所面临的挑战，针对性地给出了一些解决方法。
分享了京东在基于可观测所构建的安全生产体系，包含智能故障分析、动态资源调度、全链路观测、应用健康度这四个维度的详细讲解，向我们呈现了一个百万级容器规模系统的可观测方案。最后也与我们共同展望了京东可观测体系的未来建设。
一、云原生时代的挑战
从微服务讲起，随着应用数量的不断增加，而服务发布的频率会变得更高，复杂度也会更高，它的系统稳定性和复杂度也会随之提高，如何降低沟通成本，其实是一个很大的挑战。
容器化之后，它的调度频率也会增加，对资源率也会有更高的追求预期，这些都会要求咱们对系统的监控提出更高的要求，包括规模化起来之后，服务器变多了，故障也会更频繁，而人力是很难去追上业务的增长的，怎么把有限的人力利用在刀刃上，是比较急迫的挑战。
二、京东商城可观测的基础
京东商城可观测的基础是以APM进行串联，将监控能力SaaS化，整合各种系统的指标与数据，打造一个多视角，多维度，跨应用乃至跨部门的观测数据生态，为高级应用场景提供坚实的数据基础。
三、基于可观测搭建安全生产体系
应用健康度（防患于未然）
应用健康度，是京东基于可观测去建立安全生产体系的一个非常重要的环节，通常我们认为健康状态比较良好的应用，在当前这个状态下，它有没有存在一些隐患？这些隐患就是在正常执行的正常运行的时候并不会体现出来，当出现一些故障或者预期之外的情况，可能会对系统造成一个非常严重的打击，甚至造成一些雪崩效应，最后导致整个系统进入一个不可控的状态。
它简单来说，我们会给这个应用通过一些关键的检查项，去检查这个应用的健康情况，最后得出一个评分。评分比较低的情况，就会推动这个应用的健康治理，让这个应用始终处在一个就是它比较健壮的状态。
智能故障分析（秒级定位故障）
很多时候，我们需要快速的去定位和修复，有一部分故障虽然能自愈，但是有一些比较深层次的故障，还是需要人为的手动干预的。现阶段微服务比较多。那它的这个服务调用链可能会很深。那我怎么能快速定位到这个这个故障是不是由我自身服务的问题产生的，以及它这个故障具体的根因？如果要靠人排查的话，时间会非常长，这个时候我们会使用智能分析，首先它会去检查报警的这个服务当时的一些状况，比如有没有做发布动作，有没有修改配置，以及基础资源使用的情况等等，会用到apm系统的调用链链追踪功能。通过应用拓补和调用拓补一路往下去追，自动排查，这个速度会很快，因为等它是一个全自动的过程。
简单来说就是，从报警故障点出发，自动排查系统变更日志、基础资源状态、中间件性能表现、下游服务性能表现等指标，实现快速的故障根因定位。
弹性调度（让资源流动起来）
弹性调度调度很常见，比如上线，扩容缩容，这都是调度。但是纯靠人手动的去做调度，很难去把资源利用到极限。我们会通过一些策略去调度。根据监控数据甚至秒级监控数据，去检查系统当前的负载情况。如果当天的负载突然升高了，出现了一个比较大的波动，我们会根据预设的策略给它快速拉起新的节点，让这个系统的容量也能随着这个业务的量。能有一个快速提高。如果业务进入了闲时，那我可以把这个资源再给它缩容掉。缩掉缩掉之后再把这些资源归还到资源池里面。
全链路观测（不止是APM）
我们去打造这个系统的时候，对它寄予的期望会更多一些，首先它有应用拓补、调用链链追踪等等功能。实际上我们还希望它能承担一部分，比如说多位监控的功能，传统的应用监控的数据采集，我希望也能完成，而且应该是可以在一个多维监控的基础上去实现，比如我观测这个数据，不能是一个单一的视角，而是可以去通过多个视角去观测这个监控数据。比如我看cpu，那我除了看一个整体的平均cpu最大和最小的cpu之外，还可以分机房去看，不同的机房，它cpu的情况是怎么样的，这样我可以知道我的流量是不是均匀，不同的部署分组的cpu是一个什么情况。
直播过程中，我们的评论区出现了很多来自同学们的提问，小编已将问答部分整理成文字版，供大家温习。
问: 京东在618在发生严重故障时应急恢复方案有哪些？
答：其实是分系统、分类型的，根据不同系统的架构、特性，它解决方案，也不太一样。实际上京东开发了一个专门的应急预案系统，它会把一些预期之内的故障的解决方案在系统里面进行配置，当系统出现问题的时候，就可以直接做预案执行。这样就可以用一个比较快速的方式去排除故障。
我们内部有一个DOCC的系统，它是一个动态配置管理系统，这个应急预案里面包括一个动态的配置，比如：当发生故障时，就去动态配置系统里修改，可以达到这样的效果——如果把流量摘除，把服务切换到降级模式，这样的操作能对服务进行干预，可以配置操作类的管理管理端口的请求。
当你的系统出问题的时候，它可以自动执行一个降级的动作去对接其他的一些平台。就是提前预测了故障情况并做对应的预案，当真正出现这种故障时，就可以快速干预。
问: 对于没有自研开发apm能力的小公司，有什么好的开源工具可以监控应用系统？
答：好的监控工具有很多，比如Skywaking，Pinpoint，京东早起也有基于Pinpoint实现的内部系统，只是进行了部分模改，因为京东很多中间件是自研的，而开源监控系统跟自研的组件很难做到完美衔接，所以京东最后选择了自研。但实际上，如果量级不大，开源工具的效果也是不错的，只是可能跟其他监控系统的挂接能力没那么强，如果真的有很强的需求，还是需要去做一些自研把监控体系打通，这得根据自身情况做选择。
问: 调用链数据存储方案是怎么样的？
答：电源链数据的话，现在我们主要还是以E S为主，我们的数据也比较大，会采用采样的策略。不同的厂会对这个调用链数据有一个不同的处理方式，这个跟业务有关，如果说业务本身的调用量级并不是很大，不做采样可能全都能保存下来，如果量级比较大，比如京东，它实际上的量级很恐怖，我们现在已经把采用率调整到五千分之一，一天也有上百T的调用链数据。这就引申出一个问题：即大家很多时候会对调用链有更高的期待。其实最早调用链被提出来的时候，主要是用来解决性能瓶颈的发现，比如系统哪块功能就用调用链去发现，这是很好用的，正是因为它上报数据功能太过好用，大家总是希望用它去排查故障。
我们其实也在考虑这个问题，如果采样率太低，在排查故障方面，它就不是特别的方便,很有可能采不到。我们也在开发一个更折中的方案，比如我们可以把调用链的小片段进行后觉测试的上报，当我认为它有问题的时候，我就把这一个小片段上报上来，而不是把整个链上报上来，因为当你真的需要处理故障，一个小片段就能为你提供非常多的信息了，这是京东现阶段的方案。
问：监控数据上报存储和读取聚合的效率是如何保证的？
答：这个问题很好，在我们开发监控系统的时候，会遇到很多这方面的问题。
首先就是京东的监控系统，它在上报层面上会分成两种方式，第一个是把监控数据写到磁盘里面，然后通过一个收集程序，收集上来。然后还有一个呢，是直接通过网络上报，比如这个客户端直接把内置采集端直接内置在程序里面。所以自然也有能力通过网络上报。这两种方式其实各有好处。写磁盘呢，其实主要它就是磁盘，等于说天是一个天然的八分，也就是说当你真的出现了网络故障，如数据报不上来，实际上还有磁盘作为一个补救的手段，不好的地方就是它会提高系统的复杂度，而且他上报的数据多也不如网络上报来的快和直接。反之，网络上报快而直接。但是对网络故障的容忍能力有限，它的内部队列只能应付小小抖动，如果容器离线的时间比较长，可能就应付不过来。通常我们会根据业务情况做取舍，这两种方式不会有什么特别本质的区别。
数据上报上来之后，我们会把它存储到消息队列里面去，这时候就涉及到数据量的问题,我们会对数据进行压缩，压缩之后尽量保持数据有序，选择关键数据信息。根据关键信息做Sharding，这个数据一定会进入相同的分片（Partition）。这样能基本上保证一个有序消费。基于这个有序消费，就可以做很多性能优化，比如我可以在消费的、阶段先做一层内存的聚合，再去进行中央集群的聚合，因为通常如果想计算一个性能指标，比如算TP、TP99、TP999，是必须要做中央聚合的，否则它一定会出现有损的情况。在这种情况之下，想要避免中央缓存承受太大的压力，就得保证前面做的有序，这样压力的分摊就会好很多。
问：业务自愈都有什么场景？
答：它实际上会分成几个层次，首先是一些基础设施程度上的自愈。
举个例子，比如我我有一台服务器出现故障了，那这时候的手段就比较简单，你就直接把它的流量摘除就可以了，只要它不影响业务，那这个服务器你可以把它下线掉，然后慢慢去修，这是一种场景。再高一层次的，比如有些资源不够了，磁盘使用超过80%-90%了，这时候可能需要去清理脚本，把磁盘的容量降下来。
更高层次的网络甚至业务层面上的东西，比如流量扛不住了，就是我的系统流量已经超预期了，就需要去扩容，扩容实际上是动态调度，他可能是有一个快速的潮汐系统的一个扩容，把服务的实力，各种实力节点补充起来，去提高系统容量。但这其实也受制于业务系统本身的特性限制。因为。通常来讲，无状态的服务比较适合这种场景，但是有些有状态的服务可能就不那么适合了。
我说的那几种场景，实际上它还包括比如我做了一些自动干预之后，是不是确实解决了问题，做了磁盘清理之后，是不是确实把空间释放出来了？如果说它没有释放出来的话，可能还会去升级，进入到人工干预的环节。即使完成了自愈，可能也是需要有一个报告发出来，告诉我确实是完成了，也需要其它后续检查性的环节。
UGeek大咖说大厂可观测系列往期回顾：UGeek大咖说第八期【美图专场】
