Overview

As organizations adopt Cloud Pak for Business Automation (CP4BA) 25.0.1, observability becomes a critical component for ensuring reliability and performance across complex microservices. Instana, IBM’s observability platform, provides real-time monitoring of applications, containers, and infrastructure, enabling teams to detect anomalies, troubleshoot faster, and optimize resource usage. The integration of Instana with CP4BA is designed to deliver:

1. End-to-End Visibility - From Kubernetes clusters to CP4BA capabilities like BAW, ODM, ADS, FNCM, and BAI.

2. Automated Tracing - Dynamic instrumentation for Java and non-Java workloads.

3. Metrics & Logs Correlation - Unified view for performance analysis and root cause detection.

More specifically, this comprehensive observability is achieved through automated tracing that captures distributed transaction flows across all CP4BA components, metrics correlation that unifies Golden Signals (latency, traffic, errors, saturation) with business KPIs, and log aggregation that contextualizes application logs with trace IDs for rapid root cause analysis, all presented in a unified dashboard that enables platform administrators to visualize the entire automation stack from infrastructure through business processes, ultimately reducing Mean Time To Resolution (MTTR) through proactive anomaly detection, enabling data-driven capacity planning based on actual resource utilization patterns, and providing the operational intelligence necessary to maintain SLAs in production CP4BA environments. This blog consolidates best practices, lessons learned from recent testing, and recommendations for deploying Instana in CP4BA environments. 

Best Practices for Instana Integration

1. Deployment Strategy

Installing External Instana Host for CP4BA Monitoring

There are typically two editions of Instana hosts that can be installed, the Standard edition or Classic edition. You can use the Self-Hosted Standard Edition only for new installations. However, you can migrate data from a Self-Hosted Classic Edition (Docker) to your Standard Edition. In the blog we will discuss more details about the most common approach to install the standard edition in an online environment.

To install a single-node cluster, run the following command:

stanctl up

To install a multi-node cluster, run the following command on node0 (instana0):

stanctl up --multi-node-enable

Then the user can follow a series of prompts to select their dedicated version and parameters and the script will finalize the host installation

? Choose installation type: demo
? Enter the download key or an official agent key: **********************
? Enter the sales key: **********************
? Enter the domain under which Instana will be reachable: instana.example.com
? Enter your tenant name: marketing
? Enter your unit name: test
? Enter Instana admin password: *****
? Confirm Instana admin password: *****
? Enter TLS certificate file (hit ENTER to auto-generate):
? Select Instana version to install:

[Use arrows to move, type to filter]
> 3.281.433-0
  3.279.369-0

Installing Instana Agents in Existing CP4BA Deployment for Monitoring

The preferred methos for users to install Instana agents are either through OLM or Manually, where OLM is more recommended since it is more straight forward. 

Installing Instana Agents via OLM(Operator Lifecycle Manager)

Step 1 - Create a dedicated namespace for example, “instana-agent“ namespace to deploy the operator and agents pods.

Step 2 - User can log into the cluster OCP dashboard where CP4BA environment is deployed and to be monitored. From operatorhub, search for Instana Agent Operator, click “Install“.

Step 3 - Create and Apply the dedicated Custom Resource File to the dedicated Instana namespace in the cluster, for example:

apiVersion: instana.io/v1
kind: InstanaAgent
metadata:
  name: instana-agent
  namespace: instana-agent
spec:
  zone:
    name: instana-ocp4xgcg # (optional) name of the zone of the host
  cluster:
      name: <Instana Namespace>
  agent:
    key: <Key>
    downloadKey: <Doanlowd Key>
    endpointHost: agent-acceptor.<hostname>
    endpointPort: <Port Number>
    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/

Step 4: Check and make sure that Instana Agent pods are successfully deployed in the dedicated namespace. Now Instana Agent should be connected to the CP4BA environment and ready for monitoring.

NAME                                                READY   STATUS    RESTARTS   AGE
instana-agent-2jz89                                 1/1     Running   0          14d
instana-agent-2w9ch                                 1/1     Running   0          14d
instana-agent-2zvrs                                 1/1     Running   0          14d
instana-agent-4hmz7                                 1/1     Running   0          14d
instana-agent-57vs9                                 1/1     Running   0          14d
instana-agent-9klks                                 1/1     Running   0          14d
instana-agent-b6n8t                                 1/1     Running   0          14d
instana-agent-controller-manager-568798b565-mjlbj   1/1     Running   0          14d
instana-agent-fm7rr                                 1/1     Running   0          14d
instana-agent-fr848                                 1/1     Running   0          14d
instana-agent-fx2ds                                 1/1     Running   0          14d
instana-agent-k8sensor-586876576b-78x9k             1/1     Running   0          14d
instana-agent-k8sensor-586876576b-8kv2w             1/1     Running   0          14d
instana-agent-k8sensor-586876576b-hprgv             1/1     Running   0          14d
instana-agent-lq795                                 1/1     Running   0          14d
instana-agent-mf9nk                                 1/1     Running   0          14d
instana-agent-p86zn                                 1/1     Running   0          14d
instana-agent-q8qfq                                 1/1     Running   0          14d
instana-agent-t68cg                                 1/1     Running   0          14d
instana-agent-t7qpk                                 1/1     Running   0          14d
instana-agent-x5z26                                 1/1     Running   0          14d

Installing Instana Agents in Virtual Machine 

In some cases, it is also necessary for users to setup Instana Agents for VMs that are LDAP, Databases server etc to monitor the detailed usage or workloads for their VMs. For example, in a realistic scenario, a user might want to monitor and get the alert when the usage of certain databases or the disk usage of the DB server is approaching its full limit, which requires setting up the Instana agent in that server first prior to setting up an alert for disk usage monitoring.

The installation process is usually straightforward by installing the agent by the automated (one-liner) script such as:

curl -o setup_agent.sh https://setup.instana.io/agent && chmod 700 ./setup_agent.sh && sudo ./setup_agent.sh -a <key value> -d <key value> -t dynamic -e agent-acceptor.cp4ba-instana.fyre.ibm.com:443

2. Shared Configuration Parameters and Operator-Level Enhancements

For 25.0.1, some additional changes were made to better integrate Instana into the operator framework. Therefore, the additional parameter can now be added to the CP4BA Custom Resource to implement operator level changes. User can simply set the parameter to true to enable CP4BA support of Instana monitoring.

shared_configuration:
      sc_enable_instana_metric_collection: true 

Expected Results: Any Java Containers are expected to contain instana-autotrace as labels

  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/instance: icp4adeploy-awsins1
    app.kubernetes.io/managed-by: Operator
    app.kubernetes.io/name: workflow-server
    app.kubernetes.io/version: 25.0.1
    apps.kubernetes.io/pod-index: "0"
    com.ibm.cp4a.networking/egress-allow-cpfs: "true"
    com.ibm.cp4a.networking/egress-allow-k8s-services: "true"
    com.ibm.cp4a.networking/egress-allow-same-namespace: "true"
    com.ibm.cp4a.networking/egress-deny-all: "true"
    com.ibm.cp4a.networking/egress-external-app: "true"
    com.ibm.cp4a.networking/egress-external-app-component: BAW
    controller-revision-hash: icp4adeploy-awsins1-baw-server-c98bdcf8
    instana-autotrace: "false"
    release: 25.0.1
    statefulset.kubernetes.io/pod-name: icp4adeploy-awsins1-baw-server-0
  name: icp4adeploy-awsins1-baw-server-0
  namespace: production

3. Network Policy Compatibility

Based on the current design, enabling Network Policies won’t block Instana monitoring. For example, this is what is observed in a CP4BA 25.0.1 Runtime environment after both Instana is enabled and network policy is created. We can observe that for BAW Runtime, API Calls for icp4adeploy-awsins1-baw-server-0: Still functioning, not impacted by network policy restriction. 

4. Metrics Behavior and Enabling and Configuring Instana Alerts for Issues in CP4BA Environment

a. Use “zone” for multiple clusters

Go to “Infrastructure” view:

This is particularly useful for Instana to observe multiple clusters. As a result, your clusters details would not mix up. The screenshot above is an example by zoning to identify different clusters in infrastructure view.

b.Graphical view to identify services dependencies

Go to “Applications”, then choose “Dependencies”:

The example (as screenshot above) shows the interactions between services. The dots between services are in motion in the actual UI, which represents the actual traffic. In this example, bawdos service icon is enlarged and highlighted for latency issue. Jdbc and ldap in red alerts for service failure issue.

c. Enabling Instana Alerts

For enabling Alert for Applications:

Go to “Applications” view, then choose one of the applications:

Add Smart Alert is only available from application, and alerts can be triggered from erroneous calls, slow calls, unexpected high or low calls, and HTTP status codes. Performance team favorite alerts would be slow calls, and erroneous calls. One to catch performance issue and the other alert to ensure sound condition of the services.

5.Applying Instana monitoring capabilities to resolve Client issues

Common Issue #1 - Pods not functioning – Some Kubernetes pods were technically “running” but not actually working, and CP4BA failed to detect or alert on it.

Some Kubernetes pods were technically in a Running state but were not actually performing their intended functions. CP4BA failed to detect or alert on this condition. This could cause business processes stalled because backend services were non-functional. The monitoring and prevention plan can be enabled through integrated Instana Monitoring service. 

By default, Instana has the capability to monitor and detect any unhealthy deployments, user can simply go to Platform → Kubernetes → Unhealthy deployments. Once user click into the unhealthy deploymnent they can check the details of what deployments goes wrong and the corresponding health status, error messages etc. User can look into further details by clicking the unhealthy deployment, for example, content-navigator-deploy contains one pod container in unready status.

To further customize the monitoring query, user can self-create the queries: 

1. Use Application Perspectives: Navigate to Applications → [Your CP4BA App] → Add Smart Alert.

2. Choose “Erroneous Calls” or “Unexpectedly Low Number of Calls”.

3. Scope the alert using: service.name:"cp4ba-service" AND endpoint.name:"/your-endpoint"

4. Set a threshold: Error rate > 5% for 5 minutes. Or calls/sec < 1 for 5 minutes.

Common Issue #2 - Pod restart loop: A pod tried to restart 24,000 times in 5 minutes but failed repeatedly without any alert.

The pod likely entered a CrashLoopBackOff state due to repeated container crashes. then Kubernetes attempted rapid restarts, but the underlying issue (e.g., misconfiguration, missing dependency, or resource limit) persisted. The impact would be high resource consumption on the node due to repeated container initialization, and service unavailability during the restart storm. Since default monitoring may only trigger alerts for pod status changes (e.g., NotReady) rather than restart frequency. Instana smart alert configuration is needed to monitor excessive restart counts or CrashLoopBackOff events: 

1. Infrastructure Monitoring: Go to Infrastructure → Smart Alerts → Add Smart Alert.

2. Metric Selection, choose metric “kube_pod_container_status_restarts_total“

3. Set: increase (kube_pod_container_status_restarts_total[5m]) > 1000, Severity: Critical, Time threshold: 5 minutes

4. Email, Slack, or integration with incident management tools.

Common Issue #3 - Database full – The Zen database reached capacity without generating any alert, leading to service disruption. 

Zen database reached capacity without generating any alert, and can lead to service disruption due to inability to write new data. This can be caused by many factors such as high ingestion rate of metrics/events without retention policy, or absence of dashboards or reports highlighting near-capacity conditions.

To set up the alert monitoring using Instana, user can follow the below steps.

1. Infrastructure Monitoring: Go to Infrastructure → Smart Alerts → Add Smart Alert.

2. Metric Selection, choose metric “host.disk.used_percent“

3. Set: Critical threshold > 90%, Warning threshold > 80%, Time threshold: 5 minutes

4. Filter by host or container running Zen DB: container.name:"zen-db" OR host.name:"zen-db-host"

5. Email, Slack, or integration with incident management tools.

6.Enabling external automation using Autotrace Webhook feature Instana

There are certain use case scenarios where clients might be looking at enabling additional functionalities such as taking actions to delete certain crashed pods once the workload data reached certain threshold that triggers Instana alert. This is definitely feasible with the Autotrace Webhook feature from Instana, here are the the primary approache with the Instana built-in autotrace webhook feature. 

Instana AutoTrace Webhook is primarily designed to send alert notifications to external systems when certain conditions are met (e.g., thresholds exceeded). It doesn’t directly execute remediation actions like deleting Kubernetes pods. Instead, it acts as a trigger point. Therefore, we can setup the webhook such that it can send an alert payload to: either an external script or service (e.g., a Python script, shell script, or Lambda function), or an automation platform (e.g., Ansible, Jenkins, or Kubernetes operator). Such that when the external script receives the payload sent from webhook, it can then parse the payload, identify the affected pods, and then send direct request to Kubernetes/OCP API to take further actions such as deleting the pods. Alternatively, if webhook send out the payload to CICD pipeline, then it will be able to immediately trigger a redeployment such that the environment gets redeployed, or certain sanity or regression tests to check on the root cause of the issue.

Summary

Integrating Instana with CP4BA 25.0.1 is more than just a technical exercise—it’s a strategic move to enhance observability, streamline troubleshooting, and ensure optimal performance across your automation landscape. By following best practices around deployment strategies, shared configurations, network policy alignment, and leveraging operator-level enhancements, organizations can unlock the full potential of Instana’s monitoring capabilities. Enabling alerts and metrics behavior not only improves proactive issue detection but also accelerates resolution for client challenges. Ultimately, a well-implemented Instana integration empowers teams with actionable insights, driving reliability and efficiency in complex business automation environments.

Reference: 

1. Installing Instana Host - https://www.ibm.com/docs/en/instana-observability/1.0.309?topic=installing-standard-edition-in-online-environment

2. Installing Instana Agent - https://www.ibm.com/docs/en/instana-observability/1.0.309?topic=linux-installing-agent

3. Instana Autotrace Webhook - https://www.ibm.com/docs/en/instana-observability/1.0.309?topic=kubernetes-instana-autotrace-webhook