How LinkedIn Connects User Actions to Backend Traces with OpenTelemetry

LinkedIn has built an OpenTelemetry-based platform that connects actions in its iOS, Android and web apps to the backend services handling them. The aim is to close a visibility gap: client analytics can show a click or an error, while backend traces show what happened inside services, but linking the two has often required engineers to work across separate systems.

A page can generate many requests, each passing through multiple services. LinkedIn keeps the standard OpenTelemetry traceId for individual requests and adds a pageForestId to group requests from the same page context. Engineers can therefore inspect one request or follow the broader activity associated with a user interaction.

The platform spans clients and backend services written in Java, Python, Go and Rust. LinkedIn wraps and extends standard OpenTelemetry SDKs to give product teams a consistent way to instrument their applications while the platform handles concerns such as mobile app lifecycles, telemetry upload and LinkedIn-specific metadata. HTTP and gRPC frameworks instrument common request paths automatically; teams can also add spans for important business operations. Telemetry travels through Apache Kafka and is stored in ClickHouse, where pageForestId, traceId and timestamps support correlation.

Sampling and data controls are central to the design. LinkedIn uses coordinated head-based sampling so related client and server activity receives consistent sampling decisions. Anonymized user identifiers help maintain that consistency across a user journey. According to LinkedIn, as much as 90% of some backend tracing data may be classified as debug-level data, so the platform distinguishes higher-value experience-quality telemetry from lower-value debugging information.

On mobile devices, spans are batched, with telemetry flushed when an app moves to the background to account for apps being suspended or terminated before upload. Attribute allowlists, blocklists and content redaction control what enters traces, reducing the risk of exposing sensitive user or application information.

The approach does not hinge on a tracing feature unavailable elsewhere. Its distinction is using OpenTelemetry as a common foundation for client and backend data, with pageForestId adding a grouping layer above individual traces and Kafka and ClickHouse providing LinkedIn’s ingestion and storage architecture. That gives engineers a way to start with a user-visible problem—such as a slow page or failed action—and examine the backend activity associated with it.

Original article (InfoQ China), published November 12, 2026.