-
Story
-
Resolution: Obsolete
-
Normal
-
None
-
None
-
None
-
8
-
False
-
False
-
Undefined
-
For 4.6+
Support considerations for monitoring
Installing custom Prometheus instances in monitoring:
- You can install a custom Prometheus instance, the support is there.
- Remove the following from the "Support considerations for monitoring" section:
"Installing custom Prometheus instances on OpenShift Container Platform." - There are are considerations and limitations that need more explanation if the user wants to install their own version. Create a separate section to explain:
- Prometheus Operator version needs to be the same (APIs and API groups need to be the same/on the same version)
- If the user doesn't want to use a specific Prometheus Operator version, the user can install the default Prometheus Operator
- With the default installed, other components are also installed
- Add a note in the new section that recommends that the user installs the same Prometheus Operator version that is available in the default Monitoring stack if they want to install a custom instance.
- What happens if there are two different versions of the Prometheus Operator and their associated CRDs?
- The custom deployed operator might break if it is a different version than the default.
- As long as CVO is running, it checks for the expected version of the CRD
- The user needs to use the same version as what is shipped by the CMO, i.e. the default Prometheus Operator version
- Include steps on how to check the logs and/or metrics for the current, default Prometheus Operator version in Understanding the monitoring stack.
- relates to
-
RHDEVDOCS-4310 [4.6-4.7 docs] Contradictory guidance in file monitoring/exposing-custom-application-metrics-for-autoscaling.adoc #40244
- Closed