OTel
OTel is the common abbreviation for OpenTelemetry, the CNCF vendor-neutral standard for generating and collecting traces, metrics, and logs. It is used in package names, configuration, and conversation as a shorthand for the project and its SDKs.
OTLP
OTLP stands for OpenTelemetry Protocol, the Protobuf-based wire format for exporting telemetry over gRPC or HTTP. It is the default export format produced by OpenTelemetry SDKs and the Collector.
SLI
SLI stands for Service Level Indicator, a quantitative measure of one aspect of service quality, such as the fraction of successful requests. It is the raw measurement an SLO sets a target on.
SLO
SLO stands for Service Level Objective, a target value for an SLI over a window (for example 99.9% over 30 days). It is the internal reliability target a team commits to.
SLA
SLA stands for Service Level Agreement, a contractual commitment to customers with consequences for breach. It is a business document that is typically looser than the internal SLO.
SRE
SRE stands for Site Reliability Engineering, Google's discipline of applying software-engineering practices to operations. It introduced SLIs, SLOs, and error budgets as the language of reliability.
RED
RED stands for Rate, Errors, Duration - a request-centric monitoring method for services. It defines the minimum metrics to instrument per endpoint or service.
USE
USE stands for Utilization, Saturation, Errors - Brendan Gregg's resource-centric method for diagnosing system bottlenecks. It is applied per resource (CPU, memory, disk, network).
MELT
MELT stands for Metrics, Events, Logs, and Traces, a popular grouping of the telemetry types an observability platform handles. It is an alternative framing to the "three pillars" that explicitly calls out discrete events.
MTTR
MTTR stands for Mean Time To Recovery (sometimes Repair or Resolve), the average time to restore service after failure. Reducing MTTR is a primary goal of investing in observability.
MTTD
MTTD stands for Mean Time To Detect, the average time between an incident starting and being noticed. Good alerting and SLO burn-rate monitoring drive MTTD down.
MTBF
MTBF stands for Mean Time Between Failures, the average uptime between successive incidents. Together with MTTR it characterises a system's reliability profile.
p50 / p95 / p99
These denote the 50th, 95th, and 99th percentiles of a distribution, almost always latency. p50 is the median typical experience, while p95 and p99 describe the tail that most affects user perception and SLOs.
PromQL
PromQL is the Prometheus Query Language used to select, transform, and aggregate time series. It powers Prometheus dashboards, recording rules, and alerting expressions.
TSDB
TSDB stands for Time Series Database, a store optimised for timestamped numeric data with efficient ingestion and range queries. Prometheus, Mimir, Thanos, and VictoriaMetrics are common examples.
APM
APM stands for Application Performance Monitoring (or Management), a class of tools that trace requests, profile code, and surface latency and errors in applications. OpenTelemetry increasingly feeds vendor-neutral data into APM backends.
eBPF
eBPF (extended Berkeley Packet Filter) is a Linux kernel technology that runs sandboxed programs in kernel space, used to collect network, syscall, and performance telemetry without modifying applications. It enables zero-instrumentation observability and is the basis of tools like Cilium and Pixie.
traceparent
traceparent is the W3C Trace Context HTTP header that carries the trace ID, parent span ID, and trace flags between services. It is the field that stitches spans across service boundaries into one trace.
tracestate
tracestate is the companion W3C Trace Context header that carries vendor-specific key-value state alongside traceparent. It lets multiple tracing systems coexist on the same request.
OOMKilled
OOMKilled is the status a container receives when the Linux out-of-memory killer terminates it for exceeding its memory limit. It is a frequent saturation symptom surfaced by container and Kubernetes observability.
PII
PII stands for Personally Identifiable Information, data that can identify an individual. Telemetry pipelines must scrub or avoid PII in logs, span attributes, and high-cardinality labels for privacy and compliance.
RUM
RUM stands for Real User Monitoring, the collection of performance and error telemetry from actual end-user sessions in the browser or app. It complements synthetic monitoring, which uses scripted probes.
Synthetic Monitoring
Synthetic monitoring runs scripted probes against a service from outside to measure availability and latency on a fixed cadence. It catches outages even when there is no real traffic, unlike RUM.
Span Kind
Span kind is an OpenTelemetry attribute classifying a span as SERVER, CLIENT, PRODUCER, CONSUMER, or INTERNAL. It tells backends how spans relate across process boundaries, for example pairing a client call with its server handler.
Span Status
Span status is the outcome flag on a span - UNSET, OK, or ERROR - used to mark whether the operation failed. Setting ERROR status is how traces surface failures for filtering and tail-based sampling.
High Cardinality
High cardinality describes a dimension with very many distinct values, such as user IDs or request IDs. It is cheap in logs and traces but dangerous in metric labels, where it causes time-series explosion.
Downsampling
Downsampling reduces the resolution of stored time series over time, for example keeping 15-second data for two weeks and hourly aggregates for a year. It controls long-term storage cost while preserving trend visibility.
Cardinality Bomb
A cardinality bomb is an instrumentation mistake that injects an unbounded label value (like a full URL with IDs) into metrics, exploding the time-series count. It can crash the metrics backend and is a common production incident.
Heartbeat
A heartbeat is a periodic signal a component emits to prove it is alive, monitored via dead-man's-switch alerts that fire when the heartbeat stops. It detects silent failures where a component produces no other telemetry.
Cardinality Limit
A cardinality limit is a guardrail in a metrics pipeline that caps the number of series per metric, dropping or aggregating excess. It protects the backend from cardinality explosions caused by buggy instrumentation.