2.2. 对监控的维护和支持


若要配置 OpenShift Container Platform Monitoring,支持的方式是使用本文中介绍的选项。请勿使用其他配置,因为不受支持。各个 Prometheus 发行版本的配置范例可能会有所变化,只有掌握了所有可能的配置,才能稳妥应对这样的配置变化。如果使用并非本节所描述的配置,您的更改可能会丢失,因为 cluster-monitoring-operator 会调节差异。根据设计,Operator 默认将一切重置到定义的状态。

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

明确不支持以下修改:

  • openshift-*kube-* 项目中创建额外的 ServiceMonitor、MonitorMonitor 和 PrometheusRule 对象。
  • 修改 openshift-monitoringopenshift-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)启用基于症状的监控。
注意

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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.