LF Observability key terms

The ability to infer a system's internal state from the telemetry it emits, so you can answer new questions without shipping new code. It relies on correlated metrics, logs, and traces rather than on pre-defined dashboards alone.

The data a system emits about its own behavior, such as counters, log records, and spans. Telemetry is collected, transported, and stored so operators can inspect health and diagnose faults after the fact.

A shorthand for metrics, logs, and traces as complementary signal types. Metrics summarize cheaply over time, logs capture discrete events, and traces follow a request across services; each answers different questions and they are strongest when correlated.

A measured quantity describing service behavior, such as request latency or error ratio. An SLI is the raw number you observe; it becomes meaningful when compared against an objective.

A target range for an SLI over a window, for example 99.9 percent of requests succeeding over 28 days. SLOs convert reliability expectations into measurable goals that guide alerting and release decisions.

The allowed amount of unreliability implied by an SLO, computed as one minus the objective. Spending the budget on risky changes is acceptable; exhausting it should slow releases and trigger investigation.

How fast an error budget is being consumed relative to the rate that would exhaust it exactly at the end of the SLO window. A burn rate of one is sustainable; multi-window alerts fire on fast burns to catch incidents early.

Rules that evaluate telemetry and notify responders when conditions warrant action. Good alerts are symptom-based, actionable, and routed with severity and ownership so pages reach the right person quickly.

A short, maintained document describing how to diagnose and mitigate a specific alert or failure mode. Linking runbooks to alerts shortens recovery and captures operational knowledge for on-call engineers.

The structured process of detecting, triaging, mitigating, and learning from service disruptions. It defines roles, communication channels, and timelines so responders act calmly and record evidence for later review.

A blameless review after an incident that documents timeline, impact, contributing causes, and follow-up actions. Its purpose is systemic learning, not assigning fault, and it feeds improvements back into monitoring and design.

Numeric measurements aggregated over time, such as counters and gauges, stored as time series. They are cheap to retain and query, making them suitable for dashboards, alerting, and long-term trend analysis.

A metric that only increases, or resets to zero on restart, representing a cumulative count such as requests served. Rates and increases are derived from counters rather than reading the raw total.

A metric representing a value that can rise or fall at any moment, such as queue depth or memory usage. Gauges are read directly and are not meaningful to differentiate like counters.

A metric that records the distribution of observations by counting values into configured buckets, enabling percentile estimation. Bucket boundaries must suit the expected range, and aggregation across instances requires care.

A metric type that computes quantiles on the client side over a sliding window and exports them directly. Quantiles cannot be merged across instances, so summaries suit per-instance analysis more than fleet-wide aggregation.

A value below which a given share of observations falls, such as the 95th percentile latency. Percentiles describe tail behavior but cannot be averaged across instances; aggregate from histograms instead.

A sequence of timestamped values identified by a metric name plus a set of labels. Each distinct label combination forms its own series, which is why label design drives storage cost and query performance.

A key-value pair attached to a metric that identifies dimensions such as service, method, or status code. Labels enable filtering and grouping but multiply series count, so high-variability values should be avoided.

The number of distinct label combinations a metric produces. High cardinality from unbounded values like user IDs or raw URLs inflates memory and query cost and is a common cause of monitoring outages.

The per-second increase of a counter over a time window, computed by the query engine rather than the client. Rates smooth counter resets and reveal throughput trends for dashboards and alerts.

The query language used with Prometheus-style metrics, offering selectors, functions, and operators over time series. Understanding rate, aggregation, and vector matching is essential for building correct dashboards and alerts.

A sample trace identifier attached to a metric observation, letting you jump from an aggregated spike to a specific request trace. Exemplars bridge metrics and traces without storing per-request metric labels.

Timestamped records of discrete events, usually with a severity and message, optionally structured as key-value fields. They provide detail and context that metrics cannot, but volume and cost require sampling and retention policies.

Emitting logs as machine-parsable fields, typically JSON, instead of free-form text. Structured fields make filtering, aggregation, and correlation with trace identifiers reliable and cheap.

Collecting logs from many hosts and services into a central store for search and retention. Agents or collectors ship entries, and indexing choices determine query speed and storage cost.

Records of a request's path through distributed services, composed of nested spans with timing and attributes. Traces reveal where latency accumulates and which downstream call failed for a specific request.

A single timed operation within a trace, such as an HTTP call or database query, with a start time, duration, attributes, and status. Spans nest via parent identifiers to form the trace tree.

A globally unique identifier shared by every span in one trace, allowing spans from different services to be stitched together. Logging it alongside events enables jumping between logs and traces.

Passing trace and baggage identifiers across process and network boundaries, typically via headers, so downstream services join the same trace. Missing propagation produces fragmented, disconnected traces.

Choosing a subset of traces or events to export to control cost and volume. Head sampling decides at trace start, while tail sampling decides after seeing the whole trace, enabling keep-on-error policies.

A vendor-neutral open source project providing APIs, SDKs, and a collector for generating and shipping metrics, logs, and traces. It standardizes instrumentation so backends can be swapped without rewriting code.

An OpenTelemetry component that receives, processes, and exports telemetry through configurable pipelines of receivers, processors, and exporters. It centralizes batching, sampling, filtering, and credential handling away from applications.

Attaching instrumentation to libraries and frameworks without editing application code, via agents or language-specific hooks. It gives fast baseline coverage of common calls, which manual instrumentation then enriches with business context.

A key-value pair attached to a span, log record, or resource describing context such as HTTP method or deployment environment. Attributes enable filtering and grouping but should avoid unbounded values.

In OpenTelemetry, the set of attributes describing the entity producing telemetry, such as service name, host, and cluster. A consistent service name is essential for correlating signals across backends.

A curated view of charts and panels answering operational questions at a glance. Effective dashboards follow a hierarchy from high-level service health to drill-down detail and link out to traces and logs.

How long telemetry is stored before deletion, often tiered by resolution or age. Retention choices balance investigation needs against storage cost and are constrained by query performance and compliance rules.