Red Hat SummitEste conteúdo não está disponível no idioma selecionado.
Chapter 2. Getting started
2.1. Maintenance and support for monitoring
Not all configuration options for the monitoring stack are exposed. The only supported way of configuring Red Hat OpenShift Service on AWS monitoring is by configuring the Cluster Monitoring Operator (CMO) using the options described in the Config map reference for the Cluster Monitoring Operator. Do not use other configurations, as they are unsupported.
Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the Config map reference for the Cluster Monitoring Operator, your changes will disappear because the CMO automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
Installing another Prometheus instance is not supported by the Red Hat Site Reliability Engineers (SRE).
2.1.1. Support considerations for monitoring
Backward compatibility for metrics, recording rules, or alerting rules is not guaranteed.
The following modifications are explicitly not supported:
-
Creating additional
ServiceMonitor,PodMonitor, andPrometheusRuleobjects in theopenshift-*andkube-*projects. Modifying any resources or objects deployed in the
openshift-monitoringoropenshift-user-workload-monitoringprojects. The resources created by the Red Hat OpenShift Service on AWS monitoring stack are not meant to be used by any other resources, as there are no guarantees about their backward compatibility.NoteThe Alertmanager configuration is deployed as the
alertmanager-mainsecret resource in theopenshift-monitoringnamespace. If you have enabled a separate Alertmanager instance for user-defined alert routing, an Alertmanager configuration is also deployed as thealertmanager-user-workloadsecret resource in theopenshift-user-workload-monitoringnamespace. To configure additional routes for any instance of Alertmanager, you need to decode, modify, and then encode that secret. This procedure is a supported exception to the preceding statement.- Modifying resources of the stack. The Red Hat OpenShift Service on AWS monitoring stack ensures its resources are always in the state it expects them to be. If they are modified, the stack will reset them.
-
Deploying user-defined workloads to
openshift-*, andkube-*projects. These projects are reserved for Red Hat provided components and they should not be used for user-defined workloads. -
Enabling symptom based monitoring by using the
Probecustom resource definition (CRD) in Prometheus Operator. -
Manually deploying monitoring resources into namespaces that have the
openshift.io/cluster-monitoring: "true"label. -
Adding the
openshift.io/cluster-monitoring: "true"label to namespaces. This label is reserved only for the namespaces with core Red Hat OpenShift Service on AWS components and Red Hat certified components. - Installing custom Prometheus instances on Red Hat OpenShift Service on AWS. A custom instance is a Prometheus custom resource (CR) managed by the Prometheus Operator.
2.1.2. Support version matrix for monitoring components
The following matrix contains information about versions of monitoring components for Red Hat OpenShift Service on AWS 4.12 and later releases:
| Red Hat OpenShift Service on AWS | Prometheus Operator | Prometheus | Metrics Server | Alertmanager | kube-state-metrics agent | monitoring-plugin | node-exporter agent | Thanos |
|---|---|---|---|---|---|---|---|---|
| 4.19 | 0.81.0 | 3.2.1 | 0.7.2 | 0.28.1 | 2.15.0 | 1.0.0 | 1.9.1 | 0.37.2 |
| 4.18 | 0.78.1 | 2.55.1 | 0.7.2 | 0.27.0 | 2.13.0 | 1.0.0 | 1.8.2 | 0.36.1 |
| 4.17 | 0.75.2 | 2.53.1 | 0.7.1 | 0.27.0 | 2.13.0 | 1.0.0 | 1.8.2 | 0.35.1 |
| 4.16 | 0.73.2 | 2.52.0 | 0.7.1 | 0.26.0 | 2.12.0 | 1.0.0 | 1.8.0 | 0.35.0 |
| 4.15 | 0.70.0 | 2.48.0 | 0.6.4 | 0.26.0 | 2.10.1 | 1.0.0 | 1.7.0 | 0.32.5 |
| 4.14 | 0.67.1 | 2.46.0 | N/A | 0.25.0 | 2.9.2 | 1.0.0 | 1.6.1 | 0.30.2 |
| 4.13 | 0.63.0 | 2.42.0 | N/A | 0.25.0 | 2.8.1 | N/A | 1.5.0 | 0.30.2 |
| 4.12 | 0.60.1 | 2.39.1 | N/A | 0.24.0 | 2.6.0 | N/A | 1.4.0 | 0.28.1 |
The openshift-state-metrics agent and Telemeter Client are OpenShift-specific components. Therefore, their versions correspond with the versions of Red Hat OpenShift Service on AWS.
2.2. Accessing monitoring for user-defined projects
When you install a Red Hat OpenShift Service on AWS cluster, monitoring for user-defined projects is enabled by default. With monitoring for user-defined projects enabled, you can monitor your own projects without the need for an additional monitoring solution.
The dedicated-admin user has default permissions to configure and access monitoring for user-defined projects.
Custom Prometheus instances and the Prometheus Operator installed through Operator Lifecycle Manager (OLM) can cause issues with user-defined project monitoring if it is enabled. Custom Prometheus instances are not supported.
Optionally, you can disable monitoring for user-defined projects during or after a cluster installation.
2.3. Disabling monitoring for user-defined projects
As a dedicated-admin, you can disable monitoring for user-defined projects. You can also exclude individual projects from user workload monitoring.
2.3.1. Disabling monitoring for user-defined projects
By default, monitoring for user-defined projects is enabled. If you do not want to use the built-in monitoring stack to monitor user-defined projects, you can disable it.
Prerequisites
- You logged in to OpenShift Cluster Manager.
Procedure
- From the OpenShift Cluster Manager Hybrid Cloud Console, select a cluster.
- Click the Settings tab.
Click the Enable user workload monitoring check box to unselect the option, and then click Save.
User workload monitoring is disabled. The Prometheus, Prometheus Operator, and Thanos Ruler components are stopped in the
openshift-user-workload-monitoringproject.
2.3.2. Excluding a user-defined project from monitoring
Individual user-defined projects can be excluded from user workload monitoring. To do so, add the openshift.io/user-monitoring label to the project’s namespace with a value of false.
Procedure
Add the label to the project namespace:
oc label namespace my-project 'openshift.io/user-monitoring=false'
$ oc label namespace my-project 'openshift.io/user-monitoring=false'Copy to Clipboard Copied! Toggle word wrap Toggle overflow To re-enable monitoring, remove the label from the namespace:
oc label namespace my-project 'openshift.io/user-monitoring-'
$ oc label namespace my-project 'openshift.io/user-monitoring-'Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIf there were any active monitoring targets for the project, it may take a few minutes for Prometheus to stop scraping them after adding the label.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}