得物云原生全链路追踪Trace2。0采集篇

　　一、0xcc开篇
　　2020年3月，得物技术团队在三个月的时间内完成了整个交易体系的重构，交付了五彩石项目，业务系统也进入了微服务时代。系统服务拆分之后，虽然每个服务都会有不同的团队各司其职，但服务之间的依赖也变得复杂，对服务治理等相关的基础建设要求也更高。
　　对服务进行监控是服务治理、稳定性建设中的一个重要的环节，它能帮助提早发现问题，预估系统水位，以及对故障进行分析等等。从2019年末到现在，得物的应用服务监控系统经历了三大演进阶段，如今，整个得物的应用微服务监控体系已经全面融入云原生可观测性技术OpenTelemetry。
　　回顾过去十年间，应用服务监控行业的竞争也很激烈，相关产品如雨后春笋般涌现，如推特在2012年开源的Zipkin，韩国最大的搜索引擎和门户网站Naver开源的Pinpoint，近几年Uber公司开源的Jaeger，以及我们国内吴晟开源的SkyWalking。
　　有人说，这些其实都归功于Google在2010年基于其内部大规模分布式链路追踪系统Dapper实践而发表的论文，它的设计理念是一切分布式调用链追踪系统的始祖，但其实早在二十年前（2002年），当年世界上最大的电商平台eBay就已拥有了调用链追踪系统CAL（CentralizedApplicationLogging）。2011年，原eBay的中国研发中心的资深架构师吴其敏跳槽至大众点评，并且深入吸收消化了CAL的设计思想，主导研发并开源了CAT（CentralizedApplicationTracking）。
　　CAT作为国人主导的开源系统，其本地化工作也是做得非常到位，而凭借着架构简单，开箱即用的特点，CAT也是我们得物使用的第一个应用监控系统。
　　二、0x01第一阶段
　　从01基于CAT的实时应用监控
　　在得物五彩石项目交付之前，系统仅有基础设施层面的监控，CAT的引入，很好地弥补了应用监控盲区。它支持提供各个维度的性能监控报表，健康状况检测，异常统计，对故障问题排查起到了积极推动的作用，同时也提供简单的实时告警的能力。
　　CAT拥有指标分钟级别的聚合统计的能力，从UI上不难看出，它拥有丰富的报表统计能力和问题排障能力。
　　但随着公司业务规模逐步扩大，微服务粒度也不可避免地变小，我们发现，CAT已经逐步无法满足我们的使用场景了：无法直观呈现全链路视图：
　　问题排障与日常性能分析的场景也越来越复杂，对于一个核心场景，其内部的调用链路通常复杂多变，站在流量角度上看，需要完整地知道它的来源，上下游链路，异步调用等等，这对于CAT来说可能略显超纲。缺少图表定制化能力：
　　CAT虽供多维度报表分析，但定制化能力非常有限，在当时，业内的图表组件定制化解决方案逐步向GrafanaPrometheus靠拢，但若使用CAT，则无法享受强大的图表绘制能力。与此同时，随着云原生社区可观测性项目OpenTracing的崛起，大约不到半年时间我们逐步下线了CAT，向OpenTracing生态演进。
　　三、0x02第二阶段
　　持续创造基于OpenTracing全链路采样监控
　　OpenTracing为全链路追踪Trace定制了完整的一套协议标准，本身并不提供实现细节。在OpenTracing协议中，Trace被认为是Span的有向无环图（DAG）。官方也例举了以下8个Span的因果关系和他们组成的单Trace示例图：
　　在当时，OpenTracing相关的开源社区也是异常活跃，它使用Jaeger来解决数据的收集，调用链则使用了甘特图展示：
　　在OpenTracing生态中，我们对链路的采样使用头部采样策略，对于指标Metrics，OpenTracing并没有制定它的规范，但在GoogleSREBook里，关于MonitoringDistributedSystem章节中提到了四类黄金指标：1。吞吐量：如每秒请求数，通常的实现方式是，设定一个计数器，每完成一次请求将自增。通过计算时间窗口内的变化率来计算出每秒的吞吐量。
　　2。延迟：处理请求的耗时。
　　3。错误率错误数：如HTTP500错误。当然，有些即便是HTTP200状态也需要根据特定业务逻辑来区分当前请求是否属于错误请求。
　　4。饱和度：类似服务器硬件资源如CPU，内存，网络的使用率等等。
　　所以，我们决定使用Micrometer库来对各个组件进行吞吐量，延迟和错误率的埋点，从而对DB类，RPC类的组件做性能监控。因此也可以说，我们第二阶段的监控是以指标监控为主，调用链监控为辅的应用性能监控。
　　3。1使用Endpoint贯穿指标埋点帮助性能分析
　　在指标埋点过程中，我们在所有的指标中引入了流量入口（Endpoint）标签。这个标签的引入，实现了根据不同流量入口来区分关联DB，缓存，消息队列，远程调用类的行为。通过流量入口，贯穿了一个实例的所有组件指标，基本满足了以下场景的监控：RPC调用排障，调用方除了拥有下游接口信息，也可溯源自身触发该调用的接口。
　　接口高耗时分析，根据指标，可还原出单位时间窗口的耗时分解图快速查看耗时组件。
　　3。2关于选型的疑问
　　你可能会问，链路监控领域在业内有现成的APM产品，比如Zipkin，Pinpoint，SkyWalking等，为什么当时会选择OpenTracingPrometheus自行埋点？主要有两大因素：
　　第一，在当时，CAT无法满足全链路监控和一些定制化的报表分析，而得物交易链路五彩石项目交付也趋于尾声，贸然去集成外部一款庞大的APM产品在没有充分的验证下，会给服务带来稳定性风险，在极其有限的时间周期内不是个理智的选择。
　　第二，监控组件是随着统一的基础框架来发布，同时，由另一团队牵头开发的全链路影子库路由组件借助了OpenTracing随行数据透传机制，且与监控组件是强耦合关系，而基础框架将统筹监控，压测和其他模块，借助SpringBootStarter机制，一定程度上做到了功能的开箱即用，无缝集成。而使用字节码增强方式的Pinpoint，SkyWalking，无法很好地做到与基础框架集成，若并行开发，也会多出基础框架与JavaAgent两边的管理和维护成本，减缓迭代速度。
　　在之后将近两年的时间里，应用服务监控覆盖了得物技术部使用的将近70的组件，为得物App在2021年实现全年99。97的SLA提供了强有力的支持。现在看来，基于OpenTracingPrometheus生态，很好地解决了分布式系统的调用链监控，借助Grafana图表工具，做到了灵活的指标监控，融合基础框架，让业务方开箱即用然而，我们说第二阶段是基于OpenTracing全链路采样监控，随着业务的高速发展，这套架构的不足点也逐渐显露出来。3。3架构特点体验层面指标：覆盖面广，维度细，能清晰地根据各模块各维度来统计分析，基本做到了监控灵活的图表配置需求。但不可否认它是一种时序聚合数据，无法细化为个体。假如在某个时间点发生过几次高耗时操作，当吞吐量达到一定时，平均耗时指标曲线仍然趋于平稳，没有明显的突出点，导致问题发现能力降低。
　　链路：1的采样率使得业务服务基本不会因调用链发送量大而导致性能问题，但同时也往往无法从错误，高耗时的场景中找到正好采样的链路。期间，我们曾经考虑将头部采样策略改为尾部采样，但面临着非常高昂的SDK改造成本和复杂调用情况下（如异步）采样策略的回溯，且无法保证发生每个高耗时，错误操作时能还原整个完整的调用链路。集成方式：业务和基础框架均采用Maven来构建项目，使用SpringBootStarterallinone开箱即用方式集成，极大降低了集成成本的同时，也给依赖冲突问题埋下了隐患。项目迭代层面
　　迭代周期分化矛盾，与基础框架的集成是当时快速推广落地全链路监控的不二选择，通过这种方式，Java服务的接入率曾一度接近100，但在业务高速发展的背景下，基础框架的迭代速度已经远远跟不上业务迭代速度了，这也间接制约了整个监控系统的迭代。数据治理层面
　　数据治理成本逐步偏高，由于基础框架和业务系统的迭代节奏天然的不一致，且每个业务系统也有自身的迭代节奏，放眼全网后端服务上看，基础框架版本参差不齐。
　　尽管监控系统在每一次迭代时都会尽可能保证最大的向后兼容，但将近两年的迭代周期里，不同版本造成的数据差异也极大制约了监控门户系统天眼的迭代，开发人员长时间奔波于数据上的妥协，在很多功能的实现上曲线救国。稳定性层面
　　相关预案依托于Spring框架Bean的自动装配逻辑，业务方理解成本低，便于变更，但缺少细粒度的预案，比如运行时期间特定逻辑降级等等。2021年下半年开始，为了充分平衡以上的收益与风险，我们决定将监控采集端与基础框架解耦，独立迭代。在此之前，在CNCF（云原生计算基金会）的推动下，OpenTracing也与OpenCensus合并成为了一个新项目OpenTelemetry。
　　四、0x03第三阶段
　　向前一步基于OpenTelemetry全链路应用性能监控
　　OpenTelemetry的定位在于可观测性领域中对遥测数据采集和语义规范的统一，有CNCF（云原生计算基金会）的加持，近两年里随着越来越多的人关注和参与，整个体系也越发成熟稳定。
　　其实，我们在2020年底就已开始关注OpenTelemetry项目，只不过当时该项目仍处于萌芽阶段，Trace，MetricsAPI还在Alpha阶段，有很多不稳定因素，考虑到需尽快投入生产使用，笔者曾在2021年中到年末期间也或多或少参与了OpenTelemetry社区相关issue的讨论，遥测模块的开发，底层数据协议的一致和一些BUG的修复。在这半年期间，相关API和SDK随着越来越多的人参与也逐步趋于稳定。
　　OpenTelemetry架构（图源自opentelemetry。io）
　　4。1迈入Trace2。0时代
　　OpenTelemetry的定位致力于将可观测性三大要素Metrics，Trace，Log进行统一，在遥测API制定上，提供了统一的上下文以便SDK实现层去关联。如Metrics与Trace的关联，笔者认为体现在OpenTelemetry在Metrics的实现上包含了对OpenMetrics标准协议的支持，其中Exemplar格式的数据打通了Trace与Metrics的桥梁：
　　OpenMetrics是建立在Prometheus格式之上的规范，做了更细粒度的调整，且基本向后兼容Prometheus格式。
　　在这之前，Metrics指标类型的数据无法精确关联到具体某个或某些Trace链路，只能根据时间戳粗略关联特定范围内的链路。这个方案的缺陷源自指标采集器vmagent每隔10s30s的Pull模式中，指标的时间戳取决于采集时刻，与Trace调用时间并不匹配。
　　Exemplar数据在直方图度量格式末尾会追加当前上下文中的TraceID，SpanID信息，如下：shadowervirtualfieldmapoperationsecondsbucket｛holderFilter：Factory，keyWebMvcMetricsFilter，operationget，tclAppClassLoader，valueServlet3FilterMappingResolverFactory，le0。2｝3949。01654575981。216｛spanid48f29964fceff582，traceidc0a80355629ed36bcd8fb1c6c89dedfe｝1。01654575979。751
　　为了采集Exemplar格式指标，同时又需防止分桶标签le产生的高基数问题，我们二次开发了指标采集vmagent，额外过滤携带Exemplar数据的指标，并将这类数据异步批量发送到了Kafka，经过Flink消费后落入Clickhouse后，由天眼监控门户系统提供查询接口和UI。
　　分位线统计与Exemplar数据关联UI示意图
　　在数据上报层，OpenTelemetryJavaSDK使用了比JDK原生的阻塞队列性能更好的Mpsc（多生产单消费）队列，它使用大量的long类型字段来做内存区域填充，用空间换时间解决了伪共享问题，减少了并发情况下的写竞争来提高性能。
　　在流量高峰时期，链路数据的发送队列这一块的性能从火焰图上看CPU占比平均小于2，日常服务CPU整体水位与0采样相比几乎没有明显差距，因此我们经过多方面压测对比后，决定在生产环境客户端侧开放链路数据的全量上报，实现了在得物技术史上的全链路100采样，终结了一直以来因为低采样率导致问题排查困难的问题，至此，在第三阶段，得物的全链路追踪技术正式迈入Trace2。0时代。
　　得益于OpenTelemetry整体的可插拔式API设计，我们二次开发了OpenTelemetryJavaInstrumentation项目ShadowerJava，扩展了诸多功能特性：4。2引入控制平面管理客户端采集行
　　使用控制平面，通过客户端监听机制来确保配置项的下发动作，包括：实时动态采样控制诊断工具Arthas行为控制实时全局降级预案遥测组件运行时开关实时RPC组件出入参收集开关实时高基数指标标签的降级控制按探针版本的预案管理基于授权数的灰度接入策略。
　　。。。。。。
　　控制平面的引入，弥补了无降级预案的空白，也提供了更加灵活的配置，支持了不同流量场景下快速变更数据采集方案：
　　4。3独立的启动模块
　　为了解决业务方因集成基础框架而长期面临的依赖冲突问题，以及多版本共存引起的数据格式分散与兼容问题，我们自研了无极探针工具箱Promise，它是个通用的javaagentlauncher，结合远端存储，支持可配置化任意javaagent的下载，更新，安装和启动：〔plugins〕enablesshadower，arthas，pyroscope，chaosagent〔shadower〕artifactkeyjavaagentshadowersfinal。jarbootclasscom。shizhuang。apm。javaagent。bootstrap。AgentBootStrapclassloadersystemdefaultversion115。16〔arthas〕artifactkeytoolsarthasbin。zip；bootclasscom。taobao。arthas。agent334。AgentBootstrapbootartifactarthasagent。jarpremainargs。attachmentsarthasarthascore。jar；；ip127。0。0。1〔pyroscope〕artifactkeytoolspyroscope。jar〔chaosagent〕artifactkeyjavaagentchaosagent。jarbootclasscom。chaos。platform。agent。DewuChaosAgentBootstrapclassloadersystemapplyenvsdev，test，local，pre，xdw
　　4。4基于OtelAPI的扩展4。4。1丰富的组件度量
　　在第二阶段OpenTracing时期，我们使用Endpoint贯穿了多个组件的指标埋点，这个优秀的特性也延续至第三阶段，我们基于底层PrometheusSDK设计了一套完善的指标埋点SDK，并且借助字节码插桩的便捷，优化并丰富了更多了组件库。（在此阶段，OpenTelemetrySDK主版本是1。3。x，相关MetricsSDK还处于Alpha阶段）
　　Otel的JavaInstrumnetation主要使用WeakConcurrentMap来做异步链路上下文数据传递和同线程上下文关联的容器，由于Otel对许多流行组件库做了增强，因此WeakConcurrentMap的使用频率也是非常高的，针对这个对象的size做监控，有助于排查因探针导致的内存泄露问题，且它的增长率一旦达到我们设定的阈值便会告警，提早进行人工干预，执行相关预案，防止线上故障发生。
　　部分自监控面板
　　4。4。2扩展链路透传协
　　1）引入RPCID
　　为了更好地关联上下游应用，让每个流量都有身份，我们扩展了TextMapPropagator接口，让每个流量在链路上都知道请求的来源，这对跨区域，环境调用排障场景起到关键性作用。
　　此外，对于跨端场景，我们参考了阿里鹰眼调用链RPCID模型，增加了RpcID字段，这个字段在每次发生跨端调用时末尾数值会自增，而对于下游应用，字段本身的层级自增：
　　该字段拥有以下作用：
　　支持提供精简化的调用链路视图，查询臃肿链路（如那些涉及缓存，DB调用大于2000Span的链路）时只提供RPC调用节点和调用层次关系。
　　链路保真，客户端链路数据上报队列并不是个无界限队列，当客户端自身调用频繁时，若上报队列堆积达到阈值即会丢弃，这会造成整个链路的不完整，当然这是预期内的现象，但若没有RpcID字段，链路视图将无法关联丢失的节点，从而导致整个链路层级混乱失真。
　　2）自定义TraceID
　　为了实现链路详情页高效的检索效率，我们扩展TraceID生成逻辑，ID的前8位使用实例IP，中8位使用当前时间戳，后16位采用随机数生成。32位自定义traceId：c0a8006b62583a724327993efd1865d8c0a8006b62583a724327993efd1865d8高8位（IP）中8位（Timestmap）低16位（Random）
　　这样的好处有两点：
　　通过TraceID反向解析时间戳，锁定时间范围，有助于提高存储库Clickhouse的检索效率，此外也能帮助决定当前的Trace应该查询热库还是冷库。
　　绑定实例IP，有助于关联当前Trace流量入口所属的实例，在某些极端场景，当链路上的节点检索不到时，也能通过实例和时间两个要素来做溯源。
　　3）异步调用识别
　　业务系统为了提高服务吞吐量，充分运用硬件资源，异步调用场景可谓无处不在。我们基于Otel实现的异步链路上下文传递的基础上，额外扩充了asyncflag字段来标识当前节点相对于父节点的调用关系，从而在展示层上能迅速找出发生异步调用的场景
　　4。4。3更清晰的调用链结构
　　在Otel支持的部分组件中，有些操作不涉及到网络调用，或者具有非常频繁的操作，如MVC过程，数据库连接获取等，通常来说这类节点在链路详情主视图中的意义不大，因此我们对这类节点的产生逻辑进行了优化调整，使得整个链路主体结构聚焦于跨端，同时，对部分核心组件关键内部方法细节做了增强，以事件的形式挂载于它们的父节点上，便于更细粒度的排查：
　　RPC调用关键内部事件
　　DB调用连接获取事件
　　4。4。4profiling的支持
　　1）线程栈分析的集成。通过集成Arthas这类工具，可以很方便地查看某个实例线程的实时堆栈信息，同时对采样间隔做控制，避免频繁抓取影响业务自身性能。
　　2）通过集成pyroscope，打通高延迟性能排查最后一公里。Pyroscope对asyncprofiler做了二次开发，同时也支持Otel去集成，但截至目前，官方并没有实现完整的Profiling行为的生命周期，而Profiling行为一定程度上会影响性能，于是我们对官方Pyroscope的生命周期做了扩展，实现停止行为的同时，采用时间轮算法来检测特定操作的耗时，当达到期望的阈值将触发开启profiling，待操作结束或超过最大阈值则停止。
　　关于性能诊断相关的运用，请期待后续诊断专题。
　　五、0xff结语
　　纵观得物在应用监控采集领域的三大里程碑迭代，第一阶段的CAT则是01的过程，它提供了应用服务对自身观测的途径，让业务方第一次真实地了解了服务运行状况，而第二阶段开始，随着业务发展的飞速提升，业务方对监控系统的要求就不仅只是从无到有了，而是要精细，准确。
　　因此，快速迭代的背景下，功能与架构演进层面的矛盾，加上外部云原生大背景下可观测领域的发展因素，促使我们进行了基于OpenTelemetry体系的第三阶段的演进。功能，产品层面均取得了优异的结果。如今，我们即将进行下一阶段的演进，深度结合调用链与相关诊断工具，以第三阶段为基础，让得物全链路追踪技术正式迈入性能分析诊断时代。
　　六、关于我们
　　得物监控团队提供一站式的可观测性平台，负责链路追踪、时序数据库、日志系统，包括自定义大盘、应用大盘、业务监控、智能告警、AIOPS等排障分析。参考文章：Dapper，aLargeScaleDistributedSystemsTracingInfrastructurehttps：storage。googleapis。compubtoolspublicpublicationdatapdf36356。pdf大众点评开源分布式监控平台CAT深度剖析阿里云开发者社区https：developer。aliyun。comarticle269295趣谈分布式链路追踪组件发展史https：xie。infoq。cnarticle8e06e8d9e43d1768e021225cbJaegerSampling
　　https：www。jaegertracing。iodocs1。39samplingAbriefhistoryofOpenTelemetry（SoFar）CloudNativeComputingFoundationhttps：www。cncf。ioblog20190521abriefhistoryofopentelemetrysofarTheOpenMetricsprojectCreatingastandardforexposingmetricsdatahttps：openmetrics。ioMergingOpenTracingandOpenCensus：ARoadmaptoConvergenceMonitoringDistributedSystems
　　文栉枫忻垣
　　关注得物技术，每周一三五晚18：30更新技术干货
　　要是觉得文章对你有帮助的话，欢迎评论转发点赞