Instana to monitor Cloud Pak for Business Automation
Authors:
- Eric Giguère, ing, IBM CSM Architect IT Automation
- Rose Condon, IBM CSM Architect - IT Automation
This guide demonstrates how to use Instana, IBM’s observability platform, to monitor CP4BA effectively in such complex and dynamic environments.
Overview
IBM Cloud Pak for Business Automation (CP4BA) is a modular platform that helps organizations streamline operations, improve decision-making, and enhance customer experiences and productivity. Built on Red Hat OpenShift, it integrates key automation capabilities:
- Business process management (BPM)
- Robotic process automation (RPA)
- Document processing and content services
- Decision management and process mining
These techonolgies also leverages AI (e.g., watsonx) for intelligent automation and supports hybrid cloud deployments across public, private, and on-premises environments.
Monitoring a cloud-native platform like CP4BA presents unique challenges:
-
Dynamic and Ephemeral Infrastructure
Microservices and containers scale rapidly and shift across clusters, requiring dynamic discovery.
-
High Volume of Observability Data
Massive metrics, logs, and traces are generated across services — making correlation difficult.
-
Short-Lived Resources
Containers may terminate quickly, making persistent and centralized logging essential.
-
Distributed, Hybrid Environments
Services may span clouds, regions, and clusters — requiring a unified monitoring view.
Pre-Requisites
- OpenShift Container Platform 4.16+
- IBM Cloud Pak for Business Automation version 24.0.x +
- A workstation with oc cli installed
- Access from this workstation to the OCP cluster
- An Instana backend server SHSE (Self Hosted Standard Edition)
NOTE: This procedure will also apply to Instana on OpenShift or SaaS.
IMPORTANT: This procedure doesn't cover all the installation steps necessary in an air-gapped environment. We assume that both your workstation and the OCP cluster do have access to the Internet to download the necessary resources.
Overview of the actual OpenShift Monitoring stack
The OpenShift monitoring stack is a comprehensive, cloud-native observability solution built around Prometheus and its ecosystem. It provides real-time monitoring, alerting, and visualization for both platform components and user applications. Here's a detailed breakdown:
Core Architecture Overview The stack operates in two distinct layers managed via separate namespaces:
- Platform Monitoring (openshift-monitoring): Monitors core cluster components (enabled by default).
- User Workload Monitoring (openshift-user-workload-monitoring): Optional monitoring for user-defined applications.
Key Components and Roles
Cluster Monitoring Operator (CMO): Central orchestrator deploying, updating, and managing all monitoring components. Prometheus Operator:
- For Platform: Creates/configures Prometheus and Alertmanager instances for core infrastructure.
- For user workload: Manages dedicated Prometheus/Alertmanager for application monitoring.
Prometheus:
- Platform: Stores metrics for control plane (API server, etcd, scheduler).
- User Workload: Scrapes application metrics via ServiceMonitors.
Alertmanager: Processes alerts from Prometheus, deduplicates, and routes notifications (email/Slack/PagerDuty).
Thanos Components:
- Thanos Querier: Aggregates metrics from both platform and user Prometheus instances, providing a unified query interface.
- Thanos Ruler: Evaluates alerting rules for user-defined projects (decouples from Prometheus).
Metrics Exporters:
- node-exporter (NE): Per-node resource metrics (CPU/memory/disk).
- kube-state-metrics (KSM): Tracks Kubernetes object states (pods/deployments).
- openshift-state-metrics (OSM): Extends metrics with OpenShift-specific resources.
Metrics Server (MS): Replaces Prometheus Adapter in recent versions; provides resource metrics (CPU/memory) for kubectl top and HPA
Telemeter Client: Securely forwards subset of metrics to Red Hat for cluster health analysis.
Grafana: Pre-configured dashboards for platform metrics (read-only). Users can deploy custom instances for application dashboards.
The following diagram illustrates the interactions between the components:
Reference Red Hat documentation: OpenShift Monitoring Components
What differentiate Instana from OCP Monitoring
From a technical perspective, the OpenShift native monitoring stack — Prometheus, Thanos, and Grafana — provides strong infrastructure-level monitoring. However, it lacks deep visibility into application performance and distributed traces, making it less effective for full-stack observability.
Figure: Monitoring Features Comparison Instana vs Openshift
Configuration of the different elements
Deploying the Instana agent in the OpenShift cluster
To do this, Instana needs to have a presence in your cluster using it's agent. Deploying an Instana agent is very simple in most cases.
The Instana Agent can be installed directly from the Marketplace as shown below.
Figure: Instana Agent deployment from the Marketplace
There are also an extensive set of pre-defined recipes to help you deploy the agent easily on multiple platforms. The following screenshot demonstrates that built-in capability in Instana. We highlight the one we will use in this article: The OpenShift Operator.
Figure: Choose the Instana Agent deployment type: OpenShift operator
Choosing that option will bring you to the following page:
Figure: Deployment recipe for the Instana Agent as an OpenShift operator
So, from here, you will need to open a session on your workstation. Instana proposes a command that will immediately execute the manifest to proceed with the installation. It is recommended first to download this manifest first and review it. You will see the different resources that will be installed and validate with your cluster administrators if all is clear with their policies.
oc login --token=sha256~***the-token*** --server=https://your_ocp_api_server:6443
wget https://github.com/instana/instana-agent-operator/releases/latest/download/instana-agent-operator.yaml
vi instana-agent-operator.yaml
oc apply -f instana-agent-operator.yaml
oc apply -f https://github.com/instana/instana-agent-operator/releases/latest/download/instana-agent-operator.yaml
Once this installation is completed, you will have all the necessary resources available on your OpenShift cluster to deploy and instance of the Instana Agent. You can validate that all is good running these commands:
oc get project instana-agent
oc get sa instana-agent-operator -n instana-agent
oc get pods -n instana-agent | grep controller
The following diagram shows all the components that should be created when installing the Instana Agent operator resources:
Figure: Instana Agent Architecture
Now that we have the Instana Agent operator running, we will deploy the agents themselves. Note here that we are talking about agents, many. The operator will deploy one agent pod per Kubernetes node, including the masters. You may have guessed that we are referring here in the Kubernetes world to a resource called: DaemonSet. These workload controllers make sure to have 1 and only 1 instance of a pod running per node, and on each node of the cluster.
Since we have an operator, we have access to new type of resources in our cluster (CRDs for Custom Resource Definitions). One of those is: InstanaAgent. With this single declarative element, all the necessary Kubernetes resources will be deployed and managed.
We can see that we have an operator running by executing the following command:
oc get pod -l app.kubernetes.io/name=instana-agent-operator -n instana-agent
No matter which technique you use to deploy your Agent operator (from the CLI or from the OCP Console / Marketplace), you must prepare the CR (Custom Resource) to deploy the Agent instances. These will gather all the information and send them to the backend server.
So now we execute steps 2 and 3 in the recipe for deployment as shown in the figure: Deployment recipe for the Instana Agent as an OpenShift operator. Adapt your values for the Cluster name and the Agent Zone you want to see in your setup. The yaml file to deploy and Instana Agent instance will look like this. Note we leave the configuration_yaml section empty for now:
apiVersion: instana.io/v1
kind: InstanaAgent
metadata:
name: instana-agent
namespace: instana-agent
spec:
zone:
name: montreal
cluster:
name: riks2
agent:
key: your_instana_salesID
downloadKey: your_instana_agent_key
endpointHost: agent-acceptor.riks-instana.storage.mtl.can.ibm.com
endpointPort: "443"
env: {}
configuration_yaml: |
# You can leave this empty or use this to configure your instana agent.
# See https://docs.instana.io/setup_and_manage/host_agent/on/kubernetes/
Save this content in a file : instana-agent.customresource.yaml
And now, apply this to your cluster with this command:
oc apply -f instana-agent.customresource.yaml
You can check that your agent was properly deployed and that it is communicating with the backend server by doing the following sanity checks:
Run the following command and validate that you have a series of pods named: instana-agent-xxxx and instana-agent-k8ssensor-xxxxx running on each node of your cluster:
oc get pods -l app.kubernetes.io/instance=instana-agent -n instana-agent
In order to validate that the agents are communicating with the backend, you have to go to the Instana UI on the Agents page. Your agent instances should show up:
Figure: Instana agents list page
Enabling Metrics in the IBM Cloud Pak Foundational Services
The first thing to do is to enable the metrics for the Foundational Services that are installed with most if not all the Cloud Paks. Doing so is quite straight-forward. Replace the <your_commonservice_namespace> by the value where it is installed, typically along with other CP4BA components.
oc patch CommonService common-service --type merge -p '{"spec": {"enableInstanaMetricCollection": true}}' -n <your_commonservice_namespace>
Reference IBM Documentation: Enabling Instana metric collection for foundational services
Enabling metrics in the IBM Cloud Pak for Business Automation
Enabling metrics in IBM Cloud Pak for Business Automation (CP4BA) is a key step for monitoring with Instana, Prometheus. This typically involves modifying the Custom Resource (CR) used to deploy CP4BA components.
You can retrieve a copy of the actual CR by running the following command:
oc get icp4acluster -n <your_cp4ba_cluster>
oc get icp4acluster cp4a -o yaml -n <your_cp4ba_cluster> > cp4acluster.yaml
Edit this file (cp4acluster.yaml) with your favorite editor, you have to add the following lines in the right section of this CR. Some explanations of what is following:
monitoring_configuration section: In this section, we set parameters that are common to all components.
ecm_configuration: You see in there that we must set values for the different components of CP4BA including: cmis, cpe, css, etc.
There may be other components also that can produce metrics. The same patterns apply. Refer to IBM's CP4BA documentation for more details.
monitoring_configuration:
collectd_disable_host_monitoring: false
collectd_interval: 10
collectd_plugin_write_prometheus_port: 9103
mon_enable_plugin_mbean: true
mon_enable_plugin_pch: true
mon_metrics_writer_option: 4
...
ecm_configuration:
cmis:
monitor_enabled: true
cpe:
monitor_enabled: true
css:
monitor_enabled: true
es:
monitor_enabled: true
graphql:
monitor_enabled: true
...
navigator_configuration:
monitor_enabled: true
...
workflowAuthoring:
monitoring:
enabled: true
workflowRuntime:
monitoring:
enabled: true
...
decisionServerRuntime:
monitoring:
enabled: true
Adapting the CP4A CR to be discovered by the Instana Agent
The following yaml extract are specifically modified to enable the automatic discovery of the Prometheus metric endpoints in CP4BA. For this purpose, we use a specific tag available in the CR of CP4ACluster entities: custom_annotations.
custom_annotations: These are part of all section where we want the monitoring capabilities. Instana has a built-in mechanism to automatically discover Prometheus endpoints running in Kubernetes deployments. But in order for this auto-discovery to work, we need to have those annotations applied on the Deployment resources. These are the standard Prometheus annotation. Each Pods that produces Prometheus metrics should have these defined so that tools like Instana will be able to discover them.
Add the following lines to the existing section in your cp4acluster.yaml CR definition:
...
ecm_configuration:
cmis:
custom_annotations:
prometheus.io/path: /
prometheus.io/port: "9103"
prometheus.io/scrape: "true"
cpe:
custom_annotations:
prometheus.io/path: /
prometheus.io/port: "9103"
prometheus.io/scrape: "true"
css:
custom_annotations:
prometheus.io/path: /
prometheus.io/port: "9103"
prometheus.io/scrape: "true"
es:
custom_annotations:
prometheus.io/path: /
prometheus.io/port: "9103"
prometheus.io/scrape: "true"
graphql:
custom_annotations:
prometheus.io/path: /
prometheus.io/port: "9103"
prometheus.io/scrape: "true"
...
navigator_configuration:
custom_annotations:
prometheus.io/path: /
prometheus.io/port: "9103"
prometheus.io/scrape: "true"
Once this is all done, you can apply the CR to your CP4BA cluster. It will take approximately 10 to 30 minutes for the operator to complete the process.
oc apply -f cp4acluster.yaml -n <your_cp4ba_namespace>
oc get pods --all-namespaces -o json | jq -r '
.items[]
| select(.metadata.annotations["prometheus.io/port"] != null)
| "\(.metadata.namespace)/\(.metadata.name) \(.metadata.annotations["prometheus.io/port"])"
'
Validation of the metrics collection by Instana
The Instana Agent will start collecting metrics as soon as it is deployed. The discovery process is running also in a loop. So again, a certain delay will be experienced between the moment that the metrics are produced by CP4BA components and when Instana starts collecting them.
You can view that there are some in your infrastructure by typing: prometheus in the search bar at the top as shown in the screenshot below:
Figure: Instana Infrastructure view filtered with: prometheus
But that is not very precise, so by clicking on the Analyse infrastructure button on the top-left of this view, you will enter a view where you can select elements by technology discovered by the Instana agent. Select: Prometheus App as shown on the screenshot:
Figure: Instana Analyse Infrastructure page
You will have a list of endpoints that Instana discovered and validated as Prometheus metric sources. Typically we see there IP addresses with the port used. We know that our elements in CP4BA are located at the root of the URL (no path elements) and on port 9103. But if you want to be sure, click on one of the elements that satisfies those criteria, and from this page, open the Stack using the Stack button. All doubts will be eliminated; you will clearly see on what components you are as shown below:
Figure: Details of a Prometheus endpoint in Instana
Configuring the CP4BA Application in Instana
The last part, for this guide, is to define the CP4BA application in Instana. Although we have metrics, components discovered by the Instana agent, there is no way that the platform can define by itself what makes up the application. Applications, especially in Cloud Native environments, are what we can call conceptual or logical entities. An application is made up a lot of different elements, collaborating and doing interactions with users and other applications or services.
With Instana, it could not be simpler to define an application. Using the main menu on the left, choose the Applications element.
A page with 3 tabs: Applications, Services and Smar Alerts will be shown. Click on the "+ Add" button on the bottom right of this page and choose the New application perspective element from the small popup menu. Note that you must have to correct access right in Instana to see this button enabled.
In this popup, choose: Kubernetes or container application kind then hit Next button
Figure: Instana New application perspective page 1
After hitting Next, you will be presented with the page where you specify the filters to use to get all the application components. We will go with a high-level criteria, everything in the namespace cp4a (or the name of the namespace you have for CP4BA). Add a criterion for kubernetes.namespace.name with the correct value as shown below. If your filter is valid, you will see the Matched sevices in the last hour on the right filled with values.
Then, hit Next button.
Figure: Instana New application perspective page 2
The last step is to give your application perspective a name, CP4BA here, and selecting the calls we are interested in. Choose the All calls value. Then hit the Create button.
Figure: Instana New application perspective page 3
You're done, now you have a fully functional Application Perspective in Instana for CP4BA. Instana starts monitoring the different metrics as well as the traffic between the components, showing in a specialized view (the Dependencies), the links between them.
Figure: Instana CP4BA default Dashboard view
Figure: Instana CP4BA Dependencies view
Exploring the metrics
Instana allows you to seamlessly explore and visualize custom metrics through powerful dashboards, tagging, and filtering, making it easy to gain deep insights into your application and infrastructure performance.
Figure: Instana Prometheus Metrics search page
Full-Stack Metrics for CP4BA on OCP
Instana’s monitoring of Cloud Pak for Business Automation (CP4BA) on OpenShift (OCP) focuses on three key metric categories, each associated with a specific layer: OCP Metrics, CP4BA Platform Metrics, and CP4BA Component/Service Metrics.
- OCP Metrics
- Cluster Health: Node status (ready/not ready), CPU/Memory utilization at the cluster and node level
- Resource Utilization: Pod CPU/Memory requests vs. limits vs. actual usage, namespace resource consumption
- Network Performance: Network I/O for nodes and pods
- Kubernetes Events: Pod restarts, image pull errors, deployment failures
- Storage: Persistent Volume (PV) and Persistent Volume Claim (PVC) usage, I/O performance
- Instana’s Value Proposition:
- Automatic Discovery: discovers the entire OCP topology (nodes, namespaces, deployments, pods, services) and relationships
- Contextualized Views: Provides pre-built dashboards for OCP
- Real-time Insights: granularity metrics for rapid issue detection
- Integration with underlying infrastructure
- CP4BA Platform Metrics
- Platform Component Health: Status of CP4BA foundational services
- Shared Service Performance: Latency or error rates for common API gateways
- Resource Consumption by Shared Services: CPU/Memory/Disk usage of CP4BA-specific common services
- Licensing & Resource Consumption: Potentially, metrics related to capacity or resource usage relevant for licensing if exposed
- Instana’s Value Proposition:
- Deep Sensor Coverage
- Dynamic Graph Integration
- AI-Powered Alerting
- CP4BA Components/Services Metrics
- Application Performance Metrics: Latency for specific service endpoints or business transactions
- Business Transaction Metrics (via Tracing)
- Queue Depths/Processing Latency
- Instana’s Value Proposition:
- Automated Distributed Tracing
- Service Maps
- Code-Level Visibility
- Automated Root Cause Analysis
Conclusion
By integrating Instana with Cloud Pak for Business Automation (CP4BA) on OpenShift, teams gain full-stack observability across infrastructure, platform services, and application components. Unlike the native OpenShift monitoring stack, Instana offers real-time distributed tracing, deep application-level insights, and intelligent context mapping — essential for diagnosing complex automation workloads.
Following the steps in this guide ensures that key metrics are enabled, collected, and visualized effectively, allowing teams to proactively monitor, troubleshoot, and optimize their CP4BA environments with confidence.