LinkedIn用OpenTelemetry：打通前端点击与后端追踪

LinkedIn 搭了一套基于 OpenTelemetry 的遥测平台，把用户在 iOS、Android 和 Web 应用里的操作，跟处理这些交互的后端服务串到了一起。

这么做是为了补上一个常见的可观测性缺口。客户端分析能看到用户点了哪个按钮、在哪儿遇到了报错，后端追踪则能呈现请求在服务内部经历了什么。过去要把这两类信息对上，工程师得手动去对接好几个彼此独立的系统。LinkedIn 这套方案则可以从客户端交互出发，穿过前端和后端服务，一路追到底层的数据存储。

一个页面可能发出大量请求，每个请求又可能经过多个服务。为此 LinkedIn 引入了 pageForestId，在单条分布式追踪之上再提供一层上下文信息。

每个请求照旧保留 OpenTelemetry 的 traceId，而来自同一页面上下文的相关请求，则通过 pageForestId 关联起来。这样一来，工程师既能查单个请求，也能看清影响用户体验的更大范围的活动。

这一点很关键。常规的分布式追踪往往只盯一个请求，可一段完整的用户旅程里，彼此关联的请求常常是一大批。

LinkedIn 的技术栈相当杂：既有移动端和 Web 客户端，也有用 Java、Python、Go 和 Rust 写的后端服务。OpenTelemetry 在这些环境里提供了通用的埋点模型、追踪上下文和语义约定。

在标准 OpenTelemetry SDK 之上，LinkedIn 做了封装和扩展。产品团队按统一规范完成埋点，移动端生命周期、遥测数据上报、LinkedIn 私有元数据这些事都由平台统一处理。

客户端和后端应用都会生成 OpenTelemetry span，追踪上下文随着请求在系统中传播。常见的 HTTP 和 gRPC 框架会自动对常规请求路径埋点，业务团队也能在重要的业务操作上添加显式 span。

遥测数据经 Apache Kafka 传输，落到 ClickHouse 里存储，pageForestId、traceId 和时间戳提供了关联关系。工程师可以从用户可见的交互入手，往下深挖对应的后端执行情况。

每个 span 都抓下来会产生海量遥测数据，所以采样是这套架构的基础。

LinkedIn 用的是协同头部采样，保证相关的客户端和服务端活动采用一致的采样决策。经过匿名处理的用户标识用来维持整条用户旅程的采样一致性，避免出现客户端数据被采样、后端追踪却被丢弃的情况，反过来也一样。

平台还会把高价值的体验质量遥测数据和低价值的调试信息区分开。LinkedIn 估计，某些后端追踪数据里多达 90% 都能归为调试级数据。

客户端可观测性还有额外的约束。移动应用可能在遥测数据传出去之前就被挂起或终止，所以 LinkedIn 会对 span 做批处理，同时能在应用转入后台时刷新遥测数据。

哪些数据能进追踪，平台也做了控制，包括属性白名单、黑名单和内容脱敏。这一步很重要，否则分布式追踪链路可能不知不觉变成用户和应用敏感信息的泄露通道。

传统的分布式追踪工具，比如 Jaeger 和 Grafana Tempo，主要专注于跨后端服务追踪请求。Datadog 和 New Relic 这类平台则把分布式追踪与真实用户监控、应用性能监控结合在了一起。

LinkedIn 的方案与其说是在引入这些平台给不了的功能，不如说是让 OpenTelemetry 成为连接客户端和后端遥测的底座。pageForestId 模型在标准追踪之上加了更高层次的分组能力，Kafka 和 ClickHouse 则提供了定制化的摄取和存储架构。

这套方案也让 LinkedIn 对自家可观测性技术栈有了更强的控制权，业务埋点不再依赖特定的商业后端产品。

用户感知到的不是 traceId，他们感知到的是页面加载慢、操作失败或者功能异常。把这些体验和背后的分布式系统连起来，工程师就能更直接地从用户受到的影响定位到技术根因。