Telemetry is the data that applications and infrastructure emit about their own state and behavior, collected and transmitted for analysis. In software operations it covers metrics, logs, traces and profiles, often enriched with events such as deployments. Telemetry is the raw material of observability: without it, you cannot ask questions about a running system.
What is telemetry?
The word combines the Greek tele (remote) and metron (measure): measuring something from a distance. In software, telemetry is the data that services, hosts, containers, browsers and devices send about what they are doing: how many requests they handle, how long those take, which errors occur, how much memory and CPU they use, and what happened step by step inside a single request.
Telemetry is not the same as observability. Telemetry is the data; observability is the property of a system, and the practice of a team, that lets you understand its internal state from that data. Good observability requires telemetry that is complete, correlated and affordable enough to keep.
The main telemetry signals
| Signal | What it captures | Typical question it answers |
|---|---|---|
| Metrics | Numeric measurements aggregated over time | Is error rate or latency rising? |
| Logs | Timestamped records of discrete events | What exactly happened in this case? |
| Traces | The path of a request across services, made of spans | Where in the call chain is time spent or an error raised? |
| Profiles | Where code spends CPU time and memory, down to the function | Which function causes this CPU spike? |
| Events | Changes such as deployments, config updates, scaling actions | What changed right before the problem started? |
User-facing telemetry from browsers and mobile apps, collected through real user monitoring, adds the perspective of the people actually using the system.
How telemetry flows: the pipeline
- Generate: instrumentation in code, auto-instrumentation agents, eBPF-based collectors, or built-in exporters in infrastructure and cloud services produce the data.
- Collect: agents and the OpenTelemetry Collector receive or scrape telemetry close to the source.
- Process: the pipeline batches, enriches (for example with Kubernetes metadata), filters, samples and masks sensitive fields.
- Transport: data is sent to one or more backends, increasingly via OTLP.
- Store and analyze: the backend indexes or stores the data, makes it queryable, and drives dashboards, alerts, SLOs and automated analysis.
Each step is a lever for quality and cost. Decisions made early, such as which attributes to record and what to drop, have the largest effect on your bill and on what you can answer later.
Push vs. pull collection
Telemetry reaches a collector in one of two ways. In the pull model, popularized by Prometheus, the collector scrapes an HTTP endpoint on each target at a fixed interval, which makes it easy to see whether a target is down and keeps the application simple. In the push model, used by OTLP exporters and most log shippers, the application or agent sends data on its own schedule, which suits short-lived jobs, serverless functions and traffic that has to cross network boundaries. Most production environments use both, and the OpenTelemetry Collector can scrape Prometheus endpoints and receive OTLP pushes in the same pipeline.
Why correlation matters more than volume
More telemetry does not automatically mean more insight. What makes signals valuable is that they can be joined. Shared resource attributes such as service.name, deployment.environment.name and k8s.pod.name let you pivot from a metric to the hosts behind it. Trace and span IDs in log records let you move from a slow trace to the logs it produced. Exemplars connect a latency histogram bucket to a concrete trace. OpenTelemetry semantic conventions standardize these names across languages, which is why adopting them pays off quickly.
Best practices
- Standardize on OpenTelemetry for new instrumentation to avoid vendor-specific agents and formats.
- Set
service.name, version and environment on every signal from day one. - Treat telemetry as a product: define owners, naming rules and a budget per team.
- Filter and aggregate in the pipeline instead of storing everything and deleting later.
- Mask personal data before it leaves your network, especially in logs and span attributes.
Common mistakes
- Collecting each signal in a separate tool with different service names, so nothing can be correlated.
- Ignoring the cost of high-cardinality attributes until the invoice arrives.
- Instrumenting only the backend and having no view of what users experience.
- Monitoring applications but not the telemetry pipeline itself, so dropped data goes unnoticed.
How Obseria helps
Obseria accepts telemetry from OpenTelemetry SDKs and Collectors, the Obseria Agent (metrics, logs, traces, profiles and security signals from one installation per host), and agentless integrations for 300+ AWS, Azure and GCP services. Obseria Pipeline filters, enriches and masks data at ingest, and Obseria Lake stores all signals together so they can be correlated in one query. Get started on the OpenTelemetry page or read what is OpenTelemetry.
