本文根据曹伟老师在〖deeplus直播：多云场景下核心基础设施的稳定性、高可用建设〗线上分享演讲内容整理而成。
曹伟
货拉拉技术中心核心基础设施部
JAVA资深研发
货拉拉技术中心核心基础设施部Java资深研发，致力于全链路监控体系建设，目前是货拉拉全链路Trace服务、分布式定时调度服务负责人。曾就职于平安壹钱包中间件团队，从事分布式定时调度服务研发；曾就职于阿里本地生活，从事业务研发框架的开发和维护工作。
今天的分享主要包含以下几个方面的内容：
一、监控演进史
1、行业
首先我们看一下整个监控行业的演进历史。较早的是02年eBay的CAL这么一个全链路监控产品，在eBay内部也大面积的运用，是他的前资深架构师吴其敏主导研发的。然后是10年谷歌的Dapper，这是内部做的一个监控产品并没有开源，不过发表了一篇Dapper论文，是后面很多监控产品的鼻祖，大部分都是基于Dapper论文的实现和演进；同年出现一个商用产品产品Datadog，功能比较全面，是行业一流的标杆产品。11年吴其敏从eBay离职来到美团，开发了CAT，相当于CAL的Java版实现，同时做了很多的优化、迭代，将CAT在就开源领域发扬光大，在整个开源监控领域受到的欢迎程度比较高的，整体的覆盖率也相当的高。12年Twitter的开发出了Zipkin，相当于Dapper的开源实现。同年阿里也在搞他的Eagleye（鹰眼）监控，韩国的一个Pinpoint也出现了，值得说的是他是基于字码增强技术来实现监控数据埋点，有个亮点是他的埋点非常的细致，细到底层方法维度，同时这也是个缺点，因为埋点多多少少会有点性能损耗，其次他会导致单个Trace数据的膨胀。14年，饿了么开始搞EMonitor，他对用户的一个排障思路的引导，以及用户体验都做的非常好，是我用过所有监控里面最好的一个产品。货拉拉的全链路监控体系的很多思想都是借鉴于他的，比如说我们的“所见即所得”的思想是如何运用到监控可视化建设中的。15年，华为的吴晟开发了skywalking并且将他开源，近些年发展还挺好的，加入了Apache基金会，在当前的监控领域还是比较受欢迎，特别是他在微服务体系这块支持的比较好，所以受到很多中小型公司的追捧，甚至一些大公司也在用。像我们货拉拉的全链路Trace服务初期也是基于他结合货拉拉场景进行深度定制开发的，期间也经过几次大的架构升级，这个在后面会详细的说。最近的是16年Uber的Jaeger是基于Go语言来实现，滴滴内部也在使用，目前也开源了。
2、货拉拉
接下来我们看一下货拉拉的监控演进史，我将它划分成3个阶段，分别是监控1.0、2.0和3.0时期。
1）监控1.0时期
各个业务团队独立维护一套Prometheus监控体系，也没有全链路Trace监控，缺乏统一标准，更别说治理能力了，夸张一点说很多时候是客服接到投诉后把问题反馈给业务，业务才知道系统出现问题，然后再去排障，所以效率极其的低。
2）监控2.0时期
我们开始制定标准并逐步统一监控，进行监控治理，推进业务基础监控全覆盖，得益于字节码增强技术帮助我们实现业务“零代码”改造快速接入基础监控，实现监控“弯道超车”，Java核心服务监控%覆盖。同时我们也自研一些基础监控页面，结合着Grafana大盘来满足日常的监控场景。我们在中期也开始从0搭建全链路Trace服务，自研智能告警体系。
3）监控3.0时期
这个阶段我们主要针对各个监控领域专项做深度迭代和打磨，比如Trace，我们实现错、慢、核心服务完整全采样，在不影响业务排障体感的前提下，将整体存储成本降低60%。另一方面，由于历史原因Metric、Trace和Log都是各个团队独立维护的，缺乏较强的关联性，整体监控体系的价值得不到最大化，所以我们在这个阶段将他们和业务之间的指标做一个闭环的打通，来提高业务整体的排障流畅度。同时我们重新自研基础监控和业务大盘页面，给业务提供更智能便捷的大盘自助配置能力。最后我们在告警预案、根因分析等方面也有一定的研究和实践。
二、货拉拉监控体系整体架构
上图是我们货拉拉监控体系全局架构图，我们可以从下往上看。
首先是Prometheus集群，它主要进行数据的采集，可以从多个维度采集数据，比如说我们应用层，有Java、Go、PHP和Python等类型服务暴露指标数据，这里也可以看到货拉拉的语言栈比较丰富。除此之外，还可以通过Push-Gateway来获取像大数据场景下的一些数据，还有一些系统级别的监控数据，比如CPU、网络指标，通过Export暴露出来，K8S指标等。
再看中间层，左边的应用数据包含一些常规存储，比如ES和HBase，主要用来存储Trace数据。中间是时序数据库Victoria集群，Prometheus将收集到吐给这个Victoria集群进行时序数据的存储、计算以及供上层展示，同时他也承担一部分的告警的计算能力。
再往上是核心应用层，比如Trace数据的收集和展示层、指标数据展示层，还有智能告警服务等。简单来说就是Prometheus+Victoria实现Metric指标服务，然后用Skywalking搭建Trace服务。当然我们Skywalking的基础上做了很多的升级改造，后面会说。在这些数据基础上，我们自研了智能告警、预案系统，这就是货拉拉整体的全链路监控体系架构。三、监控埋点
1、JAVASDK图谱
上图是我们的JAVA埋点SDK图谱，整体看各基础组件都覆盖到了非常完善。
客户端：支持自研的SOAClient，支持市面上主流的同步、异步HttpClient；
服务端：同样支持自研的SOA，主流的Tomcat、Undertow以及Webflux异步埋点都支持得非常好；
基础服务层面：支持Job、全链路灰度和Log等；
数据DB层：支持当前主流的组件、客户端和版本，整体的覆盖率能达到%，完全能满足当前货拉拉复杂的场景。
我们所有的埋点完全基于字节码增强技术实现代码“零侵入”。实现业务“零代码”改造“一键快速接入”，这是我们实现“弯道超车”的基础。
2、什么是字节码增强技术？
1）字节码增强技术的应用-热修复Log4j2漏洞
我们一直在讲字节码增强技术，那么到底什么是字节码增强技术呢？因为时间原因这里不会跟大家详细升入原理，但希望通过下面这节让大家对这个技术能有个全面的认识。
这里举了一个大家非常熟悉的Log4j2漏洞的例子，正常的业务服务能通升级迭代来修复这个BUG，但是有一些基础服务，比如说一些开源的Kafka和ES并不能通过简单的升级来解决。首先升级版本可能会存在数据不兼容或者服务端和客户端版本不兼容问题，甚至仅仅是重启也可能对依赖的业务方服务产生不小的抖动。所以要求我们提出不重启服务的热修复方案，这里就可以基于字节码增强技术来实现服务的热更新，实际上我们提供出去的AgentJar帮助整个货拉拉数千个基础服务节点实现热更新，来完美修复这个Bug。
这里的修复其实很简单，只涉及到一行代码的改动，在lookup这个方法进入之初就returnnull，避免执行下面的可能产生BUG的代码，那这个Bug自然就解决了。
那具体改如何做呢？这里我们需要明白下面2个概念：
谁去修改字节码，就是字节码修改框架做的事。针对字节码修复框架，后面列了3个主流框架会逐一介绍。
修改后的字节码数据是怎么生效的，主要由JavaAgent技术来实现。
2）JavaAgent技术
这里我们先看一下JavaAgent是个什么东西？我们知道Class数据最终是被加载到JVM内存里，我们如果要在运行是修改Class数据其实是有2个契机：
在Class文件被加载到JVM之前，对他做修改，将修改后的数据加载到JVM内存中。
针对已经加载到JVM中的数据，在JAVA7之后的版本，是支持把JVM内存里面的Class数据捞出来修改增强然后再放回去，覆盖之前老的数据，这样能达到一个替换、增强的效果。
所以简单说，JavaAgent技术就是一套支持运行时动态修改JVM内存中的Class数据的技术或者手段。
上图是JavaAgen核心原理图，我们主要