本文正在参加「金石计划 . 瓜分6万现金大奖」

一、0xcc开篇

2020年3月，得物技能团队在三个月的时刻内完成了整个买卖体系的重构，交给了五彩石项目，事务体系也进入了微服务年代。体系服务拆分之后，虽然每个服务都会有不同的团队各司其职，但服务之间的依靠也变得复杂，对服务办理等相关的根底建设要求也更高。

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

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

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

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

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

CAT 作为国人主导的开源体系，其本地化作业也是做得十分到位，而凭借着架构简单，开箱即用的特色，CAT 也是咱们得物运用的第一个运用监控体系。

二、 0x01 第一阶段

从0～1依据CAT的实时运用监控

在得物五彩石项目交给之前，体系仅有根底设施层面的监控，CAT 的引进，很好地补偿了运用监控盲区。它支撑供给各个维度的功用监控报表，健康状况检测，反常核算，对毛病问题排查起到了活泼推动的作用，一起也供给简单的实时告警的才能。

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

CAT 具有目标分钟级别的聚合核算的才能，从 UI 上不难看出，它具有丰厚的报表核算才能和问题排障才能。

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

但跟着公司事务规划逐渐扩展，微服务粒度也不可避免地变小，咱们发现，CAT 现已逐渐无法满意咱们的运用场景了：

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

问题排障与日常功用剖析的场景也越来越复杂，关于一个中心场景，其内部的调用链路一般复杂多变，站在流量角度上看，需求完好地知道它的来历，上下游链路，异步调用等等，这关于 CAT 来说可能略显超纲。

  • 短少图表定制化才能：

CAT 虽供多维度报表剖析，但定制化才能十分有限，在其时，业界的图表组件定制化处理计划逐渐向 Grafana + Prometheus 挨近，但若运用 CAT，则无法享受强壮的图表制作才能。与此一起，跟着云原生社区可观测性项目 OpenTracing 的崛起，大约不到半年时刻咱们逐渐下线了 CAT，向 OpenTracing 生态演进。

三、0x02 第二阶段

持续创造 依据OpenTracing全链路采样监控

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

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

在其时， OpenTracing 相关的开源社区也是反常活泼，它运用 Jaeger 来处理数据的搜集，调用链则运用了甘特图展现：

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

在 OpenTracing 生态中，咱们对链路的采样运用头部采样战略， 关于目标 Metrics，OpenTracing 并没有拟定它的规范，但在 Google SRE Book 里，关于 Monitoring Distributed System 章节中提到了四类黄金目标：

  1. 吞吐量：如每秒恳求数，一般的完成办法是，设定一个计数器，每完成一次恳求将自增。通过核算时刻窗口内的变化率来核算出每秒的吞吐量。

  2. 推迟：处理恳求的耗时。

  3. 过错率/过错数：如 HTTP 500 过错。当然，有些即便是 HTTP 200 状况也需求依据特定事务逻辑来区分其时恳求是否属于“过错”恳求。

  4. 饱和度：类似服务器硬件资源如CPU,内存,网络的运用率等等。

所以，咱们决议运用 Micrometer 库来对各个组件进行吞吐量，推迟和过错率的埋点，然后对 DB 类，RPC类的组件做功用监控。因而也可以说，咱们第二阶段的监控是以目标监控为主，调用链监控为辅的运用功用监控。

3.1 运用 Endpoint 贯穿目标埋点协助功用剖析

在目标埋点进程中，咱们在一切的目标中引进了“流量进口（Endpoint）”标签。这个标签的引进，完成了依据不同流量进口来区分相关 DB，缓存，音讯行列，远程调用类的行为。通过流量进口，贯穿了一个实例的一切组件目标，根本满意了以下场景的监控：

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

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

  • 接口高耗时剖析，依据目标，可还原出单位时刻窗口的耗时分解图快速检查耗时组件。

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

3.2 关于选型的疑问

你可能会问，链路监控范畴在业界有现成的 APM 产品，比方 Zipkin, Pinpoint, SkyWalking 等，为什么其时会挑选 OpenTracing + Prometheus 自行埋点？首要有两大要素：

第一，在其时，CAT 无法满意全链路监控和一些定制化的报表剖析，而得物买卖链路五彩石项目交给也趋于结尾，贸然去集成外部一款巨大的 APM 产品在没有充沛的验证下，会给服务带来安稳性危险，在极其有限的时刻周期内不是个沉着的挑选。

第二，监控组件是跟着一致的根底结构来发布，一起，由另一团队牵头开发的全链路影子库路由组件凭借了 OpenTracing 随行数据透传机制，且与监控组件是强耦合联系，而根底结构将统筹监控，压测和其他模块，凭借Spring Boot Starter 机制，必定程度上做到了功用的开箱即用，无缝集成。而运用字节码增强办法的 Pinpoint, SkyWalking，无法很好地做到与根底结构集成，若并行开发，也会多出根底结构与 Java Agent 两头的办理和维护本钱，减缓迭代速度。

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

在之后将近两年的时刻里，运用服务监控掩盖了得物技能部运用的将近 70% 的组件，为得物App在 2021 年完成全年 99.97% 的 SLA 供给了强有力的支撑。现在看来，依据 OpenTracing + Prometheus 生态，很好地处理了分布式体系的调用链监控，凭借 Grafana 图表东西，做到了灵敏的目标监控，融合根底结构，让事务方开箱即用…然而，咱们说第二阶段是依据 OpenTracing 全链路采样监控，跟着事务的高速开展，这套架构的不足点也逐渐显露出来。

3.3 架构特色

  • 体验层面
    • 目标：掩盖面广，维度细，能明晰地依据各模块各维度来核算剖析，根本做到了监控灵敏的图表装备需求。但不可否认它是一种时序聚合数据，无法细化为个别。假如在某个时刻点产生过几回高耗时操作，当吞吐量达到一守时，均匀耗时目标曲线仍然趋于平稳，没有显着的突出点，导致问题发现才能降低。

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

    • 链路：1%的采样率使得事务服务根本不会因调用链发送量大而导致功用问题，但一起也往往无法从过错，高耗时的场景中找到正好采样的链路。期间，咱们曾经考虑将头部采样战略改为尾部采样，但面对着十分昂扬的 SDK 改造本钱和复杂调用情况下（如异步）采样战略的回溯，且无法保证产生每个高耗时，过错操作时能还原整个完好的调用链路。‍得物云原生全链路追踪Trace2.0-采集篇

    • 集成办法：事务和根底结构均选用 Maven 来构建项目，运用 Spring Boot Starter “all in one”开箱即用办法集成，极大降低了集本钱钱的一起，也给依靠冲突问题埋下了隐患。‍得物云原生全链路追踪Trace2.0-采集篇

  • 项目迭代层面

迭代周期分解对立，与根底结构的集成是其时快速推行落地全链路监控的不贰挑选，通过这种办法，Java 服务的接入率曾一度挨近100%，但在事务高速开展的布景下，根底结构的迭代速度现已远远跟不上事务迭代速度了，这也直接限制了整个监控体系的迭代。

  • 数据办理层面

数据办理本钱逐渐偏高，因为根底结构和事务体系的迭代节奏天然的不一致，且每个事务体系也有本身的迭代节奏，放眼全网后端服务上看，根底结构版别良莠不齐。

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

尽管监控体系在每一次迭代时都会尽可能保证最大的向后兼容，但将近两年的迭代周期里，不同版别形成的数据差异也极大限制了监控门户体系天眼的迭代，开发人员长时刻奔走于数据上的退让，在许多功用的完成上曲线救国。

  • 安稳性层面

相关预案依托于 Spring 结构 Bean 的主动安装逻辑，事务方了解本钱低，便于改变，但短少细粒度的预案，比方运行时期间特定逻辑降级等等。

  • 2021 年下半年开端，为了充沛平衡以上的收益与危险，咱们决议将监控搜集端与根底结构解耦，独立迭代。在此之前，在 CNCF（云原生核算基金会）的推动下，OpenTracing 也与 OpenCensus 兼并成为了一个新项目OpenTelemetry。

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

四、0x03 第三阶段

向前一步 依据OpenTelemetry全链路运用功用监控

OpenTelemetry 的定位在于可观测性范畴中对遥测数据搜集和语义规范的一致，有 CNCF (云原生核算基金会)的加持，近两年里跟着越来越多的人重视和参加，整个别系也越发成熟安稳。

其实，咱们在2020年末就已开端重视 OpenTelemetry 项目，只不过其时该项目仍处于萌芽阶段， Trace, Metrics API 还在 Alpha 阶段，有许多不安稳要素，考虑到需赶快投入出产运用，笔者曾在 2021 年中到年末期间也或多或少参加了 OpenTelemetry 社区相关 issue 的评论，遥测模块的开发，底层数据协议的一致和一些 BUG 的修正。在这半年期间，相关 API 和 SDK 跟着越来越多的人参加也逐渐趋于安稳。

OpenTelemetry架构（图源自 opentelemetry.io）

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

4.1 迈入 Trace2.0 年代

OpenTelemetry 的定位致力于将可观测性三大要素 Metrics,Trace,Log 进行一致，在遥测 API 拟定上，供给了一致的上下文以便 SDK 完成层去相关。如 Metrics 与 Trace 的相关，笔者认为体现在 OpenTelemetry 在 Metrics 的完成上包含了对 OpenMetrics 规范协议的支撑，其中 Exemplar 格局的数据打通了 Trace 与 Metrics 的桥梁：

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

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

在这之前，Metrics 目标类型的数据无法精确相关到详细某个或某些 Trace 链路，只能依据时刻戳大略相关特定规模内的链路。这个计划的缺陷源自目标搜集器 vmagent 每隔 10s~30s 的 Pull 方式中，目标的时刻戳取决于搜集时刻，与 Trace 调用时刻并不匹配。

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

Exemplar 数据在直方图衡量格局结尾会追加其时上下文中的 Trace ID,Span ID 信息，如下：

Plain Text

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。

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

分位线核算与Exemplar 数据相关UI示意图

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

在数据上报层，OpenTelemetry Java SDK 运用了比 JDK 原生的阻塞行列功用更好的 Mpsc (多出产单消费）行列，它运用大量的 long 类型字段来做内存区域填充，用空间换时刻处理了伪共享问题，减少了并发情况下的写竞争来进步功用。

在流量顶峰时期，链路数据的发送行列这一块的功用从火焰图上看 CPU 占比均匀小于2%，日常服务CPU整体水位与0采样相比几乎没有显着差距，因而咱们通过多方面压测比照后，决议在出产环境客户端侧开放链路数据的全量上报，完成了在得物技能史上的全链路 100% 采样，终结了一直以来因为低采样率导致问题排查困难的问题，至此，在第三阶段，得物的全链路追寻技能正式迈入 Trace2.0 年代。

得益于 OpenTelemetry 整体的可插拔式 API 规划，咱们二次开发了 OpenTelemetry Java Instrumentation 项目 Shadower Java，扩展了许多功用特性：

4.2 引进操控平面办理客户端搜集行

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

运用操控平面，通过客户端监听机制来保证装备项的下发动作，包含：

  • 实时动态采样操控
  • 确诊东西 Arthas 行为操控
  • 实时全局降级预案
  • 遥测组件运行时开关
  • 实时 RPC 组件出入参搜集开关
  • 实时高基数目标标签的降级操控
  • 按探针版别的预案办理
  • 依据授权数的灰度接入战略。

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

  • … …

操控平面的引进，补偿了无降级预案的空白，也供给了愈加灵敏的装备，支撑了不同流量场景下快速改变数据搜集计划：

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

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

4.3 独立的发动模块

为了处理事务方因集成根底结构而长时刻面对的依靠冲突问题，以及多版别共存引起的数据格局涣散与兼容问题，咱们自研了无极探针东西箱 Promise, 它是个通用的 javaagent launcher, 结合远端存储，支撑可装备化任意 javaagent 的下载，更新，安装和发动：

[plugins]
enables = shadower,arthas,pyroscope,chaos-agent
[shadower]
artifact_key = /javaagent/shadower-%s-final.jar
boot_class = com.shizhuang.apm.javaagent.bootstrap.AgentBootStrap
classloader = system
default_version = 115.16
[arthas]
artifact_key = /tools/arthas-bin.zip
;boot_class = com.taobao.arthas.agent334.AgentBootstrap
boot_artifact = arthas-agent.jar
premain_args = .attachments/arthas/arthas-core.jar;;ip=127.0.0.1
[pyroscope]
artifact_key = /tools/pyroscope.jar
[chaos-agent]
artifact_key = /javaagent/chaos-agent.jar
boot_class = com.chaos.platform.agent.DewuChaosAgentBootstrap
classloader = system
apply_envs = dev,test,local,pre,xdw

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

4.4 依据 Otel API 的扩展

4.4.1 丰厚的组件衡量

在第二阶段 OpenTracing 时期，咱们运用 Endpoint 贯穿了多个组件的目标埋点，这个优异的特性也连续至第三阶段，咱们依据底层 Prometheus SDK 规划了一套完善的目标埋点 SDK，而且凭借字节码插桩的快捷，优化并丰厚了更多了组件库。（在此阶段，OpenTelemetry SDK 主版别是 1.3.x ，相关 Metrics SDK 还处于Alpha 阶段）

Otel 的 Java Instrumnetation 首要运用 WeakConcurrentMap 来做异步链路上下文数据传递和同线程上下文相关的容器，因为 Otel 对许多流行组件库做了增强，因而 WeakConcurrentMap 的运用频率也是十分高的，针对这个目标的 size 做监控，有助于排查因探针导致的内存泄露问题，且它的增长率一旦达到咱们设定的阈值便会告警，提早进行人工干预，履行相关预案，避免线上毛病产生。

部分自监控面板

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

4.4.2 扩展链路透传协

  1. 引进RPC ID

为了更好地相关上下游运用，让每个流量都有“身份”，咱们扩展了TextMapPropagator接口，让每个流量在链路上都知道恳求的来历，这对跨区域，环境调用排障场景起到关键性作用。

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

此外，关于跨端场景，咱们参阅了阿里鹰眼调用链RPCID模型，增加了RpcID字段，这个字段在每次产生跨端调用时结尾数值会自增，而关于下游运用，字段本身的层级自增：

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

该字段具有以下作用：

支撑供给精简化的调用链路视图，查询臃肿链路（如那些涉及缓存，DB调用大于 2000 Span的链路）时只供给 RPC 调用节点和调用层次联系。

链路保真，客户端链路数据上报行列并不是个无界限行列，当客户端本身调用频频时，若上报行列堆积达到阈值即会丢弃，这会形成整个链路的不完好，当然这是预期内的现象，但若没有RpcID字段，链路视图将无法相关丢失的节点，然后导致整个链路层级混乱失真。

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

  1. 自定义 Trace ID

为了完成链路概况页高效的检索功率，咱们扩展 TraceID 生成逻辑，ID的前8位运用实例IP，中8位运用其时时刻戳，后16位选用随机数生成。

32位自定义traceId：c0a8006b62583a724327993efd1865d8
c0a8006b  62583a72   4327993efd1865d8
   |         |             |
高8位(IP) 中8位(Timestmap) 低16位(Random)

这样的好处有两点：

通过 TraceID 反向解析时刻戳，锁守时刻规模，有助于进步存储库 Clickhouse 的检索功率，此外也能协助决议其时的 Trace 应该查询热库仍是冷库。

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

绑定实例 IP，有助于相关其时 Trace 流量进口所属的实例，在某些极点场景，当链路上的节点检索不届时，也能通过实例和时刻两个要从来做溯源。

  1. 异步调用识别

事务体系为了进步服务吞吐量，充沛运用硬件资源，异步调用场景可谓无处不在。咱们依据Otel完成的异步链路上下文传递的根底上，额外扩大了”async_flag”字段来标识其时节点相关于父节点的调用联系，然后在展现层上能迅速找出产生异步调用的场景

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

4.4.3 更明晰的调用链结构

在 Otel 支撑的部分组件中，有些操作不涉及到网络调用，或许具有十分频频的操作，如 MVC 进程，数据库衔接获取等，一般来说这类节点在链路概况主视图中的含义不大，因而咱们对这类节点的产生逻辑进行了优化调整，使得整个链路主体结构聚集于“跨端”，一起，对部分中心组件关键内部办法细节做了增强，以“事情”的方式挂载于它们的父节点上，便于更细粒度的排查：

RPC调用关键内部事情

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

DB 调用衔接获取事情

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

4.4.4 profiling 的支撑

1）线程栈剖析的集成。通过集成 Arthas 这类东西，可以很方便地检查某个实例线程的实时堆栈信息，一起对采样距离做操控，避免频频抓取影响事务本身功用。

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

2）通过集成 pyroscope，打通高推迟功用排查最终一公里。Pyroscope 对 async profiler 做了二次开发，一起也支撑 Otel 去集成，但到目前，官方并没有完成完好的 Profiling 行为的生命周期，而 Profiling 行为必定程度上会影响功用，于是咱们对官方 Pyroscope 的生命周期做了扩展，完成“中止”行为的一起，选用时刻轮算法来检测特定操作的耗时，当达到希望的阈值将触发敞开 profiling, 待操作完毕或超过最大阈值则中止。

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

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

关于功用确诊相关的运用，请等待后续确诊专题。

五、 0xff 结语

纵观得物在运用监控搜集范畴的三大里程碑迭代，第一阶段的 CAT 则是 0~1 的进程，它供给了运用服务对本身观测的途径，让事务方第一次真实地了解了服务运行状况，而第二阶段开端，跟着事务开展的飞速提升，事务方对监控体系的要求就不仅只是从无到有了，而是要精密，准确。

因而，快速迭代的布景下，功用与架构演进层面的对立，加上外部云原生大布景下可观测范畴的开展要素，促进咱们进行了依据 OpenTelemetry 体系的第三阶段的演进。功用，产品层面均取得了优异的成果。如今，咱们即将进行下一阶段的演进，深度结合调用链与相关确诊东西，以第三阶段为根底，让得物全链路追寻技能正式迈入功用剖析确诊年代。

六、 关于咱们

得物监控团队供给一站式的可观测性渠道，担任链路追寻、时序数据库、日志体系，包含自定义大盘、运用大盘、事务监控、智能告警、AIOPS等排障剖析。

参阅文章：

  • Dapper, a Large-Scale Distributed Systems Tracing Infrastructure

storage.googleapis.com/pub-tools-p…

  • 大众点评开源分布式监控渠道 CAT 深度剖析-阿里云开发者社区

developer.aliyun.com/article/269…

  • 趣谈“分布式链路追寻“组件开展史xie.infoq.cn/article/8e0…

  • Jaeger Sampling

    www.jaegertracing.io/docs/1.39/s…

  • A brief history of OpenTelemetry (So Far) | Cloud Native Computing Foundation

www.cncf.io/blog/2019/0…

  • The OpenMetrics project -Creating a standard for exposing metrics data

openmetrics.io/

  • Merging OpenTracing and OpenCensus: A Roadmap to Convergence

  • Monitoring Distributed Systems

*文/栉枫忻垣

重视得物技能，每周一三五晚18:30更新技能干货

要是觉得文章对你有协助的话，欢迎评论转发点赞～