LinkedIn 构建了一个基于 OpenTelemetry 的遥测平台，将用户在 iOS、Android 和 Web 应用中的操作与处理这些交互的后端服务连接起来。
其目标是填补一个常见的可观测性缺口。客户端分析可以显示用户点击了某个按钮或遇到报错，而后端追踪则能展示请求在服务内部发生了什么。过去，想要把这两类信息关联起来，工程师需要手动对接多个独立系统。LinkedIn 的方案可以将用户交互从客户端经由前端和后端服务一直追踪到底层数据存储。
单个页面可能产生大量请求，每个请求都可能经过多个服务。LinkedIn 引入了 pageForestId，用于在单个分布式追踪之上提供上下文信息。
每个请求仍然保留 OpenTelemetry traceId，来自同一页面上下文的相关请求可以通过 pageForestId 进行关联。因此，工程师既可以排查单个请求，也可以了解影响用户体验的更广泛的活动。
这一点十分关键，因为传统分布式追踪通常只跟踪单个请求，但一段完整的用户旅程往往包含大量相互关联的请求。
LinkedIn 拥有多样化的技术栈，包括移动和 Web 客户端，以及用 Java、Python、Go 和 Rust 编写的后端服务。OpenTelemetry 为这些环境提供了通用的埋点模型、追踪上下文和语义约定。
LinkedIn 基于标准 OpenTelemetry SDK 进行了封装和扩展，使产品团队能够使用统一规范完成埋点，平台统一处理移动端生命周期、遥测数据上报、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，他们感知到的是页面加载缓慢、操作失败或功能异常。将这些体验与背后的分布式系统连接起来，工程师就能更直接地从用户影响定位到技术根因。
查看英文原文：https://www.infoq.com/news/2026/11/linkedin-opentelemetry-journey/
