The people shaping the OpenTelemetry project at Google, Meta, and Microsoft

The foundation of OpenTelemetry

OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from applications. The project is an open source, vendor-neutral observability framework. It is a CNCF graduated project. The framework formed through a merger of the OpenTracing and OpenCensus projects. Users instrument code once using these APIs and SDKs to avoid the need for re-instrumentation when they switch backends. This ability to switch backends, such as Jaeger or Prometheus, without touching application code makes the project effective.

Instrumentation and the data pipeline

Instrumentation defines how OpenTelemetry watches and records activity. Automatic instrumentation adds a library to a project to capture incoming HTTP requests or database queries without changes to the existing code. Manual instrumentation requires the developer to wrap code to create a span. A span records when an operation starts and ends. A trace is a set of related spans that describe the lifecycle of a request. A trace provides a complete record of a journey through a system. It consists of smaller units called spans. Each span records the start and end time of an operation. These individual spans share a unique trace ID to maintain the connection across different services. This architecture allows a developer to pinpoint the exact location of a failure or a slowdown. You might already know that instrumentation works through libraries, but the way the SDK manages the data lifecycle remains the most important detail.

Context propagation carries this trace context to different services using HTTP headers to ensure they belong to the same trace. The SDK manages these signals. The SDK uses a processor to handle tasks such as batching spans or filtering data. A common example is the BatchSpanProcessor, which groups spans together to improve efficiency in production environments. Sampling lets a developer control the amount of telemetry to collect to manage costs and data volume. Exporters then take the processed data and send it to a destination. The OpenTelemetry Protocol (OTLP) is a standard wire protocol used to transport this data. It runs over either HTTP or gRPC. The framework provides traces, metrics, and logs. A metric identifies a problem, a trace shows the location of the problem, and a log explains the exact event.

.NET integration and collector services

The .NET implementation differs from other platforms because .NET provides its own logging, metrics, and activity APIs. OpenTelemetry collects telemetry from these existing APIs. This makes it a powerful tool for .NET developers. The following table lists specific packages used in .NET environments:

The Aspire Service Defaults project helps developers configure the SDK, ASP.NET, and HttpClient instrumentation. This setup uses the OTLP exporter by default to provide visualization in the Aspire Dashboard. The Aspire Dashboard brings telemetry observation to the local debug cycle. This capability helps developers verify that applications produce the correct telemetry before they move to production.

The industry uses OpenTelemetry to avoid being locked into a single vendor. Because the framework is vendor-neutral, a developer can send data to Jaeger, Prometheus, or commercial vendors without changing the application code. The ability to switch backends without touching application code makes the project effective.

The OpenTelemetry Collector acts as a standalone service that sits between the application and the observability backend to receive, process, and forward telemetry data to one or more specific destinations. Does the use of a centralized gateway increase latency for high-frequency telemetry?