UMA agent does not work in OpenShift 3.11
Article ID: 273150
Updated On:
Products
Issue/Introduction
We need to monitor the OpenShift environment in version 3.11, supported by Broadcom according to the documentation.
Install and Configure UMA for OpenShift (broadcom.com)
However, when enabling the UMA agent in the OpenShift 3.11 environment, some applications were impacted.
Environment
Release : 23.1
Resolution
OpenShift 3.11 is Officially End of Support on June 2022
Is Openshift 3.11 EOL https://access.redhat.com/support/policy/updates/openshift
https://access.redhat.com/support/policy/updates/openshift_noncurrent
3.0 & 3.1 3.2 & 3.3 3.4 & 3.5 3.6 & 3.7 3.9 & 3.10 3.11
Jun 2022
https://hub.docker.com/r/caapm/universalmonitoragent
https://ca-broadcomcsm.wolkenservicedesk.com/wolken/esd/knowledgebase_list?articleId=272050
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
https://hub.docker.com/r/caapm/universalmonitoragent
https://ca-broadcomcsm.wolkenservicedesk.com/wolken/esd/knowledgebase_list?articleId=272050
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.
-
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
Feedback
