What Is Telemetry in Software?

Last verified on Nov 8, 2026.

In software, telemetry is data a system emits about itself and its behavior. OpenTelemetry's primer defines it as data emitted from a system and its behavior, in the form of traces, metrics, and logs. A web server writing a line for each request, a counter of requests per second, and a record of how long one request spent in each service are all telemetry.

This page covers telemetry from software and infrastructure. It is the raw material for observability.

Types of Telemetry

OpenTelemetry calls the categories signals:

Events and profiles (a recording of resource usage at the code level) are in development or at the proposal stage. Spans, the units of a trace, are covered in span and distributed tracing.

The signals answer different questions. A metric says the error rate rose. A log says which error. A trace says where in the request it happened. Tying logs to a trace and span makes them far more useful, so trace IDs in log lines pay off.

Where Telemetry Comes From

Software does not emit telemetry on its own. It has to be instrumented, meaning its code must emit signals. There are three common sources:

• Your code, through a logging library or tracing API.
• Instrumentation libraries, which cover common frameworks. OpenTelemetry's automatic instrumentation generates telemetry without code changes.
• Platforms and infrastructure, such as load balancers, databases, and cloud services, which write their own logs and metrics.

How Telemetry Is Collected

The usual path has four steps: generate, export, collect, store. SDKs export over a protocol such as OTLP. A Collector, run beside the service, receives the data and can retry failed sends, batch, encrypt, and filter sensitive data before forwarding it. OpenTelemetry leaves storage and visualization to other tools, so the last step is your choice of backend. See OpenTelemetry for the full picture, or log forwarding for the log side.

Things to Watch

• Volume and cost. Telemetry grows with traffic. OpenTelemetry calls sampling one of the most effective ways to reduce the cost of observability without losing visibility. Metrics add their own cost through cardinality, the number of distinct label combinations.
• Sensitive data. Telemetry leaks things quietly. OpenTelemetry advises against putting credentials, API keys, or personal data in baggage, since it might be logged or sent to untrusted downstream services, and notes that internal trace and span IDs might reveal sensitive information to external services.
• Gaps. A service that emits nothing is invisible, so a silent source is a blind spot. See log stream behavior.
• Inconsistent fields. The same fact under three names makes search hard. Agree on field names early.

Telemetry in Sazabi

Sazabi, an AI-native observability and security platform, treats every kind of telemetry as a log. Its docs describe logs, metrics, traces, and webhook events all normalized into one searchable body of log records through a single intake, so there is one setup path and one place to ask questions. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run. See the OpenTelemetry integration to start sending.

Frequently Asked Questions

What is telemetry in simple terms?

Data a running system sends out about what it is doing, such as log lines, performance measurements, and records of requests, so people can see how it behaves without logging in to the machine.

What are the main types of telemetry?

Logs, metrics, and traces. OpenTelemetry also lists baggage, and has events and profiles in development or at the proposal stage.

What is the difference between telemetry and logs?

Logs are one kind of telemetry. Telemetry also includes metrics, which are numeric measurements over time, and traces, which follow a request across services.

Is telemetry the same as observability?

No. Telemetry is the data. Observability is the ability to understand a system from that data. You can collect plenty of telemetry and still be unable to answer new questions about your system.

Sources

1. Telemetry refers to data emitted from a system and its behavior, in the form of traces, metrics, and logs; a log is a timestamped message; metrics are aggregations over a period of time of numeric data; the application must be instrumented to emit signals (accessed Nov 8, 2026)
2. Signals supported are traces, metrics, logs, and baggage; events and profiles are under development or proposed; traces are the path of a request, metrics a measurement captured at runtime, logs a recording of an event (accessed Nov 8, 2026)
3. Telemetry is generated by instrumentation, exported, and collected; storage and visualization are left to other tools; automatic instrumentation generates telemetry without code changes (accessed Nov 8, 2026)
4. The Collector receives, processes, and exports telemetry and can handle retries, batching, encryption, and sensitive data filtering (accessed Nov 8, 2026)
5. Avoid putting credentials, API keys, or PII in baggage because it might be logged or sent to untrusted downstream services; internal trace and span IDs might reveal sensitive information to external services (accessed Nov 8, 2026)
6. Sampling is one of the most effective ways to reduce the cost of observability without losing visibility (accessed Nov 8, 2026)
7. Sazabi treats every kind of telemetry as a log and normalizes logs, metrics, traces, and webhook events into searchable log records through a single intake (accessed Nov 8, 2026)