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

一、0xcc开篇

2020年3月，得物技术团队在三个月的时间内完成了整个交易体系的重构，交付了五彩石项目，业务系统也进入了微服务时代。系统服务拆分之后，虽然每个服务都会有不同的团队各司其职，但服务之间的依赖也变得复杂，对服务治理等相关的基础建设要求也更高。

对服务进行监控是服务治理、稳定性建设中的一个重要的环节，它能帮助提早发现问题，预估系统水位，以及对故障进行分析等等。从 2019 年末到现在，得物的应用服务监控系统经历了三大演进阶段，如今，整个得物的应用微服务监控体系已经全面融入云原生可观测性技术 OpenTelemetry。

640-99.png

回顾过去十年间，应用服务监控行业的竞争也很激烈，相关产品如雨后春笋般涌现，如推特在 2012 年开源的 Zipkin，韩国最大的搜索引擎和门户网站 Naver 开源的 Pinpoint，近几年 Uber 公司开源的 Jaeger，以及我们国内吴晟开源的 SkyWalking。

有人说，这些其实都归功于 Google 在 2010 年基于其内部大规模分布式链路追踪系统 Dapper 实践而发表的论文，它的设计理念是一切分布式调用链追踪系统的始祖，但其实早在二十年前（2002年），当年世界上最大的电商平台 eBay 就已拥有了调用链追踪系统 CAL(Centralized Application Logging)。2011 年，原eBay的中国研发中心的资深架构师吴其敏跳槽至大众点评，并且深入吸收消化了 CAL 的设计思想，主导研发并开源了CAT(Centralized Application Tracking）。

640-100.png

CAT 作为国人主导的开源系统，其本地化工作也是做得非常到位，而凭借着架构简单，开箱即用的特点，CAT 也是我们得物使用的第一个应用监控系统。

二、 0x01 第一阶段

从0～1基于CAT的实时应用监控

在得物五彩石项目交付之前，系统仅有基础设施层面的监控，CAT 的引入，很好地弥补了应用监控盲区。它支持提供各个维度的性能监控报表，健康状况检测，异常统计，对故障问题排查起到了积极推动的作用，同时也提供简单的实时告警的能力。

640-101.png

CAT 拥有指标分钟级别的聚合统计的能力，从 UI 上不难看出，它拥有丰富的报表统计能力和问题排障能力。

640-102.png

但随着公司业务规模逐步扩大，微服务粒度也不可避免地变小，我们发现，CAT 已经逐步无法满足我们的使用场景了：

• 无法直观呈现全链路视图：

问题排障与日常性能分析的场景也越来越复杂，对于一个核心场景，其内部的调用链路通常复杂多变，站在流量角度上看，需要完整地知道它的来源，上下游链路，异步调用等等，这对于 CAT 来说可能略显超纲。

• 缺少图表定制化能力：

CAT 虽供多维度报表分析，但定制化能力非常有限，在当时，业内的图表组件定制化解决方案逐步向 Grafana + Prometheus 靠拢，但若使用 CAT，则无法享受强大的图表绘制能力。与此同时，随着云原生社区可观测性项目 OpenTracing 的崛起，大约不到半年时间我们逐步下线了 CAT，向 OpenTracing 生态演进。

三、 0x02 第二阶段

持续创造 基于OpenTracing全链路采样监控

OpenTracing 为全链路追踪 Trace 定制了完整的一套协议标准，本身并不提供实现细节。在 OpenTracing 协议中，Trace 被认为是 Span 的有向无环图（DAG）。官方也例举了以下 8 个 Span 的因果关系和他们组成的单 Trace示例图：

640-103.png

在当时， OpenTracing 相关的开源社区也是异常活跃，它使用 Jaeger 来解决数据的收集，调用链则使用了甘特图展示：

640-104.png

在 OpenTracing 生态中，我们对链路的采样使用头部采样策略， 对于指标 Metrics，OpenTracing 并没有制定它的规范，但在 Google SRE Book 里，关于 Monitoring distributed System 章节中提到了四类黄金指标：

吞吐量：如每秒请求数，通常的实现方式是，设定一个计数器，每完成一次请求将自增。通过计算时间窗口内的变化率来计算出每秒的吞吐量。 延迟：处理请求的耗时。 错误率/错误数：如 HTTP 500 错误。当然，有些即便是 HTTP 200 状态也需要根据特定业务逻辑来区分当前请求是否属于“错误”请求。 饱和度：类似服务器硬件资源如cpu,内存,网络的使用率等等。

所以，我们决定使用 Micrometer 库来对各个组件进行吞吐量，延迟和错误率的埋点，从而对 DB 类，RPC类的组件做性能监控。因此也可以说，我们第二阶段的监控是以指标监控为主，调用链监控为辅的应用性能监控。

3.1 使用 Endpoint 贯穿指标埋点帮助性能分析

在指标埋点过程中，我们在所有的指标中引入了“流量入口（Endpoint）”标签。这个标签的引入，实现了根据不同流量入口来区分关联 DB，缓存，消息队列，远程调用类的行为。通过流量入口，贯穿了一个实例的所有组件指标，基本满足了以下场景的监控：

• RPC 调用排障，调用方除了拥有下游接口信息，也可溯源自身触发该调用的接口。

640-105.png

• 接口高耗时分析，根据指标，可还原出单位时间窗口的耗时分解图快速查看耗时组件。

640-106.png

3.2 关于选型的疑问

你可能会问，链路监控领域在业内有现成的 APM 产品，比如 Zipkin, Pinpoint, SkyWalking 等，为什么当时会选择 OpenTracing + Prometheus 自行埋点？主要有两大因素：

第一，在当时，CAT 无法满足全链路监控和一些定制化的报表分析，而得物交易链路五彩石项目交付也趋于尾声，贸然去集成外部一款庞大的 APM 产品在没有充分的验证下，会给服务带来稳定性风险，在极其有限的时间周期内不是个理智的选择。

第二，监控组件是随着统一的基础框架来发布，同时，由另一团队牵头开发的全链路影子库路由组件借助了 OpenTracing 随行数据透传机制，且与监控组件是强耦合关系，而基础框架将统筹监控，压测和其他模块，借助Spring Boot Starter 机制，一定程度上做到了功能的开箱即用，无缝集成。而使用字节码增强方式的 Pinpoint, SkyWalking，无法很好地做到与基础框架集成，若并行开发，也会多出基础框架与 Java Agent 两边的管理和维护成本，减缓迭代速度。

640-107.png

在之后将近两年的时间里，应用服务监控覆盖了得物技术部使用的将近 70% 的组件，为得物App在 2021 年实现全年 99.97% 的 SLA 提供了强有力的支持。现在看来，基于 OpenTracing + Prometheus 生态，很好地解决了分布式系统的调用链监控，借助 Grafana 图表工具，做到了灵活的指标监控，融合基础框架，让业务方开箱即用…然而，我们说第二阶段是基于 OpenTracing 全链路采样监控，随着业务的高速发展，这套架构的不足点也逐渐显露出来。

3.3 架构特点

• 体验层面
  • 指标：覆盖面广，维度细，能清晰地根据各模块各维度来统计分析，基本做到了监控灵活的图表配置需求。但不可否认它是一种时序聚合数据，无法细化为个体。假如在某个时间点发生过几次高耗时操作，当吞吐量达到一定时，平均耗时指标曲线仍然趋于平稳，没有明显的突出点，导致问题发现能力降低。

640-108.png

• • 链路：1%的采样率使得业务服务基本不会因调用链发送量大而导致性能问题，但同时也往往无法从错误，高耗时的场景中找到正好采样的链路。期间，我们曾经考虑将头部采样策略改为尾部采样，但面临着非常高昂的 SDK 改造成本和复杂调用情况下（如异步）采样策略的回溯，且无法保证发生每个高耗时，错误操作时能还原整个完整的调用链路。‍
  • 集成方式：业务和基础框架均采用 Maven 来构建项目，使用 Spring Boot Starter "all in one"开箱即用方式集成，极大降低了集成成本的同时，也给依赖冲突问题埋下了隐患。‍
• 项目迭代层面

迭代周期分化矛盾，与基础框架的集成是当时快速推广落地全链路监控的不二选择，通过这种方式，Java 服务的接入率曾一度接近100%，但在业务高速发展的背景下，基础框架的迭代速度已经远远跟不上业务迭代速度了，这也间接制约了整个监控系统的迭代。

• 数据治理层面

数据治理成本逐步偏高，由于基础框架和业务系统的迭代节奏天然的不一致，且每个业务系统也有自身的迭代节奏，放眼全网后端服务上看，基础框架版本参差不齐。

640-109.png

尽管监控系统在每一次迭代时都会尽可能保证最大的向后兼容，但将近两年的迭代周期里，不同版本造成的数据差异也极大制约了监控门户系统天眼的迭代，开发人员长时间奔波于数据上的妥协，在很多功能的实现上曲线救国。

• 稳定性层面

相关预案依托于 Spring 框架 Bean 的自动装配逻辑，业务方理解成本低，便于变更，但缺少细粒度的预案，比如运行时期间特定逻辑降级等等。

• 2021 年下半年开始，为了充分平衡以上的收益与风险，我们决定将监控采集端与基础框架解耦，独立迭代。在此之前，在 CNCF（云原生计算基金会）的推动下，OpenTracing 也与 OpenCensus 合并成为了一个新项目 OpenTelemetry。

640-110.png

四、 0x03 第三阶段

向前一步 基于OpenTelemetry全链路应用性能监控

OpenTelemetry 的定位在于可观测性领域中对遥测数据采集和语义规范的统一，有 CNCF (云原生计算基金会)的加持，近两年里随着越来越多的人关注和参与，整个体系也越发成熟稳定。

其实，我们在2020年底就已开始关注 OpenTelemetry 项目，只不过当时该项目仍处于萌芽阶段， Trace, Metrics API 还在 Alpha 阶段，有很多不稳定因素，考虑到需尽快投入生产使用，笔者曾在 2021 年中到年末期间也或多或少参与了 OpenTelemetry 社区相关 issue 的讨论，遥测模块的开发，底层数据协议的一致和一些 BUG 的修复。在这半年期间，相关 API 和 SDK 随着越来越多的人参与也逐步趋于稳定。

OpenTelemetry架构（图源自 opentelemetry.io）

640-111.png

4.1 迈入 Trace2.0 时代

OpenTelemetry 的定位致力于将可观测性三大要素 Metrics,Trace,Log 进行统一，在遥测 API 制定上，提供了统一的上下文以便 SDK 实现层去关联。如 Metrics 与 Trace 的关联，笔者认为体现在 OpenTelemetry 在 Metrics 的实现上包含了对 OpenMetrics 标准协议的支持，其中 Exemplar 格式的数据打通了 Trace 与 Metrics 的桥梁：

640-112.png

OpenMetrics 是建立在 Prometheus 格式之上的规范，做了更细粒度的调整，且基本向后兼容 Prometheus 格式。

在这之前，Metrics 指标类型的数据无法精确关联到具体某个或某些 Trace 链路，只能根据时间戳粗略关联特定范围内的链路。这个方案的缺陷源自指标采集器 vmagent 每隔 10s~30s 的 Pull 模式中，指标的时间戳取决于采集时刻，与 Trace 调用时间并不匹配。

640-113.png

Exemplar 数据在直方图度量格式末尾会追加当前上下文中的 Trace ID,Span ID 信息，如下：

shadower_virtual_field_map_operation_seconds_bucket{holder="Filter:Factory",key="WebMvcmetricsFilter",operation="get",tcl="AppClassLoader",value="Servlet3FilterMappingResolverFactory",le="0.2"} 3949.0 1654575981.216 # {span_id="48f29964fceff582",trace_id="c0a80355629ed36bcd8fb1c6c89dedfe"} 1.0 1654575979.751

为了采集 Exemplar 格式指标，同时又需防止分桶标签“le”产生的高基数问题，我们二次开发了指标采集 vmagent，额外过滤携带 Exemplar 数据的指标，并将这类数据异步批量发送到了 Kafka，经过 Flink 消费后落入 Clickhouse 后，由天眼监控门户系统提供查询接口和UI。

640-114.png

分位线统计与Exemplar 数据关联UI示意图

640-19.jpeg

在数据上报层，OpenTelemetry Java SDK 使用了比 JDK 原生的阻塞队列性能更好的 Mpsc (多生产单消费）队列，它使用大量的 long 类型字段来做内存区域填充，用空间换时间解决了伪共享问题，减少了并发情况下的写竞争来提高性能。

在流量高峰时期，链路数据的发送队列这一块的性能从火焰图上看 cpu 占比平均小于2%，日常服务cpu整体水位与0采样相比几乎没有明显差距，因此我们经过多方面压测对比后，决定在生产环境客户端侧开放链路数据的全量上报，实现了在得物技术史上的全链路 100% 采样，终结了一直以来因为低采样率导致问题排查困难的问题，至此，在第三阶段，得物的全链路追踪技术正式迈入 Trace2.0 时代。

得益于 OpenTelemetry 整体的可插拔式 API 设计，我们二次开发了 OpenTelemetry Java Instrumentation 项目 Shadower Java，扩展了诸多功能特性：

4.2 引入控制平面管理客户端采集行

@H_399_404@

640-115.png