Cloud Observability Glossary

Active Service Bundle

A bundle of products which consists of an Active Service, Span Data, Active Time Series, and other items with limits detailed on a Cloud Observability order form

Active Time Series (ATS)

A set of timestamped measurements that share a metric name and a unique set of tag keys and values. Other vendors refer to this concept as “custom metric” or “metric time series.” In Cloud Observability, the cost of a time series is prorated hourly. See also distribution.


A notification that a value being monitored has gone outside of an assigned threshold for an assigned duration.


application performance monitoring (APM)

Technique used to monitor key app performance metrics about the performance of a web application in production.


A key:value pair that annotates a span with metadata used to identify characteristics of the span, such as customer_id or hostname. Attributes do not have timestamps.



In Cloud Observability, the segment of a chart where performance was stable. Baselines are used to compare performance to the time when a deviation occurred.


The number of elements in a set or other grouping, as a property of that grouping.

child span

Span created by a parent span. In a childOf relationship, the parent span has some dependency on the child(ren) span(s). In a followsFrom relationship, the parent spawns the child, but is not dependent on it. Try to avoid when talking about a followsFrom relationship.



Denotes the relationship this span has to another (parent) span. The parent is dependent on the child span and won’t close until the child closes.



Functionality that shows underlying services, operations, and tags that have a high probability in contributing to latency shown in a histogram.


critical path

The critical path is the time each operation in a request was actually active during the request. The Trace view highlights the path as a black line that travels down and back up the stack, to help identify bottlenecks in the overall transactions.



A metric kind that adds its value to the last value. They count the total number of things at a specific point in time, but as opposed to deltas, each value uses the same “start” timestamp to determine the value. An example of a cumulative metric is total web page hits. The value at each point in time increases from the last value, and you want to know how many of something you have accumulated at a given point in time.


A user-created, high-level view of the operations of interest. You can create dashboards for both metrics and traces (Streams).


Data Retention policy

The period of time that Cloud Observability retains an organization’s span data for analysis.


deep system

A software architectures where there are at least four layers of stacked, independently operated services, including cloud or SaaS dependencies.


A metric kind that shows how the values change from one reporting period (point on the graph) to the next. HTTP requests is an example of a delta metric. You want to see if requests are going up or down, and by how much.

Developer Mode

Allows an application developer to quickly see results of local instrumentation using a local developer satellite, without needing to deploy to production.


developer satellite

A locally-run satellite used by Developer Mode



Used to describe a change in expected behavior as seen in a chart or dashboard


diagnostics service

A Satellite sidecar process that tracks health and provides diagnostic information



A metric type that returns a set of values for a point in time and performs aggregation on those values before charting the points. Cloud Observability supports percentile aggregation and can display the 50th, 95th, 99th, and 99.9th percentiles.


A Cloud Observability product tailored to the needs of advanced customers. Product limits are included on order forms.


The view in Cloud Observability for doing live queries into Microsatellites as well as for viewing historical snapshots.



Denotes the relationship this span has to another (parent) span. The parent is not dependent on the child span.


A metric kind that represents an observed value at a specific point in time or over a specified range of time. Temperature readings are an example of a gauge metric. CPU usage is another example; you want to know exactly how much of an available resource is being used at a given point in time.

Identity Provider (IDP)

Identity Providers (IdPs) store and authenticate user identities. Cloud Observability integrates with several IdPs: Azure AD, Google, Okta, and OneLogin.

inferred service

An external service, library, or dependency that hasn’t been instrumented, like a database or a third-party API. Cloud Observability recognizes these as leaf spans (the request can’t continue to another service) and reports on their error counts, span counts, and average latencies.


ingress operations

An operation is considered an ingress operation when it is part of either a root span or its part of the first span that’s called in a service. By default, Cloud Observability considers ingress operations to be the Key Operations on a service.


Instrumentation Quality (IQ)

Analyzes the instrumentation on your services and determines how you can improve it to make Cloud Observability work even better


Just-in-Time (JIT) provisioning

With Just-in-Time (JIT) provisioning, the first time a user logs into Cloud Observability with their IdP credentials, Cloud Observability creates their account with a default role.

Key Operations

Operations whose performance is strategic to the health of your system. Latency or error increases in these operations are good starting points for investigating a service’s performance. By default, Cloud Observability considers Key Operations to be your ingress operations on the service.



Time interval or delay when one component is waiting for another component. Specifically, the duration of time for a data packet to travel from one component to another (one-way) or the time it takes for the packet to make a round-trip, minus the time spent at the destination (round-trip).


launchers (OpenTelemetry)

Cloud Observability’s configuration layer for OpenTelemetry that chooses default values for configuration to simplify discovery of the options and components available to users.


Cloud Observability Quickstart

A paid engagement led by our observability experts who partner closely with your team to ensure a fast, effective, and robust onboarding experience. This may include optional sessions on Observability and instrumentation best practices alongside Cloud Observability product trainings.

Cloud Observability SaaS

Satellites send all telemetry data to the Cloud Observability SaaS. The SaaS analyzes examples of application errors, high latency, or other interesting events, builds complete traces and dynamic service diagrams, deduces correlations among the data, and monitors for changes in performance after deploys. Along with trace data, the SaaS also monitors metrics and logs to provide full observability into your system’s performance.



Structured or unstructured lines of text that are emitted by an application in response to some event in the code. Logs are used to understand the activity in the application.

Log Event Analysis

The table and graph on the RCA view. The graph shows frequency of events in the spans that Cloud Observability has analyzed. The table shows the log messages, the number of times that message appears on spans during both the baseline and regression, and the change in frequency between the two.



A collection of data that measures a general feature of a system, for example the number of http requests received. Metrics are usually represented as counts or measures, and are often aggregated or calculated over a period of time.



Collects the telemetry data generated by instrumented clients and servers, and then sends that data to the Cloud Observability SaaS platform for analysis. They can be deployed in your environment as horizontally scalable instances.


Monthly Active Service

A service that has reported telemetry to Cloud Observability within the previous rolling 30-day period.



The concept of measuring the internal state of a system only by its outputs. For distributed systems, such as microservices, serverless, service meshes, etc., these outputs are telemetry data: logs, metrics, and traces.


An open source observability framework for cloud-native software. OpenTelemetry is a collection of tools, APIs, and SDKs. OpenTelemetry can be used to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) for analysis in order to understand software’s performance and behavior.


OpenTelemetry “Constellation” Consulting

A paid engagement led by our OpenTelemetry and OpenTracing experts who partner closely with your team to lead training and educational sessions on instrumentation (including instrumentation of common libraries and frameworks), creating a modern telemetry pipeline with the OpenTelemetry Collector, and hold office hours for two (2) weeks to help accelerate your OpenTelemetry efforts.

OpenTelemetry “Galaxy” Consulting

A paid engagement led by our OpenTelemetry and OpenTracing experts which includes all of the sessions and work from the “Constellation” package as well as hands-on-keyboard paired instrumentation of your services, frameworks, and other abstractions, any telemetry transformation in the OpenTelemetry Collector, and metrics data ingestion.


The work represented by a span.


Operation diagram

A view of the dependent services and operations. Used in the RCA pages.



The entity that Cloud Observability is installed for. Organizations contain projects.


The 99th percentile of a (histogram) distribution. This represents the upper bound of latencies experienced by 99% of traces. In other words, 99% of the traces are experiencing the p99 latency or less.

parent span

A span that spawns other spans. They can be spans with a childOf relationship (the parent span is dependent on the child completing) or with a followsFrom relationship (there is no dependency).

Premium Success & Support

A professional services offering for the duration of a customer’s term with SLAs or deliverables detailed on a Cloud Observability order form or statement of work.

Professional Services Hours

A limited engagement professional services offering capped at the number of hours specified on a Cloud Observability order form or statement of work.


Encapsulates all Cloud Observability data for a particular environment such as dev or production, spanning team boundaries, languages, clients, servers, and physical locations. Projects roll up into an organization.


Public Microsatellite pool

A Cloud Observability-managed shared pool of Microsatellites.



Describes a change in latency or error rate as reported by trace data.


role-based access control (RBAC)

Role-based access control (RBAC) lets you manage what users can do in Cloud Observability through roles and permissions.

Root Cause Analysis (RCA)

Typically used as a reactive method of identifying event(s) causes, revealing problems and solving them. Analysis is done after an event has occurred. Insights in RCA make it potentially useful as a preemptive method. In that event, RCA can be used to forecast or predict probable events even before they occur. While one follows the other, RCA is a completely separate process to incident management.

root span

Span that starts a trace.


The number of unique users that log into Cloud Observability at least once during a contract period as defined in the terms of the contract.


A single component of a software application (often a microservice) that provides specific functionality, such as an authentication or checkout service. You can have an unlimited number of deployed service instances. For billing purposes, only the actual service (by name) is counted.

Service diagram

Shows a map of the service hierarchy, as well as latency and errors. It provides a visual, interactive, and hierarchical representation of a system’s behavior for a given point in time, based on the query shown in Explorer.


Service directory

Shows all services reporting to Cloud Observability and their performance.


service level agreement (SLA)

Contract between a service provider (either internal or external) and the end user that defines the level of availability (usually a customer-facing SLO) expected from the service provider. SLAs are output-based in that their purpose is specifically to define what the customer will receive.

service level indicator (SLI)

The tool(s) that continuously measure your app’s performance and determine when it is breaking an SLO.

service level objective (SLO)

The contract of performance you make internally, that when broken, alert you to the problem so that you have time to address it before an SLA is broken. SLIs measure for SLOs.

Single sign-on (SSO)

Cloud Observability supports single sign-on (SSO) to help you securely manage users. With SSO, your existing Identity Provider (IdP), for example, Okta, authenticates users. Those users can then log into Cloud Observability with their Okta credentials. Cloud Observability supports SSO with OAuth2 and SSO with Security Assertion Markup Language (SAML).


Persisted view of a query’s results made in Explorer. Every query result has an associated snapshot that can be revisited and shared at anytime.



Represents a name and timed unit of work in the system that has a start time and a duration. Spans that are from the same request are built into a trace and can include nested spans. Spans often include attribute and event objects that describe and contextualize the work being performed.


span context

Represents span state that must propagate to child spans and across process boundaries (for example, a trace_id, span_id, sample_id tuple).


Span Data

The total amount of data comprising all the spans sent to Cloud Observability. An average span is about 500 bytes of data, most of which consists of the key:value attributes that are added to the span.

span references

A span may reference zero or more spans that are causally related. Cloud Observability recognizes the two types of references defined by OpenTracing/OpenTelemetry: ChildOf and FollowsFrom. Both reference types specifically model direct causal relationships between a child Span and a parent Span.

Standard Support

Cloud Observability-provided consulting for software integration and service setup. Tickets and consulting time resulting from violations of Cloud Observability’s Service Level Agreement do not count against monthly limits.


User-defined time series of trace data that matches a predicate such as a combination of service name, operation, and tag values. Streams allow you to proactively monitor the golden indicators (latency, error, ops rate) of your system that are crucial to business health. You create Streams based on a query of your services, operations, and attributes. Streams are persisted according to your Data Retention Policy.



Portion of an overall end-to-end trace. If a trace is thought of as a directed acyclic graph (DAG) of spans, then a sub-trace is simply a subgraph of the overall DAG


A key-value pair that annotates a metric and does not have a timestamp. For example, metrics might use the service tag to show what service a metric was emitted from, or the customer tag to show which customer made the request. Note that previously, the term “tag” referred to metadata on OpenTracing spans. This term has been replaced with the OpenTelemetry term “attribute.”



All the data collected and analyzed to help determine the health of your system. Typical telemetry data includes tracing, logs, and metrics.


The path of an individual transaction or request as it flows through an application. Traces are a critical part of observability, as they provide context for other telemetry. For example, traces can help define which metrics would be most valuable in a given situation, or which logs are relevant to a particular issue.


Trace Analysis table

In Cloud Observability, the table that shows span data.


trace assembly

The process by which Cloud Observability assembles individual spans into a single, logical trace of the top-most operation.

Trace view

A flame graph of a trace (each service a different color), and below that, each span in the hierarchy, allowing you to see the parent-child relationship of all the spans in the trace.


A configurable link to an external site displayed on the Trace view.


Updated Sep 15, 2021