2.2. 对监控的维护和支持

并非所有监控堆栈配置选项都公开。配置 OpenShift Container Platform 监控的唯一支持的方法是，使用 Cluster Monitoring Operator 的 Cluster Monitoring Operator 的 Config map 参考中所述的选项来配置。请勿使用其他配置，因为不受支持。

各个 Prometheus 发行版本的配置范例可能会有所变化，只有掌握了所有可能的配置，才能稳妥应对这样的配置变化。如果您使用 Cluster Monitoring Operator 的 Config map 引用中描述的配置，您的更改可能会丢失，因为 Cluster Monitoring Operator 会自动协调任何区别，并将任何不支持的更改重置为最初定义的状态。

2.2.1. 对监控的支持注意事项

注意

指标、记录规则或警报规则的向后兼容性无法被保证。

明确不支持以下修改：

  • 在 openshift-* 和 kube-* 项目中创建额外的 ServiceMonitor、PodMonitor 和 PrometheusRule 对象。

  • 修改 openshift-monitoring 或 openshift-user-workload-monitoring 项目中部署的任何资源或对象。OpenShift Container Platform 监控堆栈所创建的资源并不是为了供任何其他资源使用，因为不能保证向后兼容性。

    注意

    Alertmanager 配置作为 openshift-monitoring 命名空间中的 alertmanager-main secret 资源部署。如果您为用户定义的警报路由启用了单独的 Alertmanager 实例，则 Alertmanager 配置也会部署为 openshift-user-workload-monitoring 命名空间中的 alertmanager-user-workload secret 资源。要为 Alertmanager 实例配置额外的路由，您需要对该 secret 进行解码、修改，然后再进行编码。该程序是对前述声明的一个受支持例外。

  • 修改堆栈的资源。OpenShift Container Platform 监控堆栈确保其资源始终处于期望的状态。如果修改了资源，堆栈会重置它们。
  • 将用户定义的工作负载部署到 openshift-* 和 kube-* 项目。这些项目是为红帽提供的组件保留的，不应该用于用户定义的工作负载。
  • 使用 Prometheus Operator 中的 Probe 自定义资源定义（CRD）启用基于症状的监控。
  • 在 OpenShift Container Platform 上安装自定义 Prometheus 实例。自定义资源 (CR) 是由 Prometheus Operator 管理的 Prometheus 自定义资源 (CR)。

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 内置的可靠性功能，并妨碍接收更新。在删除所有覆盖后，必须可以重现报告的问题方可获得支持。