# Observability Glossary

> Clear, practical definitions of observability, monitoring, and telemetry terms - written for engineers, by engineers.

Source: https://openobserve.ai/glossary/

---

## Observability Fundamentals (4)

- [Observability](https://openobserve.ai/glossary/what-is-observability/): Observability is the ability to understand a system's internal state from the telemetry it emits - logs, metrics, and traces - so you can debug problems you didn't predict.
- [Telemetry](https://openobserve.ai/glossary/what-is-telemetry/): Telemetry is data emitted by software systems about their own behavior - logs, metrics, traces, and events - collected remotely to monitor, debug, and optimize those systems.
- [Telemetry Pipeline](https://openobserve.ai/glossary/what-is-telemetry-pipeline/): A telemetry pipeline (or observability pipeline) collects, transforms, filters, enriches, and routes logs, metrics, and traces between sources and destinations - controlling cost and data quality in flight.
- [Three Pillars of Observability](https://openobserve.ai/glossary/three-pillars-of-observability/): The three pillars of observability are logs, metrics, and traces - the core telemetry signals used to understand, debug, and operate modern software systems.

## Logs (2)

- [Log Aggregation](https://openobserve.ai/glossary/what-is-log-aggregation/): Log aggregation is the process of collecting logs from many distributed sources into one centralized system where they can be searched, correlated, and analyzed together.
- [Log Management](https://openobserve.ai/glossary/what-is-log-management/): Log management is the practice of collecting, parsing, storing, searching, and retaining log data from applications and infrastructure - at a cost and scale that stays sustainable.

## Metrics & Monitoring (2)

- [Four Golden Signals](https://openobserve.ai/glossary/four-golden-signals/): The four golden signals - latency, traffic, errors, and saturation - are Google SRE's recommended minimum set of metrics for monitoring any user-facing system.
- [High Cardinality](https://openobserve.ai/glossary/what-is-high-cardinality/): High cardinality means a field or metric label has a very large number of unique values - user IDs, container IDs, request IDs - which can explode storage and query costs in many observability systems.

## Tracing & APM (4)

- [APM (Application Performance Monitoring)](https://openobserve.ai/glossary/what-is-apm/): APM is the practice and tooling for monitoring application performance and availability - response times, error rates, throughput, and transaction traces - to detect and diagnose problems before users feel them.
- [Distributed Tracing](https://openobserve.ai/glossary/what-is-distributed-tracing/): Distributed tracing tracks a single request as it travels through the services of a distributed system, recording timing and context at every hop so you can pinpoint where latency and errors originate.
- [Real User Monitoring (RUM)](https://openobserve.ai/glossary/what-is-real-user-monitoring/): Real User Monitoring (RUM) captures performance, errors, and behavior from actual users' browsers and mobile devices - page loads, web vitals, session replays - showing what users really experience.
- [Span](https://openobserve.ai/glossary/what-is-a-span/): A span is the basic unit of a distributed trace - one named, timed operation with attributes, events, and a parent - and a trace is the tree of spans a single request produces.

## OpenTelemetry (2)

- [OpenTelemetry Collector](https://openobserve.ai/glossary/what-is-opentelemetry-collector/): The OpenTelemetry Collector is a vendor-neutral agent that receives, processes, and exports telemetry - a configurable pipeline of receivers, processors, and exporters for logs, metrics, and traces.
- [OTLP (OpenTelemetry Protocol)](https://openobserve.ai/glossary/what-is-otlp/): OTLP is OpenTelemetry's vendor-neutral wire protocol for transmitting traces, metrics, and logs from applications and collectors to any compatible observability backend, over gRPC or HTTP.

## SRE & Incident Response (4)

- [DORA Metrics](https://openobserve.ai/glossary/what-is-dora-metrics/): DORA metrics are four research-backed measures of software delivery performance - deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time.
- [Error Budget](https://openobserve.ai/glossary/what-is-error-budget/): An error budget is the amount of unreliability an SLO permits - if your target is 99.9%, the 0.1% is budget you can spend on releases, experiments, and maintenance before halting risk.
- [MTTR vs MTTD](https://openobserve.ai/glossary/mttr-vs-mttd/): MTTD (mean time to detect) measures how quickly you notice an incident; MTTR (mean time to resolve) measures how quickly you fix it. Together they define how long users feel your failures.
- [SLO vs SLA vs SLI](https://openobserve.ai/glossary/slo-sla-sli/): An SLI is what you measure (e.g., percent of successful requests), an SLO is the internal target you set for it (99.9%), and an SLA is the external contract with consequences if you miss it.

## Security (1)

- [SIEM](https://openobserve.ai/glossary/what-is-siem/): SIEM is a security platform that aggregates logs and events across an organization, correlates them to detect threats, and supports investigation, alerting, and compliance reporting.

## AI Observability (1)

- [LLM Observability](https://openobserve.ai/glossary/what-is-llm-observability/): LLM observability is the practice of monitoring LLM-powered applications - tracing prompts and responses, tracking token costs and latency, and evaluating output quality - to keep AI features reliable, safe, and affordable.