OpenTelemetry, often written OTel, is an open source, vendor neutral framework for generating, collecting and exporting telemetry: traces, metrics and logs. It is not a storage or dashboard product. Your code emits data in a common format, and you choose which backend receives it.
What does it include?
The project's own documentation says OpenTelemetry is an observability framework and toolkit for the generation, export and collection of telemetry, and that it is intentionally not a backend. The pieces are:
- APIs and SDKs for many languages, so applications can create telemetry.
- Instrumentation libraries that add telemetry to common frameworks, some without code changes.
- Semantic conventions, agreed attribute names such as which key holds an HTTP method, so data from different services lines up.
- OTLP, the OpenTelemetry protocol, the wire format used to send data. See the OTLP specification.
- The Collector, a separate process that receives, processes and exports data.
What are the signals?
The signals documentation covers each type.
- Traces follow one request across services. Each unit of work is a span, and spans link into a tree. Use them to find which hop was slow or failed.
- Metrics are numbers aggregated over time: request counts, queue depth, error rates. Cheap to store and good for alerts.
- Logs are timestamped records of events. OTel can attach a trace ID to a log line so you can jump from a log entry to the whole request.
Context propagation is the glue. A trace ID travels in request headers from service to service, which is how a trace survives crossing process boundaries.
Why use the Collector?
You can send data straight from an application to a backend, but a Collector in between gives you one control point. It can batch, retry, add resource attributes such as the cluster name, drop noisy data, redact fields and fan out to more than one destination. Swapping a backend becomes a configuration change rather than a code change in every service.
What are the security and cost concerns?
Telemetry is data, and it often contains more than teams expect.
- Sensitive values. URLs with tokens in the query string, SQL statements with literals, headers and request bodies can end up in spans and logs. The project has a security section worth reading.
- Volume. Tracing every request is expensive. Sampling keeps a portion, and tail sampling lets you keep the interesting traces, such as errors and slow ones.
- Transport. Encrypt the connection between SDK, Collector and backend, and authenticate it.
- Access. Anyone who can query traces can see what your system does. Treat access accordingly.
Constructed example: a checkout service records the full request URL on each span. A bug causes a password reset token to be placed in a query string, and now those tokens are stored in the tracing backend for 30 days. A redaction rule in the Collector, plus a code fix, solves both the leak and the recurrence.
How does this relate to security work?
Telemetry is evidence. When an incident happens, traces and logs show which service called which, with what identity, and when. Consistent attribute names make queries like "every call this service account made last night" feasible. Uniform instrumentation also exposes unexpected dependencies, such as a service quietly calling an external host.
How to check or apply this
- Pick one service and one user journey. Instrument it, using zero code instrumentation if your language supports it.
- Run a Collector and send data through it rather than directly to the backend.
- Agree on resource attributes: service name, version, environment.
- Add redaction rules for tokens, emails and other personal data, and test them with a sample.
- Set a sampling policy and a retention period, and write down the reason for each.
- Link logs to traces with trace IDs.
- Review who can read telemetry and audit that list each quarter.
Quick check
Is OpenTelemetry a monitoring tool?
No. It produces and moves telemetry. You still need a backend to store, query and visualize it.
Do I have to change my code?
Not always. Zero code instrumentation can capture common framework activity. Custom spans and attributes need code changes.
Sources
- OpenTelemetry, What is OpenTelemetry?
- OpenTelemetry, Signals
- OpenTelemetry, OTLP specification
- OpenTelemetry, Sampling
- OpenTelemetry, Security
Last reviewed: 18 October 2026.
