What is OpenTelemetry?

OpenTelemetry is an open source project that standardizes how software produces telemetry, the traces, metrics and logs that describe what it is doing, and how that telemetry is described and moved. It is a Cloud Native Computing Foundation project, formed in 2019 when two earlier projects, OpenTracing and OpenCensus, merged.

The short version: OpenTelemetry covers everything from the line of code that records a measurement to the moment the data leaves for a backend. It doesn't store, query or chart anything. That part is up to whichever backend you send to, which is the point.

The problem it solves

Before OpenTelemetry, every monitoring vendor shipped its own agent, its own client libraries and its own data format. Instrumenting an application meant instrumenting it for one vendor. Switching meant re-instrumenting, and library authors couldn't add tracing to their own code without picking a vendor for their users.

OpenTelemetry separates producing telemetry from analyzing it. You instrument once, with vendor-neutral APIs, and send the data to any backend that speaks the OpenTelemetry protocol. Libraries can carry instrumentation that costs nothing until an application turns it on.

The parts

The API is what your code and your libraries call: start a span, add an attribute, record a counter. On its own it does nothing, which is why it is safe for a library to depend on.

The SDK is the implementation behind the API, one per language. It decides which spans to keep (sampling), batches data, detects resource details such as the host and the container, and hands everything to exporters.

Instrumentation connects popular frameworks and clients to the API, so an HTTP server or a database driver produces spans without you writing them. For several languages, including Java, .NET, Node.js and Python, an agent applies that instrumentation with no code changes. For compiled languages such as Go, there is also eBPF-based instrumentation that works from outside the process.

OTLP, the OpenTelemetry Protocol, is how telemetry travels: over gRPC or over HTTP with protobuf or JSON, on ports 4317 and 4318 by default.

The Collector is a standalone service that receives telemetry, processes it and exports it. A configuration wires receivers (OTLP, host metrics, log files, Prometheus scrapes and many more) through processors (batching, filtering, redaction, enrichment) to exporters. It runs beside applications as an agent, centrally as a gateway, or both. Vendors and teams build their own distributions of it from the same components.

Semantic conventions give common things common names: service.name for a service, http.request.method and http.response.status_code for HTTP, k8s.pod.name for a pod. Shared names are what let a dashboard, an alert or a query work on data from any language.

Context propagation carries a trace from one service to the next, usually in the W3C Trace Context traceparent header, so one request becomes one trace no matter how many services it crosses.

The signals

Traces follow a request through a system. Metrics are numbers aggregated over time, such as request counts and latency histograms. Logs are timestamped records, and OpenTelemetry can attach the active trace and span IDs to them, which is what lets you jump from a slow span to the log lines it wrote.

How mature each signal is depends on the language. The language pages list the status of traces, metrics and logs for every SDK, and they are worth checking before you plan a rollout.

What it leaves to you

OpenTelemetry is not a backend. It has no storage, no query language, no dashboards and no alerting. Those come from what you send the data to.

It also doesn't make telemetry free. You still decide what to name services, which resource attributes to set, how much to sample, and which attributes are worth their cardinality. A user ID as a span attribute is useful; the same ID as a metric label can create a series per user.

How Tracix handles it

Tracix is built around upstream OpenTelemetry, so the instrumentation you add is portable.

• No proprietary SDK. Applications use the upstream OpenTelemetry agents and SDKs. The Setup page in APM writes the configuration for your language and platform, and every setup reads the standard OTEL_* environment variables.
• OTLP in. Each workspace has an OTLP endpoint for HTTP and one for gRPC, both on port 443 with TLS. Requests carry an ingest key in the x-tracix-ingest-key header. See OTLP endpoint and ingest keys.
• A collector that is an OpenTelemetry Collector. The Tracix Collector is a distribution built with the OpenTelemetry Collector Builder. It adds the parts a fleet needs, such as policies that push signed configuration to collectors, and it can receive OTLP from your applications on ports 4317 and 4318.
• The Operator on Kubernetes. The upstream OpenTelemetry Operator injects agents into your pods; Tracix gives it the endpoint and the key.
• Zero-code where you can't change the code. The collector can trace services with eBPF on Linux 5.8 and later with BTF, with no code, image or restart change.
• OpenTelemetry names first. Data keeps the semantic convention names, and Tracix adds names of its own only where no convention exists, such as tracix.service_group.name for service groups.

To try it with a real service, follow Instrument a Go service with OpenTelemetry, or pick your language in Languages and SDKs.