Glossary of Observability Terms (Beginner’s Cheat Sheet)

Aggregation is the process of combining data and summarizing it. In observability, this often means taking a large set of raw data points and rolling them up into a summary statistic or group. For example, instead of recording every single response time, you might aggregate them into an average response time per minute. Aggregation reduces data volume and makes trends easier to see – think of it as summarizing a book into key bullet points so you get the gist without reading every word.

Alerting is the practice of sending out notifications when something important happens or when predefined conditions are met. In the context of observability, you set up rules or thresholds for your system’s metrics and logs, and if those rules are violated, an alert (message) is sent to your team. For example, you might receive an alert if a server’s CPU usage stays above 90% for too long or if an application’s error rate suddenly spikes. Alerts are like smoke alarms for your software— they loudly warn you when there’s a fire (issue) so you can respond quickly. Good alerting helps ensure you discover problems before your users do.

APM stands for Application Performance Monitoring (sometimes “Application Performance Management”). It refers to tools and practices for tracking how well your applications are performing. APM involves measuring things like response times, error rates, transaction throughput, and resource usage (CPU, memory, etc.) to detect performance issues . Essentially, APM is like a health tracker for your apps – it keeps an eye on your application’s vital signs and tells you if something is wrong. For example, an APM tool might show you that a database query in your login service is slowing down the entire app, so you know exactly where to fix the problem to ensure users have a smooth experience.

In data terms, cardinality means the number of unique values in a set. In observability, we often talk about cardinality in the context of metrics or logs. For example, the cardinality of a “user ID” field in your logs is the number of different user IDs that appear. High cardinality means there are lots of unique values. High cardinality can strain monitoring systems because there’s more data variety to handle. Think of cardinality as “variety”: a low-cardinality metric is like an ice cream shop with only vanilla and chocolate, whereas a high-cardinality metric is like one with 50 flavors plus all the toppings – richer detail, but heavier to manage.

A collector is a component or service that gathers telemetry data and funnels it to where it needs to go. It acts as a central hub that collects, processes, and exports observability data (logs, metrics, traces) from one or many sources. It’s like a postal sorting office for telemetry: the collector receives all the data “mail,” sorts and packages it, and then delivers it to the right destination (usually an observability backend or database). Using a collector centralizes your data collection, making it easier to manage and route telemetry from your apps to your monitoring tools.

In observability, a dashboard is a customizable display or visual board that shows important metrics and data visualizations (graphs, charts, tables) about your system in real time. Dashboards are like an airplane cockpit for your software – at a glance, you can see key indicators like CPU usage, request rates, error counts, or whatever matters to you. Teams set up dashboards to monitor the health and performance of services. For example, you might have a dashboard for your website that shows the number of active users, request latency, and error rate all in one view. A well-crafted dashboard helps you quickly interpret complex data and spot anomalies or trends (say, a sudden drop in user sign-ups) without combing through raw logs.

Distributed tracing is a technique for tracking the path of a single request or transaction as it moves through a distributed system (for example, through multiple microservices). When a user performs an action – like clicking “Purchase” on a website – that request may travel through many different services (authentication service, order service, payment service, etc.). Distributed tracing follows that journey and records each step of the process. It’s like following a trail of breadcrumbs through your services to see where time is spent or where errors occur. By looking at a distributed trace, you can identify bottlenecks or failures – for instance, you might discover that the payment service was slow or a database call errored out. Each step in a distributed trace is called a span (see Span below), and together all the spans form the complete trace. Distributed tracing is invaluable for understanding how different parts of a system work together and for troubleshooting issues that span -no pun intended- multiple services.

An exporter is a component or plugin that sends telemetry data from one system to another. In many observability setups, exporters are used to get metrics or logs out of a system and into a monitoring platform. For example, with Prometheus (a popular open-source monitoring tool), you might use a Node Exporter on a Linux server to expose CPU, memory, and disk metrics in a format Prometheus can scrape. Essentially, exporters act as translators or data shippers – they take internal data and present it in the right format for your observability system to consume. This allows data from various systems (databases, servers, applications) to be exported and analyzed in a centralized monitoring tool.

Instrumentation is the act of adding code (or using tools) in your application to collect telemetry data about its behavior and performance. When you instrument an application, you insert “sensors” into the code – capturing metrics (e.g. how long a function takes or how often an event happens), tracing operations, or logging important events. It’s like outfitting a car with gauges and sensors: without instrumentation, you’re driving blind, but with it, you have a speedometer, fuel gauge, and other dials. Similarly, with software, instrumentation gives you insight into what’s happening inside your application. Good instrumentation is the foundation of observability – it provides the raw data (metrics, logs, traces) that all your monitoring and analysis tools rely on.

Logs are textual records of events that happen within a system. Whenever something noteworthy occurs in an application or on a server – for example, an error, a user action, or a configuration change – it can be recorded as a log entry. Logs are usually timestamped and can include details like severity level (Info, Warning, Error) and contextual information (e.g., which user or process triggered the event). In everyday terms, logs are like a diary or journal for your application, recording what happened and when. They are incredibly useful for debugging and forensic analysis – when something goes wrong, reading the logs lets you trace the sequence of events leading up to the issue. Logs may be plain text or structured (e.g., in JSON format). They are one of the three pillars of observability, alongside metrics and traces, because they provide a detailed narrative of system activity.

Metrics are numeric measurements about your system, tracked over time. Common metrics include things like CPU usage percentage, memory consumption, request rate (requests per second), error rate, and response latency. These are typically collected at regular intervals (for example, every 10 seconds) which lets you see historical trends – like “CPU usage spiked to 90% at 2:00 AM” or “we had double the traffic on Friday compared to Thursday.” Metrics are easy to graph on dashboards to observe patterns and are often used to trigger alerts when they go out of expected ranges. In short, metrics are like the vital signs of your application – they quantify aspects of system performance and health (how much, how many, how fast, how slow). They help answer questions such as “Is our error rate higher today?” or “What’s the average response time right now?”

Monitoring is the practice of continuously observing the state of your system by tracking a set of predefined metrics and logs, and alerting when something seems wrong. With monitoring, you might set up dashboards and alerts for things like uptime, CPU load, or error rate. For example, you monitor a web server’s response time and set an alert if it exceeds 500 milliseconds on average. Monitoring is essentially a subset of observability – it focuses on the key metrics and thresholds you predict might fail. It’s very useful for catching obvious issues (e.g., “server down” or “disk 95% full”) through automated checks and alarms.

Observability is the ability to understand what’s happening inside a complex system by looking at the data it produces on the outside. In practical terms, it means using telemetry data – logs, metrics, and traces (often called the three pillars of observability) – to infer the internal state and health of your applications. When a system is highly observable, you can answer almost any question about its behavior by examining its external outputs, without needing to add new probes or instrumentation each time. Observability is like being a doctor who can diagnose an illness from symptoms and test results – you don’t need to take the patient apart to know what’s wrong; you use the signals they give off (fever, blood pressure, etc.) to figure it out. In the software world, those signals are your logs, metrics, traces, and other telemetry. A strong observability setup means engineers can explore the why behind issues (not just detect that an issue happened).

OpenTelemetry (often abbreviated OTel) is an open-source collection of tools, APIs, and SDKs for instrumenting software and collecting telemetry data. It provides a standardized framework to generate and export observability data (logs, metrics, traces) in a vendor-neutral way. OpenTelemetry defines a common language for telemetry so that you can instrument your code once and send the data to many different backend systems that support OTel. Think of OpenTelemetry as a universal telemetry toolkit – instead of each monitoring vendor having its own agent or format, they all collaborate on OTel. By using OpenTelemetry libraries in your application, you can switch or send data to different observability platforms (open-source or commercial) without changing your instrumentation. This flexibility has made OpenTelemetry a key part of modern observability, as it avoids vendor lock-in and encourages interoperability across tools.

OTLP stands for the OpenTelemetry Protocol. It is the protocol used by OpenTelemetry to transmit telemetry data over the network. In simple terms, OTLP is the format or “language” that OpenTelemetry speaks when sending data (spans, metrics, logs) from your applications to a backend or collector. It’s designed to be efficient and vendor-neutral. You can think of OTLP as the postal service for your telemetry: it defines how telemetry data is packaged up and delivered so that any OTLP-compatible receiver can understand it. The benefit of having a standard like OTLP is that all your services and tools can communicate observability data seamlessly – if your app and your monitoring backend both support OTLP, they can talk to each other without custom adapters.

PromQL is the Prometheus Query Language, used to query and aggregate data from Prometheus – a popular open-source time-series database for metrics. If your metrics are stored in Prometheus, PromQL is how you ask questions about that data. It’s a flexible, functional language that lets you filter metrics and apply calculations on the fly. For example, you could write a PromQL query to get the average CPU usage of a service over the last 5 minutes, or to get the 99th percentile response time of an API endpoint. Think of PromQL as Excel formulas for time-series data – instead of cells and columns, you have metric names and time ranges, but you can sum them up, average them, take maximums, etc., often grouping by labels (like grouping metrics per service or per datacenter). PromQL’s power allows you to create dynamic dashboards and set up precise alerts (e.g., “alert if 5-minute error rate > 1%”). While it has its own syntax, with a bit of practice you can extract very rich insights from your metrics using PromQL.

In observability, sampling means recording only a subset of all data points rather than everything. This is usually done to control overhead and cost when there’s a high volume of telemetry data. For example, instead of collecting every single request trace in a high-traffic system (which could be millions of traces), you might only sample 1% of requests and ignore the rest. The idea is that a representative sample of data can still tell you what’s going on, at a fraction of the cost. It’s analogous to polling a small percentage of voters to predict an election result instead of surveying everyone. The trade-off is that you lose some detail (there’s a chance an infrequent error or outlier might not be captured if it falls outside the sample), but you greatly reduce overhead in terms of storage and processing. Different sampling strategies exist (fixed-rate, random, or more intelligent ones that try to keep “interesting” events), but all share the goal of balancing visibility with efficiency.

A service map is a visual representation of how the different services or components in your architecture connect and interact with each other. If you have a bunch of microservices, a service map will show each service as a node and draw lines (edges) between them to indicate which services talk to which. It’s like an architectural map for your software system. Service maps are often generated automatically using data from distributed tracing or network telemetry. They help you see the big picture of your system’s topology: for example, you can quickly grasp that Service A calls Service B and Service C, and Service C in turn calls Service D. This is useful for understanding dependencies and figuring out what might be impacted when one service has an issue. In short, a service map helps connect the dots, giving you a bird’s-eye view of your system’s structure that complements the detailed data you get from logs and metrics.

A Service Level Agreement (SLA) is a formal (often contractual) commitment between a service provider and a customer that defines the expected level of service. It usually specifies concrete targets like uptime, responsiveness, or throughput over a period (for example, 99.9% uptime per month) and the remedies if those targets are not met. In essence, an SLA is the “official promise” of service quality. If the provider fails to meet the agreed targets, the SLA typically outlines consequences, such as service credits or penalties. SLAs often incorporate one or more SLOs (see below) as the specific objectives that must be met, but an SLA adds legal weight – it’s what you can hold the provider accountable to. Think of an SLA as a guarantee: it sets clear expectations for performance and reliability, and it manages risk for the customer. Because breaking an SLA can have business or legal implications, these agreements are usually carefully defined and tracked.

A Service Level Indicator (SLI) is a specific metric or measurement that indicates how well a service is performing in a certain area. It’s essentially the measurement of something that matters to users. Common SLIs include things like availability (uptime percentage), latency (for example, “95% of requests complete in under 200ms”), throughput (requests per second), and error rate. In short, an SLI is the quantitative indicator of some aspect of service quality. If you think of a service level as a concept (say “reliability”), the SLI is how you measure it (“99.99% uptime” or “error rate = 0.1%”). These indicators are the building blocks for defining objectives and agreements – you set SLOs (objectives) and SLAs (agreements) based on SLIs. For example, if one SLI is “error rate = 0.1%,” the SLO might be to keep that error rate below 1% over a month, and the SLA might formalize that as a promise. In summary, SLIs tell you how you’re measuring success for a service’s attribute, and they provide the data for SLOs and SLAs .

A Service Level Objective (SLO) is a target or goal for a service’s performance or reliability, defined for a specific metric (SLI) over a period of time. It’s what your team aims for to ensure a good user experience. For example, an SLO might be 99.5% uptime for your service each quarter, or 95% of API responses under 300ms over the last 7 days. SLOs are usually internal goals and are often expressed as percentages or thresholds. They’re not customer-facing promises (that would be an SLA), but they guide your engineering and operations decisions. If your service stays within SLO, you’re meeting your reliability targets; if it consistently misses the SLO, that’s a signal to invest in improvements. Think of an SLO as the performance bar you set for your service – “we want to be this reliable or better.” By tracking SLOs, teams can balance pushing new features with maintaining quality (as in SRE practices with error budgets). In essence, SLOs help you answer “Are we meeting our reliability/performance goals?” and drive action if you’re not.

A span is a single operation or unit of work within a distributed trace. Each span has a name (what operation it represents), a start time and end time (so you know its duration), and metadata (tags or context about what it did). Spans can be nested: for example, if Service A calls Service B as part of handling a request, Service A’s span will be the parent and Service B’s span will be a child. In a trace, multiple spans are connected to form the full picture of a request. By examining spans in a trace, you can see which step took the longest or where an error occurred. In other words, spans let you zoom in on individual steps of a transaction, providing detailed context for each part of a workflow. They are the building blocks of distributed tracing – every trace consists of one or more spans linked together.

In software, telemetry refers to the data that a system produces about its own state and operations, which is collected for monitoring and analysis. In observability, telemetry typically includes all the logs, metrics, traces, and other signals emitted by your applications and infrastructure. The word comes from Greek roots meaning “remote measurement”, and that’s exactly what it is – measurements sent from your system to an external location (like your observability platform). It’s like how a spacecraft continuously sends status data back to mission control so engineers can understand what’s happening on the ship. Similarly, your services send telemetry data (e.g., CPU metrics, error logs, request traces) to your monitoring tools. Telemetry is the lifeblood of observability: without it, you’d be “flying blind” with no insight into your system’s behavior. Modern telemetry often relies on standardized protocols (like OTLP) and formats, so different systems can share and aggregate this data. Simply put, telemetry is all the data your system is telling you about itself – and observability is about listening to and making sense of that data.

A trace represents the end-to-end journey of a single request through a system, composed of a series of spans (each span is one step or operation). It shows how a request travels from one service or component to the next and how long each step takes. Traces are very useful for diagnosing performance issues and understanding service dependencies. By looking at a trace, you can pinpoint which part of a workflow caused a slowdown or an error – for example, you might see that a database query took 5000ms while all other steps were fast, indicating a database bottleneck. In essence, a trace links together all the related operations for one transaction, giving you a detailed story of that request. This distributed context is something you don’t get from metrics alone, which is why traces (along with logs and metrics) are such an important pillar of observability.