UMA agent does not work in OpenShift 3.11
search cancel

UMA agent does not work in OpenShift 3.11


Article ID: 273150


Updated On:


DX Application Performance Management


We need to monitor the OpenShift environment in version 3.11, supported by Broadcom according to the documentation.

Install and Configure UMA for OpenShift (

However, when enabling the UMA agent in the OpenShift 3.11 environment, some applications were impacted.


Release : 23.1


OpenShift 3.11 is Officially End of Support on  June 2022

Is Openshift 3.11 EOL

3.0 & 3.1    3.2 & 3.3    3.4 & 3.5    3.6 & 3.7    3.9 & 3.10    3.11
Jun 2022

However, you can buy extended support until June 2024. 
3.X    June, 2015    June, 2021    June, 2022    June, 2024

Did your company purchase extended support for Open Shift 3.11?

From a Broadcom perspective, we support Open Shift 3.11

Agent release 2023.6.1.4 (Build 990004).

You can see from that link that 3.11 is supported for that release

2023.8.1.6 1.17 to 1.26 Openshift 3.11 to 4.12
2023.7.1.19 1.17 to 1.26 Openshift 3.11 to 4.12
2023.7.1.14 1.17 to 1.26 Openshift 3.11 to 4.12
2023.6.1.4 1.17 to 1.26 Openshift 3.11 to 4.12


There are two perspectives here:

- From the RedHat perspective, Open Shift 3.11 is only supported under certain conditions. You can read the links to see those details. That includes extended support.

- From the APM perspective, whether under Red Hat extended support or not (I am checking on this), the UMA Agent is supported for Open Shift 3.11.

3) I think we can move beyond this an understand what is happening with UMA and your agent. I asked for logs and other information. Please provide. This also sounds like a new agent deployment. Correct

Additional Information

If it happens again:

Can you provide information of what we need to collect in case the failure happens again?
Can you please provide the clusterinfo logs ideally in debug. And the logs from container info and pod monitor

If cluster metrics are not getting reported, you must check the logs of UMA's 'clusterinfo' pod.

To see the logs, execute the following command:
  • On Openshift: 
    oc logs <clusterinfo-podname> -n <UMA namespace>
  • On Kubernetes: 
    kubectl logs <clusterinfo-podname> -n <UMA namespace>
    To set in DEBUG 
  • -kubectl logs <clusterinfo-podname> -n <UMA namespace> -- Look at logs


    Set logs to DEBUG

    - Find out ClusterInfo pod (kubectl get po -A | grep clusterinfo) - Log into the ClusterInfo pod (kubectl -n <ns> exec -it <pod> -- bash) - Check and verify log file (cluserinfo.log) exists under either /tmp/clusterinfo/logs or /usr/local/openshift/apmia/logs - If log file doesn't exist either locations, open logback.xml under either /usr/local/openshift or /usr/local/openshift/apmia/core/config and check: <variable scope="local" name="logfiledir" value="${logfiledir:-/tmp/clusterinfo/logs}" /> - To turn on DEBUG for logfile/console, find and change this line in logback.xml: <variable scope="local" name="logfile_log_level" value="${logfile_log_level:-INFO}" /> <variable scope="local" name="console_log_level" value="${console_log_level:-ERROR}" /> - Alternatively, if pod restart is allowed and required, to turn on DEBUG surviving pod restart, you can also edit the clusterinfo Deployment or yaml file to add corresponding java option: -Dlogfile_log_level=DEBUG -Dconsole_log_level=DEBUG - Exit pod and copy the log file out of the pod (kubectl -n <ns> cp <pod>:<log file> clusterinfo.log