Operational visibility and the ability to understand the internals of the IBM Cloud Pak for Integration behavior is key to maintaining the health, readiness and availability of the solutions built on top of your Cloud Pak. You can monitor components of your Cloud Pak by leveraging the out of the box monitoring stack provided by the OpenShift Container Platform 4.6+ and enhance its capabilities by deploying an open source monitoring dashboard. This configuration provides a powerful open source based solution that allows you to identify and respond to issues in a timely manner in order to guarantee the level of service and availability of your integrations.

Author:

• James Hewitt: Senior Technical Staff Member / Cloud Pak for Integration

Contributors:

• Jorge D. Rodriguez: STSM / Business Automation Solutions Architect / Automation SWAT Team

• Dr. Matthias Jung: Enterprise Content Services / Accelerated Value Specialist / Digital Business Automation - SWAT

• Kevin Trinh: STSM / Cloud Integration Architect / Digital Business Automation (ECM)

• Piotr Godowski: STSM / Cloud Pak Foundational Services Architecture

Huge thanks to Jorge who wrote How to Monitor Components of Cloud Pak for Business Automation, which is the basis for this blog post.

Overview

IBM Cloud Pak for Integration is a hybrid integration platform with an automated, closed-loop approach that supports multiple styles of integration within a single, unified experience. Unlock business data and assets as APIs, connect cloud and on-premise applications, reliably move data with enterprise messaging, deliver real-time event interactions, transfer data across any cloud and deploy and scale with cloud-native architecture and shared foundational services — all with end-to-end enterprise-grade security and encryption.

The IBM Cloud Pak for Integration provides a fully integrated platform that combines IBM’s best-in-class integration software to modernise applications and provide new opportunities. The core integration capabilities of the IBM Cloud Pak for Integration include low/no code integration development, first-class API and Event management and processing, message streaming and queuing, and high speed data transfer.

While the integration platform itself provides a low code simplified experience for business and technical users alike, system administrators and operations teams still need to deploy, manage and monitor the containerized software that makes up the IBM Cloud Pak for Integration in order to keep the platform and the solutions built on top running optimally.

In this article I will discuss how to enable monitoring capabilities on the IBM Cloud Pak for Integration and how to extend OpenShift’s pre-configured monitoring stack to provide operational visibility across Cloud Pak components.

Pre-Requisites

• OpenShift Container Platform version 4.12 and up
• IBM Cloud Pak for Integration version 16.1.0 and up
• Workstation with oc command installed

Brief Introduction to the OpenShift Monitoring Stack

The OpenShift Container Platform monitoring stack is based on the Prometheus open source project. At a high level the pre-configured stack includes one or more instances of the following components:

By default, the OpenShift monitoring stack provides monitoring capabilities for core platform components only. That is, the out of the box deployment of the monitoring stack found under the openshift-monitoring project is fully dedicated to monitoring core OpenShift Container Platform systems and other essential kubernetes services.

Optionally, since OpenShift version 4.6, the default monitoring stack deployment can be extended to monitor user-defined projects and custom deployments such as the IBM Cloud Pak for Integration installations. The additional components needed to monitor user-defined projects are automatically deployed under the openshift-user-workload-monitoring project once the default stack is configured to support user-defined projects. After the configuration is completed you will be able to collect, query, visualize and create alerts based on custom metrics generated by your own deployments. This article describes how to enable these capabilities, how to expand them using additional monitoring components provided by the IBM Cloud Pak Foundational Services and how to define the necessary kubernetes resources to collect and utilize custom metrics generated by the IBM Cloud Pak for Integration platform. For more information on how to monitor user-defined projects see the Enabling Monitoring for user-defined Projects documentation.

Enable User Project Monitoring in OpenShift

The first thing that we need to do in order to monitor IBM Cloud Pak for Integration components is to turn on user-defined project monitoring in OpenShift. To do that we need to create an instance of a ConfigMap named cluster-monitoring-config in the openshift-monitoring project. The cluster-monitoring-config ConfigMap allows you to specify the configuration details for the OpenShift monitoring stack such as enabling user project monitoring, retention policy for metrics collected, resource limits for monitoring components, node selectors for pod deployments, among other settings. For a complete list of configurable parameters see Configuring the OpenShift Monitoring Stack.

For the purpose of this article we are going to deploy a simple instance of a ConfigMap that sets the enableUserWorkload attribute to true. Setting the enableUserWorkload to true will enable monitoring for user-defined projects in addition to the default platform monitoring and will automatically trigger the deployment of additional monitoring components under the openshift-user-workload-monitoring project once the ConfigMap is created. To create the cluster-monitoring-config ConfigMap complete the following steps:

1. Create a cluster-monitoring-config.yaml file.

2. Add the following content to the file

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       enableUserWorkload: true
   

3. Use the oc command to create the ConfigMap instance

   oc apply -f cluster-monitoring-config.yaml -n openshift-monitoring

Now that the cluster-monitoring-config ConfigMap instance has been created we can verify that the additional components required for user project monitoring have been deployed under the openshift-user-workload-monitoring project. You can use the following command to list the PODs under the openshift-user-workload-monitoring project. Wait until the pods are running and ready.

oc get pods -n openshift-user-workload-monitoring

Once the additional monitoring components have been deployed successfully the output of the command should look similar to the following listing:

NAME                                        READY   STATUS    RESTARTS   AGE
prometheus-operator-5d66498b6-tgwhv         2/2     Running   0          2d4h
prometheus-user-workload-0                  4/4     Running   0          2d4h
prometheus-user-workload-1                  4/4     Running   0          2d4h
thanos-ruler-user-workload-0                3/3     Running   0          2d4h
thanos-ruler-user-workload-1                3/3     Running   0          2d4h

To customize the resources and the behavior specific to monitoring components deployed under the openshift-user-workload-monitoring project, you can create a ConfigMap named user-workload-monitoring-config under that project. This ConfigMap is analogous to the cluster-monitoring-config created under the openshift-monitoring project and allows you to further customize the deployment of components specific to user project monitoring. See Configuring the monitoring stack for additional details.

Configure Grafana

While the OpenShift monitoring stack provides most of the capabilities required to properly address observability and operational visibility requirements for your Cloud Pak, there are some limitations around the ability to visualize metrics. Specifically, the Grafana instance included in the OpenShift core monitoring stack is read only. This means that you can only visualize a predefined set of metrics through pre-configured dashboards provided by the platform. This also means that the ability to create new dashboards and visualize custom metrics has been completely removed from this installation.

Fortunately, the OpenShift catalog includes a Grafana operator that manages Grafana deployments that can connect to the OpenShift’s Prometheus instance. This configuration gives us the ability to use all metrics available in the platform, including custom metrics, so that we can create additional visualizations and dashboards on top of what is provided by the OpenShift user-defined workload monitoring stack.

Start by installing the Grafana operator from the Community catalog:

1. Open the OpenShift console
2. In the side bar, select Operators > Operator Catalog, or from OpenShift version 4.20, Ecosystem > Software Catalog.
3. Search for Grafana.
4. Select the Grafana Operator from the Community catalog.
5. Click Install.
6. Select an installation mode and a namespace.
7. Click Install.

Next, deploy an instance of Grafana:

Adjust the examples to use your own namespace, username, and password. If you change the name of the resource, you will need to change route.spec.to.name to match, as well as change a number of references in the later steps.

1. Create a grafana.yaml file.

2. Add the following content to the file

   apiVersion: grafana.integreatly.org/v1beta1
   kind: Grafana
   metadata:
     name: grafana
     namespace: grafana
     labels:
       dashboards: grafana
       folders: grafana
       datasources: grafana
       app: grafana
   spec:
     config:
       auth:
         disable_login_form: 'false'
       log:
         mode: console
       security:
         admin_password: start
         admin_user: root
     route:
       spec:
         to:
           kind: Service
           name: grafana-service
   

3. Use the oc command to create the Grafana instance

   oc apply -f grafana.yam 

4. Wait for services to install. Use the following command to monitor the installation.

   oc get pods -w -n grafana -l app=grafana

   Once the installation is completed successfully you should see output similar to the following:

   NAME                                                      READY   STATUS    RESTARTS   AGE
   grafana-deployment-687b66b4c8-445rb                       1/1     Running   0          84m
   

We now need to give Grafana access to the metrics data:

1. Create a grafana-rolebinding.yaml file.

2. Add the following content to the file

   
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: grafana-access
     namespace: openshift-monitoring
   subjects:
     - kind: ServiceAccount
       name: grafana-sa
       namespace: grafana
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: cluster-monitoring-metrics-api
   

3. Use the oc command to create the RoleBinding instance

   oc apply -f grafana-rolebinding.yaml

4. Test that the grafana service account has access to the metrics api:

   oc auth can-i get -n openshift-monitoring prometheuses.monitoring.coreos.com/k8s --as=system:serviceaccount:grafana:grafana-sa --subresource api

   You should see the following output:

   yes

Now we can generate a service account token to use to connect to the data source:

1. Create a grafana-token.yaml file.

2. Add the following content to the file

   kind: Secret
   apiVersion: v1
   metadata:
     name: grafana-token
     namespace: grafana
     annotations:
       kubernetes.io/service-account.name: grafana-sa
   type: kubernetes.io/service-account-token
   

3. Use the oc command to create the Secret instance

   oc apply -f grafana-token.yaml

4. Get the token from the secret:

   oc extract -n grafana secret/grafana-token --keys token --to -

   You should see the following output:

   # token
   <grafana service account token>

We will also need the hostname for the thanos querier endpoint:

1. Use the oc command to get the hostname:

   oc get route -n openshift-monitoring thanos-querier

   You should see the following output:

   NAME             HOST/PORT                   PATH   SERVICES         PORT   TERMINATION          WILDCARD
   thanos-querier   <thanos querier hostname>   /api   thanos-querier   web    reencrypt/Redirect   None

Finally, we can configure the grafana data source:

1. Create a grafana-datasource.yaml file.

2. Add the following content to the file, including the hostname and token values:

   apiVersion: grafana.integreatly.org/v1beta1
   kind: GrafanaDatasource
   metadata:
     name: prometheus
     namespace: grafana
   spec:
     datasource:
       access: proxy
       basicAuth: false
       isDefault: true
       name: prometheus 
       jsonData:
         httpHeaderName1: Authorization
       secureJsonData:
         httpHeaderValue1: Bearer <grafana service account token>
       type: prometheus
       url: 'https://<thanos querier hostname>'
     instanceSelector:
       matchLabels:
         datasources: grafana

3. If your cluster does not have a TLS certificate signed by a well-known certificate authority, you can add tlsSkipVerify: true to the jsonData section or tlsCACert to the secureJsonData section.

4. Use the oc command to create the GrafanaDatasource instance

   oc apply -f grafana-datasource.yaml

5. Check the resource has successfully applied:

   oc get GrafanaDatasource -n grafana openshift-monitoring -o yaml

   You should see the following output in the status. If the datasource hasn't synchonized, check the output to see what the problem is:

   status:
     conditions:
     - lastTransitionTime: "2026-02-04T14:42:02Z"
       message: Datasource was successfully applied to 1 instances
       observedGeneration: 3
       reason: ApplySuccessful
       status: "True"
       type: DatasourceSynchronized
     hash: 1f8852cb737ec81790b77fae0514df1a3b4373d91fa2ae54e64583292d318e4f
     lastResync: "2026-02-04T15:02:56Z"
     uid: be46a3de-d307-440b-8b19-51a531d4aa2f

Now that Grafana has been installed we need to find the URL that we can use to access the services:

1. The Grafana instance is accessed using a route. To find the details of the route you can run the following command:

   oc get route -n grafana -l app=grafana

   The output of the command should look similar to the following listing:

   NAME            HOST/PORT                                   PATH   SERVICES          PORT   TERMINATION   WILDCARD
   grafana-route   grafana-route-grafana.<cluster-subdomain>          grafana-service   3000   edge          None

   Use the host from the command output to access the grafana UI from your browser. Log in using the username and password you set before.

Monitoring Capabilities at the component level in the IBM Cloud Pak for Integration

The IBM Cloud Pak for Integration components automatically enable monitoring capabilities at the component level. The components automatically advertise their metrics endpoints to the OpenShift user project monitoring stack.

Access the Cloud Pak for Integration sample dashboards

Now that we have installed IBM Cloud Pak for Integration, and deployed a fully functional instance of Grafana, we can use the sample dashboards to visualize some of the metrics generated by IBM Cloud Pak for Integration components. You can create or edit dashboards directly from the Grafana user interface, and automate the deployment of dashboards by using GrafanaDashboard custom resources.

The IBM Cloud Pak for Integration dashboards are available in the ibm-integration github project.

To import a dashboard:

1. Access your new Grafana instance using the URL from the grafana route. See the previous section on how to access the Grafana dashboard.

2. Click on the Dashboards menu item in the left-hand menu.

3. Click New and select Import.

4. You can either select a file, paste a url, or paste the JSON content.
5. Click Load

Access the dashboards

1. Access your new Grafana instance using the URL from the grafana route. See the previous section on how to access the Grafana dashboard.

2. Click on the Dashboards menu item in the left-hand menu. You should be able to see the dashboards you imported for your installed IBM Cloud Pak for Integration components.

3. Click on a dashboard. You should see the selected dashboard.

   

You can now explore all custom metrics available via the IBM Cloud Pak for Integration components and expand the dashboard capabilities to include visualizations for additional metrics and components suited to your use case.

Configure Alerts Based on IBM Cloud Pak For Integration Components

Arguably one of the most important features of a monitoring system is the ability to generate notifications based on conditions or events that need to be investigated in order to prevent or address application issues and potential failures. The OpenShift Container Platform leverages the combined capabilities of Prometheus, Thanos and AlertManager to generate, correlate and route notifications to a variety of notification targets.

In previous sections of this article we were able to configure OpenShift’s monitoring stack to support user-defined projects and feed custom metrics generated by IBM Cloud Pak for Integration components into it. In this section we will learn how to leverage this setup in order to create customized alerts to monitor the behavior of the Cloud Pak. Specifically, we will create a sample alert to monitor the message throughput of an MQ queue manager. For more MQ metrics, see Metrics published by when using the IBM MQ Operator in the MQ documentation.

To define a custom alert in the OpenShift’s monitoring stack we need to create an instance of the PrometheusRule custom resource definition. This entails creating a resource of type PrometheusRule and specifying the rules that would trigger the firing of notifications using the Prometheus expression language.

1. Create a file cp4i-mq-throughput-alert.yaml.

2. Add the following content to the file:

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     name: cp4bi-mq-throughput
     namespace: <cp4i_namespace>
   spec:
     groups:
     - name: cp4isetup
       rules:
         - alert: cp4i-mq-throughput-low
           expr: rate(ibmmq_qmgr_mqput_mqput1_total{qmgr="<queue manager>"}[5m]) < 1
           for: 10m
           labels:
             severity: warning
           annotations:
             message: Potential throughput problem - queue manager is receiving no messages

   Where <cp4i_namespace> should be replaced with the name of the project where the IBM Cloud Pak For Integration has been deployed and <queue manager> should be replaced with the name of the queue manager to monitor.

3. Deploy the PrometheusRule instance using the oc apply command

   oc apply -f cp4i-mq-throughput-alert.yaml

   The output of the command should be similar to the following listing:

   prometheusrule.monitoring.coreos.com/cp4i-mq-throughput created

4. Verify the alert has been created

   oc get PrometheusRule cp4i-mq-throughput -n <cp4i_namespace>

   Where <cp4i_namespace> should be replaced with the name of the project where the IBM Cloud Pak For Integration has been deployed.

   The output of the command should be similar to the following listing:

   NAME                 AGE
   cp4i-mq-throughput   18m

To validate if your PrometheusRule instance has been properly created, you can use the OpenShift Console. From the OpenShift Console you can inspect the rule created and verify if the alert is actually being fired. For example, we can verify the cp4i-mq-throughput alert created above by completing the following procedure:

1. Open the Administrator perspective of your OpenShit Console.

2. Go to the Monitoring menu on the left-hand side of the console.

3. Select the Alerting option under the Monitoring menu.

4. By default, the Alerting panel shows platform based alerts (those monitoring OCP components and Kubernetes) that are being fired. You can expand the search to include non-platform alerts by clicking on the Clear all filters link. When all filters are removed, you should be able to see alerts that are part of the platform and custom alerts coming from user-defined projects. Notice that this panel does not show the actual instance of the PrometheusRule created in the previous step. It shows instances of alerts that are actively being fired or about to be fired when the conditions of the PrometheusRule are met. If you do not see an alert in this panel it means that the conditions for the alert have not been met.

5. To view the actual instance of the PrometheusRule previously created in this section you can click on the Alerting Rules tab found at the top of the Alerting panel. By default, the Alerting Rules panel only shows PrometheusRule instances for the platform but you can click on the Clear all filters link to include alert rules for user-defined projects. Once you clear all filters you should be able to see the cp4i-mq-throughput alert rules.

As you can see, creating alerts for components of the IBM Cloud Pak for Integration can be done using the standard mechanism provided by Prometheus to create custom alerts. A few things worth mentioning about these capabilities are:

• Once custom metrics have been scrapped by Prometheus you can use them to create alert rules. This gives you the flexibility to create alerts that are specific to the capabilities and inner workings of the IBM Cloud Pak for Integration components and to get real-time notifications based on potential threats to the reliability of your solutions.
• Custom metrics can be used in combination with functions provided by Prometheus to test for a condition. In this example, we used the rate function to calculate the rate of change of messages being put onto an MQ queue manager.
• The instance of your alert resource should be created under the namespace where the resource being monitored resides. Since we were monitoring the IBM Cloud Pak For Integration we created the alert in that namespace.

For a complete explanation of how to create alerts and the Prometheus expression language see the Alerting Rules documentation.

Conclusion

Operational visibility and the ability to understand the internals of the IBM Cloud Pak for Integration behavior is key to maintaining the health, readiness and availability of the solutions built on top of your Cloud Pak. You can monitor components of your Cloud Pak by leveraging the out of the box monitoring stack provided by the OpenShift Container Platform 4.6+ and enhance its capabilities by deploying the open source Grafana tooling. This configuration provides a powerful open source based solution that allows you to identify and respond to issues in a timely manner in order to guarantee the level of service and availability of your integrations.

Want to start your agile integration journey? See how the IBM Cloud Pak for Integration can help you.