Observability Glossary
Clear, practical definitions of observability, monitoring, and telemetry terms - written for engineers, by engineers.
Observability Fundamentals
Observability
Observability is the ability to understand a system's internal state from the telemetry it emits — logs, metrics, and traces — so you can debug problems you didn't predict.
Telemetry
Telemetry is data emitted by software systems about their own behavior — logs, metrics, traces, and events — collected remotely to monitor, debug, and optimize those systems.
Telemetry Pipeline
A telemetry pipeline (or observability pipeline) collects, transforms, filters, enriches, and routes logs, metrics, and traces between sources and destinations — controlling cost and data quality in flight.
Three Pillars of Observability
The three pillars of observability are logs, metrics, and traces — the core telemetry signals used to understand, debug, and operate modern software systems.
Logs
Log Aggregation
Log aggregation is the process of collecting logs from many distributed sources into one centralized system where they can be searched, correlated, and analyzed together.
Log Management
Log management is the practice of collecting, parsing, storing, searching, and retaining log data from applications and infrastructure — at a cost and scale that stays sustainable.
Metrics & Monitoring
Four Golden Signals
The four golden signals — latency, traffic, errors, and saturation — are Google SRE's recommended minimum set of metrics for monitoring any user-facing system.
High Cardinality
High cardinality means a field or metric label has a very large number of unique values — user IDs, container IDs, request IDs — which can explode storage and query costs in many observability systems.
Tracing & APM
APM (Application Performance Monitoring)
APM is the practice and tooling for monitoring application performance and availability — response times, error rates, throughput, and transaction traces — to detect and diagnose problems before users feel them.
Distributed Tracing
Distributed tracing tracks a single request as it travels through the services of a distributed system, recording timing and context at every hop so you can pinpoint where latency and errors originate.
Real User Monitoring (RUM)
Real User Monitoring (RUM) captures performance, errors, and behavior from actual users' browsers and mobile devices — page loads, web vitals, session replays — showing what users really experience.
Span
A span is the basic unit of a distributed trace — one named, timed operation with attributes, events, and a parent — and a trace is the tree of spans a single request produces.
OpenTelemetry
OpenTelemetry Collector
The OpenTelemetry Collector is a vendor-neutral agent that receives, processes, and exports telemetry — a configurable pipeline of receivers, processors, and exporters for logs, metrics, and traces.
OTLP (OpenTelemetry Protocol)
OTLP is OpenTelemetry's vendor-neutral wire protocol for transmitting traces, metrics, and logs from applications and collectors to any compatible observability backend, over gRPC or HTTP.
SRE & Incident Response
DORA Metrics
DORA metrics are four research-backed measures of software delivery performance — deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time.
Error Budget
An error budget is the amount of unreliability an SLO permits — if your target is 99.9%, the 0.1% is budget you can spend on releases, experiments, and maintenance before halting risk.
MTTR vs MTTD
MTTD (mean time to detect) measures how quickly you notice an incident; MTTR (mean time to resolve) measures how quickly you fix it. Together they define how long users feel your failures.
SLO vs SLA vs SLI
An SLI is what you measure (e.g., percent of successful requests), an SLO is the internal target you set for it (99.9%), and an SLA is the external contract with consequences if you miss it.