-
Feature Request
-
Resolution: Unresolved
-
Blocker
-
None
-
None
-
False
-
None
-
False
-
Not Selected
-
-
-
-
1.Proposed title of this feature request
- Allow installation of Prometheus operators without touching built-in CRDs
2. What is the nature and description of the request?
- Request is to allow for other Prometheus operators to be installed on the cluster with the condition that the built-in CRDs are not touched, so that a custom Prometheus stack can be deployed.
- Ability to scrape built-in exporters like node-exporters/kubelet/openshift-api/openshift-state-metrics/etc in order to gather necessary metrics to create the alerts they need.
3. Why does the customer need this? (List the business requirements here)
- Customer needs to access cluster system metrics to have visibility of cluster health and trigger alerts when needed. Customer needs a custom Prometheus instance on each cluster for the following reasons:
-
- The `openshift-monitoring` namespace does not allow for custom prometheus/alerts
- The `openshift-monitoring` namespace cannot be altered as it is SRE managed
- To get access to the metrics and set up necessary alerts, they need a Prometheus instance deployed as a CR by a Prometheus operator in a different namespace other than `openshift-monitoring` so that the two operators do not conflict in any way.
- An existing RFE (RFE-4617) allows Remote-Write configuration setup in the built-in Promethus stack inside the `openshift-monitoring`namespace, but doesn't appear to meet the customer requirements as remote-writing in the SVC of an HA Prometheus cluster would result in metrics splitting between the two Promethus instances. It would act as a LB.
4. List any affected packages or components.
- Prometheus
- is related to
-
OCPBUGS-13923 Handle additional customer-installed monitoring stacks
- Closed