Glossary
Observability has a vocabulary of its own. Below are the terms that come up most in our conversations, each in two or three sentences. Every term has its own address, so you can point to it.
Observability
The ability to infer what is happening inside a system from the signals it emits, including for questions nobody asked in advance. Where monitoring watches known failures, observability makes unknown problems investigable.
More on this →Monitoring
Watching predefined measurements against predefined thresholds, with a notification as soon as a threshold is crossed. Indispensable for known failure modes, blind to new ones.
Telemetry
Collective name for the data a system emits about itself: metrics, traces and logs. Good telemetry is structured, correlated and free of personal data.
Metrics
Numeric measurements over time, such as requests per second, error rate or memory use. Cheap to store and ideal for trends and alerts, but without the context of one individual request.
Traces
The journey of one request through every part of a system, built from spans. A trace shows where time is lost and which component caused an error.
Span
One step within a trace: an operation with a start, an end, a status and attributes. Spans that refer to each other form the tree of a request.
Logs
Timestamped events with free text or structured fields. Structured logs, with a fixed set of fields and no sensitive data, are searchable and correlatable; free text rarely is.
Correlation
Linking metrics, traces and logs to the same request, the same release or the same session, usually through a shared identifier. Without correlation they remain three separate stories.
MTTR
Mean Time To Recovery: the average time between the start of an incident and its resolution. The main measure of what observability delivers, because context with an alert shortens the search.
More on this →MTTD
Mean Time To Detect: the average time between the start of a problem and the moment someone knows. Errors that are handled gracefully often have an invisibly high MTTD.
More on this →SLI
Service Level Indicator: a concrete measurement of one aspect of a service, such as the percentage of successful bookings or the load time 95 percent of visitors achieve.
SLO
Service Level Objective: the target you set for an SLI, for example 99.5 percent successful requests per month. An SLO is an internal agreement that decides when an alert is worth it.
SLA
Service Level Agreement: a contractual promise to a customer, with consequences if it is missed. An SLA should be looser than the SLO behind it.
Error budget
The room between 100 percent and your SLO: the amount of failure you can afford per period. While there is budget, a team may take risks; once it is spent, reliability comes first.
Alert fatigue
A team going numb from too many or too few relevant alerts, so the one that matters is missed. The answer is fewer alerts with more context, not more alerts.
More on this →Golden signals
The four measurements that form the core for almost any service: latency, traffic, errors and saturation. A good starting point for what you should measure at minimum.
APM
Application Performance Monitoring: tooling that tracks the performance and errors of applications, often with automatic instrumentation. APM is a part of observability, not the whole of it.
More on this →RUM
Real User Monitoring: measurements from the browsers of real visitors, such as the load time they actually experience. The counterweight to lab measurements, which simulate a device and a network.
More on this →Synthetic monitoring
Automated checks that call a page or API at fixed intervals and verify the result. They see an outage even when there is no visitor, but they generate traffic of their own at the systems they test.
Sampling
Keeping a fraction of the telemetry instead of all of it, to limit cost. At low volume, sampling mostly throws away evidence; apply it based on measured volume, not out of habit.
Cardinality
The number of unique values of a label or attribute, such as user ids or URLs. High cardinality makes metrics expensive and slow; traces and logs handle it better.
Runbook
A step-by-step guide for a known incident: what to check, what to do, whom to call. An alert without a runbook moves the problem to whoever happens to be on duty.
Postmortem
The blameless analysis after an incident: what happened, why, and which change prevents a repeat. The source of the best improvements to observability.
Performance budget
A fixed limit for load time, page weight or script time that a change may not exceed, checked in the pipeline. Works as a change detector; the real quality measure comes from measurements with visitors.
More on this →Core Web Vitals
The three measures Google defines for the user experience of a web page: load speed of the largest element, response time to interaction and visual stability. They count in search rankings.
Capacity planning
Predicting the load a system can handle and the growth that is coming, based on measured saturation and stress testing. Prevents peak traffic, such as a sales event, from causing an outage.
More on this →Ready to see clearly?
Book a free strategy call. We analyze your situation and advise without obligation.