What is OpenTelemetry?
OpenTelemetry (OTel) is an open-source, vendor-neutral standard for generating and exporting telemetry: traces, metrics and logs. It provides APIs and SDKs for most languages, automatic instrumentation for common libraries, the OTLP wire protocol and a Collector. You instrument once and can send the data to any compatible backend.
Why OpenTelemetry matters
Before OpenTelemetry, every APM vendor had its own agent, so switching tools meant re-instrumenting the code. With OTel the instrumentation belongs to you and the backend is a configuration setting.
It is a Cloud Native Computing Foundation project, formed in 2019 by merging OpenTracing and OpenCensus. Its semantic conventions give common names to attributes such as http.request.method, so dashboards work across languages.
How to measure OpenTelemetry
kept spans = spans produced × sampling ratio (TraceIdRatioBased sampler) OTLP/HTTP paths: <base>/v1/traces, <base>/v1/metrics, <base>/v1/logs
Worked example
A service produces about 2,000,000 spans a day. You configure the TraceIdRatioBased sampler with a ratio of 0.1.
- Kept spans = 2,000,000 × 0.1 = 200,000 per day.
- With the default parent-based setup, downstream services follow the root's decision, so whole traces are kept or dropped together.
- Head sampling decides at the start, before anyone knows whether the request will be slow, so keep slow and failed traces with tail sampling in the Collector or in the backend.
Result: Sampling cuts volume tenfold, but the traces you most need are the rare slow ones. Decide which ones you must never lose before you pick a ratio.
Common mistakes
- Forgetting the service name. Without
service.nameevery span shows up as an unknown service. Set it withOTEL_SERVICE_NAME. - Exporting synchronously. Use the batch span processor so exporting never blocks requests.
- Mixing semantic convention versions. HTTP attribute names changed when the conventions were stabilised. Keep SDKs reasonably current so dashboards match.
- Assuming auto-instrumentation covers everything. It covers common libraries. Add manual spans around important business logic.
How Vigil handles OpenTelemetry
- Point any OpenTelemetry SDK or Collector at
https://puzaricloud.in/otlp/v1/traces(and/otlp/v1/metrics,/otlp/v1/logs); the OTel quick start covers Ruby, PHP, Go, Java, .NET, Node, Python, Rust and Elixir. - OTLP traces go through the same pipeline as Vigil's own SDKs: endpoints, slow traces, slow queries, N+1 detection, Apdex and deploy impact.
- Spans per day are metered per plan; when the daily allowance is used up, ingestion pauses until it resets, and nothing is charged automatically.
OpenTelemetry: frequently asked questions
Is OpenTelemetry a backend?
No. OpenTelemetry produces and transports telemetry; storing, querying and alerting on it is the job of a backend such as Vigil, Jaeger, Prometheus or a commercial APM.
What is OTLP?
The OpenTelemetry Protocol, the standard way to send traces, metrics and logs, over gRPC or HTTP with protobuf or JSON payloads.
Do I need the OpenTelemetry Collector?
No; SDKs can export straight to a backend. The Collector is useful to batch, filter, sample or route data to several backends from one place.