This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.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 配置额外的路由,您需要对该 secret 进行解码、修改,然后再进行编码。该程序是对前述声明的一个受支持例外。- 修改堆栈的资源。OpenShift Container Platform 监控堆栈确保其资源始终处于期望的状态。如果修改了资源,堆栈会重置它们。
-
将用户定义的工作负载部署到
openshift-*
和kube-*
项目。这些项目是为红帽提供的组件保留的,不应该用于用户定义的工作负载。 - 修改监控堆栈 Grafana 实例。
- 在 OpenShift Container Platform 上安装自定义 Prometheus 实例。自定义资源 (CR) 是由 Prometheus Operator 管理的 Prometheus 自定义资源 (CR)。
-
使用 Prometheus Operator 中的
Probe
自定义资源定义(CRD)启用基于症状的监控。 -
使用 Prometheus Operator 中的
AlertmanagerConfig
CRD 修改 Alertmanager 配置。
指标、记录规则或警报规则的向后兼容性无法被保证。
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.
Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
设置 CVO 覆盖会使整个集群处于不受支持的状态,并导致监控堆栈无法被协调到其预期状态。这会影响 Operator 内置的可靠性功能,并妨碍接收更新。在删除所有覆盖后,必须可以重现报告的问题方可获得支持。