About Red Hat OpenShift Cluster Observability Operator


Red Hat OpenShift Cluster Observability Operator 1-latest

Cluster Observability Operator 简介。

Red Hat OpenShift Documentation Team

摘要

本文档概述了 Cluster Observability Operator 功能,还包括发行注记和支持信息。

第 1 章 Cluster Observability Operator 概述

Cluster Observability Operator (COO)是 OpenShift Container Platform 的可选组件,旨在创建和管理高度可自定义的监控堆栈。它使集群管理员能够广泛地自动配置和管理监控需求,与默认的 OpenShift Container Platform 监控系统相比,为每个命名空间提供更定制和详细视图。

COO 部署以下监控组件:

  • Prometheus - 一个高度可用的 Prometheus 实例,可以使用远程写入将指标发送到外部端点。
  • Thanos Querier (可选)- 启用从中央位置查询 Prometheus 实例。
  • Alertmanager (可选)- 为不同服务提供警报配置功能。
  • UI 插件 (可选)- 通过插件增强可观察功能,用于监控、日志记录、分布式追踪和故障排除。
  • Korrel8r (可选)- 提供可观察性信号相关性,由开源 Korrel8r 项目提供支持。
  • 事件检测 (可选)- 将相关警报分组到事件中,以帮助您识别警报突发的根本原因。

1.1. COO 与默认监控堆栈相比

COO 组件独立于默认的集群内监控堆栈(由 Cluster Monitoring Operator (CMO) 部署和管理)。两个 Operator 部署的监控堆栈不会冲突。除了 CMO 部署的默认平台监控组件外,您还可以使用 COO 监控堆栈。

COO 和默认集群监控堆栈之间的主要区别显示在下表中:

Expand
功能COO默认监控堆栈

范围和集成

提供全面的监控和分析,满足企业级需求,涵盖集群和工作负载性能。

但是,它缺少与 OpenShift Container Platform 的直接集成,通常需要外部 Grafana 实例进行仪表板。

仅限于集群中的核心组件,如 API 服务器和 etcd,以及特定于 OpenShift 的命名空间。

在控制台中有与 OpenShift Container Platform 的深度集成,包括控制台仪表板和警报管理。

配置和自定义

更广泛的配置选项,包括数据保留周期、存储方法和收集的数据类型。

COO 可以使用 Server-Side Apply (SSA) 将自定义资源中单个可配置字段的所有权委派给用户,从而增强自定义。

带有有限自定义选项的内置配置。

数据保留和存储

长期数据保留,支持历史分析和容量规划

数据保留时间短,专注于短期监控和实时检测。

1.2. 使用 COO 的主要优点

部署 COO 可帮助您解决难以使用默认监控堆栈实现的监控要求。

1.2.1. 可扩展性

  • 用户可以在 COO 部署的监控堆栈中添加更多指标,该堆栈无法在没有丢失支持的情况下进行核心平台监控。
  • 您可以通过联邦从核心平台监控接收特定于集群的指标。
  • COO 支持高级监控场景,如趋势预测和异常检测。

1.2.2. 多租户支持

  • 您可以为每个用户命名空间创建监控堆栈。
  • 您可以为每个命名空间部署多个堆栈,或为多个命名空间部署单个堆栈。
  • COO 为不同团队启用独立的警报和接收器配置。

1.2.3. 可扩展性

  • 在单个集群中支持多个监控堆栈。
  • 通过手动分片启用对大型集群的监控。
  • 解决指标超过单个 Prometheus 实例功能的情况。

1.2.4. 灵活性

  • 与 OpenShift Container Platform 发行周期分离。
  • 更快的发行迭代,并对更改要求进行快速响应。
  • 独立管理警报规则。

1.3. COO 的目标用户

COO 非常适合需要高定制性、可扩展性和长期数据保留的用户,特别是在复杂的多租户企业环境中。

1.3.1. 企业级用户和管理员

企业用户需要深入的 OpenShift Container Platform 集群监控功能,包括高级性能分析、长期数据保留、趋势预测和历史分析。这些功能可帮助企业更好地理解资源使用、防止性能问题并优化资源分配。

1.3.2. 多租户环境中的操作团队

通过多租户支持,COO 允许不同的团队为其项目和应用程序配置监控视图,使其适合具有灵活的监控需求的团队。

1.3.3. 开发和运维团队

COO 提供精细的监控和可自定义的观察视图,以便在开发和操作期间进行深入故障排除、异常检测和性能调节。

1.4. 使用 Server-ide Apply 自定义 Prometheus 资源

服务器端应用是一种支持协作管理 Kubernetes 资源的功能。control plane 跟踪不同的用户和控制器如何管理 Kubernetes 对象中的字段。它引入了字段管理器的概念并跟踪字段的所有权。这种集中控制提供了冲突检测和解决方案,并降低意外覆盖的风险。

与 Client-Side Apply 相比,它更具声明性,并跟踪字段管理,而不是最后应用的状态。

服务器端应用
通过更新资源的状态来声明配置管理,而无需删除并重新创建它。
字段管理
用户可以指定要更新的资源哪些字段,而不影响其他字段。
受管字段
Kubernetes 存储元数据,提供有关在 metadata 中的 managedFields 字段中管理对象的每个字段的元数据。
Conflicts
如果多个管理器尝试修改同一字段,则会出现冲突。申请者可以选择覆盖、恢复控制或共享管理。
合并策略
基于管理它们的参与者,server-ide Apply merges 字段。

流程

  1. 使用以下配置添加 MonitoringStack 资源:

    MonitoringStack 对象示例

    apiVersion: monitoring.rhobs/v1alpha1
    kind: MonitoringStack
    metadata:
      labels:
        coo: example
      name: sample-monitoring-stack
      namespace: coo-demo
    spec:
      logLevel: debug
      retention: 1d
      resourceSelector:
        matchLabels:
          app: demo
    Copy to Clipboard Toggle word wrap

  2. coo-demo 命名空间中生成了一个名为 sample-monitoring-stack 的 Prometheus 资源。运行以下命令,检索生成的 Prometheus 资源的受管字段:

    $ oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fields
    Copy to Clipboard Toggle word wrap

    输出示例

    managedFields:
    - apiVersion: monitoring.rhobs/v1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:labels:
            f:app.kubernetes.io/managed-by: {}
            f:app.kubernetes.io/name: {}
            f:app.kubernetes.io/part-of: {}
          f:ownerReferences:
            k:{"uid":"81da0d9a-61aa-4df3-affc-71015bcbde5a"}: {}
        f:spec:
          f:additionalScrapeConfigs: {}
          f:affinity:
            f:podAntiAffinity:
              f:requiredDuringSchedulingIgnoredDuringExecution: {}
          f:alerting:
            f:alertmanagers: {}
          f:arbitraryFSAccessThroughSMs: {}
          f:logLevel: {}
          f:podMetadata:
            f:labels:
              f:app.kubernetes.io/component: {}
              f:app.kubernetes.io/part-of: {}
          f:podMonitorSelector: {}
          f:replicas: {}
          f:resources:
            f:limits:
              f:cpu: {}
              f:memory: {}
            f:requests:
              f:cpu: {}
              f:memory: {}
          f:retention: {}
          f:ruleSelector: {}
          f:rules:
            f:alert: {}
          f:securityContext:
            f:fsGroup: {}
            f:runAsNonRoot: {}
            f:runAsUser: {}
          f:serviceAccountName: {}
          f:serviceMonitorSelector: {}
          f:thanos:
            f:baseImage: {}
            f:resources: {}
            f:version: {}
          f:tsdb: {}
      manager: observability-operator
      operation: Apply
    - apiVersion: monitoring.rhobs/v1
      fieldsType: FieldsV1
      fieldsV1:
        f:status:
          .: {}
          f:availableReplicas: {}
          f:conditions:
            .: {}
            k:{"type":"Available"}:
              .: {}
              f:lastTransitionTime: {}
              f:observedGeneration: {}
              f:status: {}
              f:type: {}
            k:{"type":"Reconciled"}:
              .: {}
              f:lastTransitionTime: {}
              f:observedGeneration: {}
              f:status: {}
              f:type: {}
          f:paused: {}
          f:replicas: {}
          f:shardStatuses:
            .: {}
            k:{"shardID":"0"}:
              .: {}
              f:availableReplicas: {}
              f:replicas: {}
              f:shardID: {}
              f:unavailableReplicas: {}
              f:updatedReplicas: {}
          f:unavailableReplicas: {}
          f:updatedReplicas: {}
      manager: PrometheusOperator
      operation: Update
      subresource: status
    Copy to Clipboard Toggle word wrap

  3. 检查 metadata.managedFields 值,并观察 metadataspec 中的一些字段是否由 MonitoringStack 资源管理。
  4. 修改不是由 MonitoringStack 资源控制的字段:

    1. 更改 spec.enforcedSampleLimit,这是 MonitoringStack 资源未设置的字段。创建 prom-spec-edited.yaml 文件:

      prom-spec-edited.yaml

      apiVersion: monitoring.rhobs/v1
      kind: Prometheus
      metadata:
        name: sample-monitoring-stack
        namespace: coo-demo
      spec:
        enforcedSampleLimit: 1000
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来应用 YAML:

      $ oc apply -f ./prom-spec-edited.yaml --server-side
      Copy to Clipboard Toggle word wrap
      注意

      您必须使用 --server-side 标志。

    3. 获取更改的 Prometheus 对象,并注意,managedFields 中有多个部分,其 spec.enforcedSampleLimit:

      $ oc get prometheus -n coo-demo
      Copy to Clipboard Toggle word wrap

      输出示例

      managedFields: 
      1
      
      - apiVersion: monitoring.rhobs/v1
        fieldsType: FieldsV1
        fieldsV1:
          f:metadata:
            f:labels:
              f:app.kubernetes.io/managed-by: {}
              f:app.kubernetes.io/name: {}
              f:app.kubernetes.io/part-of: {}
          f:spec:
            f:enforcedSampleLimit: {} 
      2
      
        manager: kubectl
        operation: Apply
      Copy to Clipboard Toggle word wrap

      1
      managedFields
      2
      spec.enforcedSampleLimit
  5. 修改由 MonitoringStack 资源管理的字段:

    1. 使用以下 YAML 配置更改 spec.LogLevel,它是由 MonitoringStack 资源管理的字段:

      # changing the logLevel from debug to info
      apiVersion: monitoring.rhobs/v1
      kind: Prometheus
      metadata:
        name: sample-monitoring-stack
        namespace: coo-demo
      spec:
        logLevel: info 
      1
      Copy to Clipboard Toggle word wrap
      1
      添加了 spec.logLevel
    2. 运行以下命令来应用 YAML:

      $ oc apply -f ./prom-spec-edited.yaml --server-side
      Copy to Clipboard Toggle word wrap

      输出示例

      error: Apply failed with 1 conflict: conflict with "observability-operator": .spec.logLevel
      Please review the fields above--they currently have other managers. Here
      are the ways you can resolve this warning:
      * If you intend to manage all of these fields, please re-run the apply
        command with the `--force-conflicts` flag.
      * If you do not intend to manage all of the fields, please edit your
        manifest to remove references to the fields that should keep their
        current managers.
      * You may co-own fields by updating your manifest to match the existing
        value; in this case, you'll become the manager if the other manager(s)
        stop managing the field (remove it from their configuration).
      See https://kubernetes.io/docs/reference/using-api/server-side-apply/#conflicts
      Copy to Clipboard Toggle word wrap

    3. 请注意,无法使用 Server-Side Apply 更改字段 spec.logLevel,因为它已经由 observability-operator 管理。
    4. 使用 --force-conflicts 标志来强制更改。

      $ oc apply -f ./prom-spec-edited.yaml --server-side --force-conflicts
      Copy to Clipboard Toggle word wrap

      输出示例

      prometheus.monitoring.rhobs/sample-monitoring-stack serverside-applied
      Copy to Clipboard Toggle word wrap

      with-force-conflicts 标志,字段可以被强制更改,但因为同一字段也由 MonitoringStack 资源管理,所以 Observability Operator 会检测到更改,并将其恢复到 MonitoringStack 资源设置的值。

      注意

      MonitoringStack 资源生成的一些 Prometheus 字段受到 MonitoringStack spec 小节中的字段的影响,如 logLevel。可以通过更改 MonitoringStack spec 来更改它们。

    5. 要更改 Prometheus 对象中的 logLevel,请应用以下 YAML 以更改 MonitoringStack 资源:

      apiVersion: monitoring.rhobs/v1alpha1
      kind: MonitoringStack
      metadata:
        name: sample-monitoring-stack
        labels:
          coo: example
      spec:
        logLevel: info
      Copy to Clipboard Toggle word wrap
    6. 要确认已进行了更改,请运行以下命令来查询日志级别:

      $ oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'
      Copy to Clipboard Toggle word wrap

      输出示例

      info
      Copy to Clipboard Toggle word wrap

注意
  1. 如果 Operator 的新版本生成了一个之前由参与者生成和控制的字段,则行动者设置的值将被覆盖。

    例如,您正管理一个由 MonitoringStack 资源生成的 enforcedSampleLimit 字段。如果升级了 Observability Operator,Operator 的新版本会为 enforcedSampleLimit 生成值,这会覆盖之前设置的值。

  2. MonitoringStack 资源生成的 Prometheus 对象可能包含一些由监控堆栈未明确设置的字段。此时会出现这些字段,因为它们有默认值。

法律通告

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat