Observability Foundation key terms

The three complementary telemetry types, metrics, logs, and traces, that together let teams infer the internal state of a system from its external outputs. Each answers different questions, so none alone gives a complete picture.

The property of a system that lets you ask new questions about its behavior without shipping new code first. It depends on rich, high-cardinality telemetry rather than a fixed set of pre-defined dashboards.

Watching a known set of signals against thresholds to detect conditions you already anticipated. It answers whether things are broken, but not why an unfamiliar failure is happening.

A numeric measurement aggregated over time, such as request rate or error count, stored cheaply and queried fast. Metrics are excellent for alerting and trends but lose per-request detail.

A timestamped record of a discrete event, often with structured attributes. Logs carry rich detail useful for debugging, but are expensive at volume and hard to aggregate without structure.

The recorded path of a single request as it moves through services, made of nested spans. A trace shows where time was spent and which component caused an error or delay.

One timed operation inside a trace, such as a database query or HTTP call, with start and end times, attributes, and status. Spans nest to form the parent-child structure of a trace.

The span that directly encloses another operation in a trace. Parent-child links let tooling reconstruct call order and attribute a child's latency to the operation that triggered it.

A key-value pair attached to a span describing what happened, such as HTTP status, route, or database name. Attributes enable filtering and grouping traces by meaningful dimensions.

Tracking one request across process, service, and host boundaries by passing trace context between them. It reveals end-to-end latency and failure points in service-oriented architectures.

Carrying trace identifiers and flags from one service to the next, usually through HTTP headers or message metadata, so their spans join the same trace. Broken propagation fragments traces into unrelated pieces.

A globally unique identifier shared by every span belonging to one request. It is the key used to stitch together a complete distributed trace across systems.

Choosing which traces to record and export instead of keeping all of them, to control cost and overhead. Head-based sampling decides at the start; tail-based sampling decides after the trace completes.

A vendor-neutral open source project providing APIs, SDKs, and a collector for generating and exporting metrics, logs, and traces. It standardizes instrumentation so telemetry is portable between backends.

A standalone agent or gateway that receives, processes, and exports telemetry in many formats. It centralizes batching, filtering, sampling, and routing so applications stay free of backend-specific code.

Instrumenting applications with libraries or agents that emit telemetry for common frameworks without manual code changes. It speeds adoption but may miss business-specific context that manual spans add.

Adding spans, attributes, and metrics explicitly in application code to capture domain-specific behavior. It complements automatic instrumentation by recording what matters to the business.

Agreed naming rules for telemetry attributes, such as standard keys for HTTP method or service name. They make data comparable across teams, languages, and vendors.

The standard wire format and transport specification for sending telemetry between instrumented software, collectors, and backends. Using it avoids lock-in to any single vendor's ingestion API.

The number of distinct values a dimension can take, such as unique user IDs or URLs. High cardinality gives analytical power but raises storage cost and query load if unmanaged.

A sample trace identifier attached to a metric data point, linking an aggregate number to a concrete request. It lets an engineer jump from a spike on a chart straight into a relevant trace.

A shared identifier written into logs, traces, and events so records from one request can be found together. It bridges telemetry types that are stored in separate systems.

Emitting logs as machine-parsable records with named fields rather than free text. Structured fields make logs filterable, aggregatable, and joinable with traces and metrics.

A quantitative measure of service behavior from the user's perspective, such as success rate or latency percentile. SLIs are the raw measurements from which objectives and error budgets are derived.

A target range for an SLI over a period, such as 99.9 percent of requests succeeding in 30 days. SLOs align engineering priorities with user-perceived reliability.

The amount of unreliability an SLO permits in a period, computed as the inverse of the objective. It gives teams a shared, data-driven basis for balancing releases against stability work.

The desensitization that occurs when too many noisy or low-value alerts fire, causing real incidents to be missed. It is reduced by alerting on symptoms, SLOs, and actionable conditions only.

Correlated visibility across the whole delivery chain, from browser and mobile clients through network, infrastructure, and backend services to business outcomes. It connects technical signals to user and revenue impact.

Collecting performance and error data from actual client sessions in browsers or mobile apps. It captures the user-perceived experience that server-side telemetry alone cannot see.

Probing a system with scripted, simulated transactions from controlled locations on a schedule. It detects availability and latency problems even when no real users are active.

Tracing a complete business flow, such as checkout or claim submission, across services and tying it to outcomes like conversion or revenue. It translates technical health into business impact.

The practice of integrating security controls and checks throughout the software delivery pipeline rather than auditing after release. It shifts security work into the same automated, observable flow as development and operations.

Applying machine learning and analytics to telemetry for anomaly detection, alert correlation, and root cause suggestions. It reduces manual triage but depends on high-quality, well-labeled observability data.

A staged framework describing how an organization's observability practice grows, from reactive monitoring to proactive, data-driven engineering. Stages typically cover tooling, culture, and process adoption.

Shared norms in which teams instrument their own services, treat telemetry as a product, and blamelessly learn from incidents. Tools alone fail without these behaviors and ownership agreements.

Telemetry gathered from containers and their runtimes, including resource limits, restarts, and per-container network and CPU behavior. It explains failures that host-level metrics hide in dense, ephemeral environments.

Visibility into cluster state and workloads, covering pod lifecycle, scheduling, control-plane events, and service networking. It links application symptoms to orchestration events such as evictions or failed probes.

Understanding traffic flows, latency, retransmissions, and drops across the network path between services. It exposes problems such as DNS delays or packet loss that application telemetry alone cannot explain.