This glossary provides terms and definitions for Instana.

While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.



A record of an event indicating a fault in the managed environment.

alert channel

An integration with an external alert management and notification tool to receive alert notifications to your alert integration in real time.


A deviation from the expected baseline behaviors.

anomaly detection

The identification of data points, items, observations or events that do not conform to the expected pattern of a given group.


The means to continuously analyze code-level performance, discover bottlenecks in production code, visualize performance with a flame graph, and dig deep into the application's "hot paths". See Analyzing profiles.

AutoTrace WebHook

A Kubernetes and OpenShift-compatible admission controller mutating webhook that automatically configures the Instana tracing on Node.js, .NET Core, Ruby and Python applications that run across the entire Kubernetes or OpenShift cluster, and on IBM MQ and ACE that run in IBM Cloud Pak for Integration.


One or more computer programs or software components that provide a function in direct support of a specific business process or processes.

application perspectives

The means to tailor your view of an application and to capture the type of semantics and information thatyou need to optimize the applications and services you are responsible for. See Application perspectives.



The Instana server.

backend correlation

The means to create links between user activity, for example website visits, and the work created on the backend or server-side. See Backend correlation.



A communication between two services and can be seen as a request and a response where the response can be asynchronous.


An ordered list of code executions, such that whenever code invokes other code, the new code is put onto the top of that stack. Callstacks are used by runtimes of all programming languages, and they can usually be seen printed out as “stacktrace” when errors occur as they allow “tracing back” to what calls led to the error.


The core functions of a service. For example, the XYZ service provides "monitoring" capability.

comparison table

The means to sort and quickly find the servers and boxes that you would like to look at. See Comparison table.

context guide

A visual representation of Application Perspective services and related underlying infrastructure. Behind the scenes, it is driven by Instana's powerful Dynamic graph, a core component of Instana in which all the physical components of your infrastructure are tracked and associated with their logical counterparts and automatically kept up to date when changes occur. See Context guide.


distributed tracing

Tracing across multiple systems, such as cloud to cloud, cloud to on-prem, etc.

dynamic focus

The robust search and filter function that is capable of searching through all of data contexts simultaneously. Microservice architectures utilize a complex variety of data contexts that are all clustered together under one hood. Dynamic Focus is capable of filtering across these to provide a strong system-wide understanding for the user. See Filtering with dynamic focus.

dynamic graph

The model of your application that understands all the physical and logical dependencies of components such as Host, OS, JVM, Cassandra Node, MySQL, etc. The graph also includes logical components such as traces, applications, services, clusters, and tablespaces. Components and their dependencies are automatically discovered by our agent and sensors, which means the graph is kept up to date in real-time. See Leveraging the dynamic graph.



Public API of a service, to expose specific commands to the rest of the system.


The fault in an event that causes a failure.


A change in state of a service or system.

end-user monitoring (EUM)

The means to collect monitoring data from end-users' web browsers and mobile devices.



The surfacing of an error to the user.


An error in the internal state of a component in a system.



Either physical, virtual or “as a service”. Each host has resources like CPU, memory and IO that can be a bottleneck. Each hosts runs in one zone.

host agent

The means by which data is collected and aggregated from various sensors on your hosts before it sends the data to the Instana backend. See Host agent.



An unplanned interruption that causes, might cause, or reduces the quality of an IT service.

infrastructure map

An overview of all monitored systems, which are grouped by named zones (two-dimensional colored rectangles). Within each zone are pillars comprised of opaque blocks. Each pillar as a whole represents one connectors running on the respective system. Each block within the pillars represents the software components running on that system, and will change color to reflect the component's health. Specific types of components can be processes (a JVM or an Apache process), or specific servers running within those processes, such as a Tomcat server within a JVM. See Infrastructure map.

infrastructure monitoring

Typically hardware monitoring, such as CPU, memory, disk IO, network IO.


Modifying code to collect traces, performance data, business data, logs.


Any independent application that provides additional capabilities to an IBM service or base product.


An event that gets created if an application, service, or any part of it gets unhealthy. Instana comes with several hundreds of out-of-the-box curated health signatures detecting various problems ranging from degradations of service quality, to complex infrastructure issues, to disk saturation. Issues are automatically resolved as soon as the metrics, events, or metadata returns to the expected values.


log analytics

Log collection and indexing.



An architectural pattern where various loosely coupled services work together to form an application. Each of these services focus on one single purpose only, encapsulating all related logic and data. Communications between services are conducted over well-defined APIs.

mobile monitoring

EUM/RUM for mobile applications.


out-of-the-box tools

Tools that provide a set of functionalities that works immediately after installation with hardly any configuration or modification needs. When it's applied to the software delivery, a one-stop solution allows quick setup of a deployment pipeline.


pipeline feedback

An automatic analysis of application development and deployment pipeline events, correlated directly with application, infrastructure, and service performance data. See Pipeline feedback.


A form of dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls.


A program to generate a profile for the purpose of immediate or later analysis.


Collecting low-level performance data, down to line of code, for CPU and memory usage.



A physical or logical component that can be provisioned or reserved for an application or service instance. Examples of resources can include storage, processors, memory, clusters, and VMs.


Real User Monitoring.



Known as on-premises, which means that the data collection backend runs within the customers data center and therefore no customer data get outside of the firewall.

self-hosted backend

The Instana backend that is installed on on-premises environments.


Instana's custom built software designed to monitor a specified technology. For example, the ActiveMQ sensor is used to monitor ActiveMQ, and this sensor is automatically deployed and installed after you install the Instana agent. See Agent sensors.


A set of capabilities that provide functionality to a product.

service level indicators (SLI)

A quantitative measure of some aspect of a service. To monitor the health of a service, you need to understand which behaviors matter for that service and how to measure and evaluate those behaviors. Each behavior that you focus on can be an SLI.

service level objectives (SLO)

A target value for a service level that is measured by SLIs. It's a measurable reliability target over a period, such as 7 days. SLO can be represented as: SLI ≤ <upper_bound> or SLI >= <lower_bound>.

See Service level objectives (SLO).

smart alerts

The means to automatically generate alerting configurations so you can receive alerts based on out-of-the-box blueprints such as website slowness, JavaScript errors, and HTTP status codes. See Smart Alerts


Represents timing of code execution (literally an action with its start and end times). It also carries a set of data consisting of both a timestamp and a duration.

Synthetic monitoring

Also known as proactive monitoring, can simulate actions that an end-user takes on an application from different locations, and continuously monitor at a specific interval for performance like availability, response time. See Synthetic monitoring (Technology Preview).

Synthetic PoP (point of presence)

The agent where the Synthetic tests are executed. It runs as a set of Kubernetes pods in the Kubernetes cluster.



The representation of a single request and its path through a system of services.


A piece of code that collects spans.


A formal record of identified issues or requests that are created against an item and assigned to appropriate users to resolve those issues or complete the requests.


An arrangement of specific, interconnected assets and resources within a network or application.


Unbounded analytics

The means to generate new insights from all unsampled, high-cardinality data. See Unbounded analytics.



An HTTP-based callback function that allows lightweight, event-driven communication between two applications.



Zones can be in different continents and regions. They can fail or have different performance characteristics.