2.2. 对监控的维护和支持
若要配置 OpenShift Container Platform Monitoring，支持的方式是使用本文中介绍的选项。请勿使用其他配置，因为不受支持。各个 Prometheus 发行版本的配置范例可能会有所变化，只有掌握了所有可能的配置，才能稳妥应对这样的配置变化。如果使用并非本节所描述的配置，您的更改可能会丢失，因为 cluster-monitoring-operator 会调节差异。根据设计，Operator 默认将一切重置到定义的状态。
2.2.1. 对监控的支持注意事项
明确不支持以下修改：
-
在
openshift-*和kube-*项目中创建额外的ServiceMonitor、PodMonitor和PrometheusRule对象。 修改
openshift-monitoring或openshift-user-workload-monitoring项目中部署的任何资源或对象。OpenShift Container Platform 监控堆栈所创建的资源并不是为了供任何其他资源使用，因为不能保证向后兼容性。注意Alertmanager 配置作为 secret 资源部署在
openshift-monitoring命名空间中。如果您为用户定义的警报路由启用了单独的 Alertmanager 实例，则 Alertmanager 配置也将部署为openshift-user-workload-monitoring命名空间中的 secret 资源。要为 Alertmanager 实例配置额外的路由，您需要对该 secret 进行解码、修改，然后再进行编码。该程序是对前述声明的一个受支持例外。- 修改堆栈的资源。OpenShift Container Platform 监控堆栈确保其资源始终处于期望的状态。如果修改了资源，堆栈会重置它们。
-
将用户定义的工作负载部署到
openshift-*和kube-*项目。这些项目是为红帽提供的组件保留的，不应该用于用户定义的工作负载。 - 在 OpenShift Container Platform 上安装自定义 Prometheus 实例。自定义资源 (CR) 是由 Prometheus Operator 管理的 Prometheus 自定义资源 (CR)。
-
使用 Prometheus Operator 中的
Probe自定义资源定义（CRD）启用基于症状的监控。
指标、记录规则或警报规则的向后兼容性无法被保证。
2.2.2. 监控 Operator 的支持策略
监控 Operator 确保 OpenShift Container Platform 监控资源按设计和测试的方式正常工作。如果某个 Operator 的 Cluster Version Operator (CVO) 控制被覆盖，该 Operator 不会响应配置更改，协调集群对象的预期状态或接收更新。
虽然在调试过程中覆盖 Operator 的 CVO 可能有所帮助，但该操作不受支持，集群管理员需要完全掌控各个组件的配置和升级。
覆盖 Cluster Version Operator
可将 spec.overrides 参数添加到 CVO 的配置中，以便管理员提供对组件的 CVO 行为覆盖的列表。将一个组件的 spec.overrides[].unmanaged 参数设置为 true 会阻止集群升级并在设置 CVO 覆盖后提醒管理员：
Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
设置 CVO 覆盖会使整个集群处于不受支持的状态，并导致监控堆栈无法被协调到其预期状态。这会影响 Operator 内置的可靠性功能，并妨碍接收更新。在删除所有覆盖后，必须可以重现报告的问题方可获得支持。
