Observability glossary
Plain-English, citable definitions of the terms we use across the Rocketgraph blog. Each entry is written to stand alone.
- Observability
- Observability is the ability to understand a system's internal state from the telemetry it emits — primarily metrics, logs, and traces. Unlike traditional monitoring, which answers known questions, observability lets engineers ask new questions about failures they didn't anticipate.
- Observability at scale
- Observability at scale is the practice of collecting and querying telemetry across hundreds of services or thousands of hosts without costs growing faster than traffic. The main levers are decoupling storage from compute (object storage), controlling cardinality, and sampling intelligently rather than indexing everything.
- AI incident triage
- AI incident triage is the use of AI agents to perform the first phase of incident response automatically: clustering related alerts, correlating metrics, logs, traces, and deploys, ranking probable root causes, and drafting an incident summary before a human is paged. It targets the diagnostic gap between detection and mitigation, where most incident time is spent.
- Telemetry
- Telemetry is the data a system emits about its own behavior — metrics (numeric measurements), logs (event records), and traces (request paths across services). Telemetry volume typically grows super-linearly with traffic, which is why observability pricing models matter at scale.
- Cardinality
- Cardinality is the number of unique time series produced by a metric and its label combinations. High-cardinality labels (user ID, container ID, request ID) multiply series counts and are the single most common cause of surprise observability bills.
- MTTR (Mean Time to Resolution)
- MTTR is the average time from when an incident starts to when it is resolved. Most MTTR is spent in diagnosis — figuring out what changed and where — which is the phase AI triage compresses most effectively.
- Tail-based sampling
- Tail-based sampling is a tracing strategy that decides which traces to keep after they complete, so slow and failed requests are retained at full fidelity while healthy traffic is sampled down. It preserves debugging value at a fraction of the storage cost of keeping everything.
- OpenTelemetry (OTel)
- OpenTelemetry is the CNCF open standard for generating and exporting telemetry. Instrumenting with OpenTelemetry keeps your data portable, so you can switch observability backends — or run several — without re-instrumenting application code.
- Object-storage observability
- Object-storage observability is an architecture that lands telemetry in cheap object stores (like S3-compatible storage) in open columnar formats and queries it on demand, instead of keeping everything in expensive hot indexes. It decouples the cost of retaining data from the cost of querying it.
- Alert fatigue
- Alert fatigue is the desensitization that occurs when engineers receive too many low-signal alerts, causing real incidents to be missed or acknowledged slowly. Deduplication, correlation, and AI triage reduce fatigue by collapsing alert storms into a small number of ranked, contextualized issues.
- SLO (Service Level Objective)
- An SLO is a target level of reliability for a service, such as 99.9% of requests succeeding within 300 ms over 30 days. SLOs turn raw telemetry into a decision framework: they define how much unreliability is acceptable before feature work should pause.
- Error budget
- An error budget is the amount of unreliability an SLO permits — the gap between the objective and 100%. Teams spend it deliberately on launches and experiments; when it's exhausted, reliability work takes priority.