2. OpenShift监控架构与核心组件

OpenShift的监控体系并非一组独立部署的软件，而是由Cluster Monitoring Operator（CMO）统一编排、以Prometheus为核心的声明式监控栈。理解这套架构的关键，是分清每个组件的职责边界，以及指标从产生到可视化的完整数据流。

核心组件职责

Cluster Monitoring Operator（CMO）是整套监控栈的“控制面”。它本身不采集指标，而是监听集群中的ConfigMap与自定义资源，将用户声明的监控配置（如保留时长、存储容量、告警接收器）翻译成Prometheus、Alertmanager、Thanos等组件的实际部署参数，并持续保证这些组件处于期望状态。当集群升级或配置变更时，CMO负责滚动更新各组件，避免人工逐个调整。

Prometheus是采集与规则计算引擎。它通过服务发现自动识别集群中的ServiceMonitor、PodMonitor对象，按配置的抓取间隔拉取指标，写入本地时序数据库，并按Recording Rule与Alerting Rule计算派生指标和告警条件。OpenShift默认部署两个Prometheus实例：一个运行在openshift-monitoring命名空间，负责集群核心监控；另一个运行在openshift-user-workload-monitoring命名空间，负责用户自定义监控，两者物理隔离。

Alertmanager接收Prometheus推送的告警，负责去重、分组、静默和路由。它不产生告警，只处理告警的“最后一公里”——决定哪些告警合并成一条通知、通过什么渠道发给谁、在维护窗口内是否抑制。OpenShift中Alertmanager同样按平台与用户工作负载分实例部署。

Thanos解决长期存储与全局查询问题。Prometheus本地存储受限于磁盘容量和保留周期，Thanos Sidecar将Prometheus的块数据上传至对象存储（如S3、ODF），Thanos Querier则聚合多个Prometheus实例与对象存储中的数据，对外提供统一的查询入口。这样既保留了Prometheus的实时能力，又获得了近乎无限的保留时长和跨集群查询能力。

Grafana是可视化层。OpenShift默认在openshift-monitoring中部署Grafana实例，预置了集群概览、etcd、API Server等仪表盘。用户也可以部署自己的Grafana，通过Thanos Querier或Prometheus作为数据源，构建面向业务的视图。

数据流与边界

指标从产生到可视化的路径可以概括为：目标端点暴露/metrics → Prometheus按ServiceMonitor/PodMonitor发现并抓取 → 写入本地TSDB → 按规则计算告警并推送Alertmanager → Thanos Sidecar上传块数据至对象存储 → Thanos Querier聚合查询 → Grafana展示。这条链路中，CMO不参与数据搬运，只负责让各环节的组件正确运行。

平台监控与用户自定义监控的边界是本节最需要明确的实践问题。默认情况下，openshift-monitoring中的Prometheus只抓取openshift-*、kube-*等平台命名空间下的指标，用户业务命名空间中的Pod即使暴露了/metrics端点，也不会被自动采集。要采集用户指标，必须显式启用user-workload-monitoring，并在用户命名空间中创建ServiceMonitor或PodMonitor对象。这种隔离设计既保护了平台监控的稳定性，也避免了用户指标的高基数问题拖垮核心监控。

默认监控栈的配置入口

集群管理员通过名为cluster-monitoring-config的ConfigMap调整平台监控行为，该ConfigMap必须位于openshift-monitoring命名空间。用户工作负载监控则通过user-workload-monitoring-config这个ConfigMap控制，位于openshift-user-workload-monitoring命名空间。两个ConfigMap的结构相似，但作用域完全独立。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      retention: 15d
      volumeClaimTemplate:
        spec:
          storageClassName: gp3
          resources:
            requests:
              storage: 100Gi
    alertmanagerMain:
      volumeClaimTemplate:
        spec:
          storageClassName: gp3
          resources:
            requests:
              storage: 10Gi
    thanosQuerier:
      enableRequestLogging: true

这段配置声明了平台Prometheus保留15天、使用100Gi的gp3存储，Alertmanager使用10Gi存储，并开启Thanos Querier的请求日志。CMO监听到该ConfigMap后，会重新生成Prometheus StatefulSet的PVC模板并触发滚动更新。需要注意的是，存储容量和保留时长需要匹配：如果每天新增指标约5GiB，15天保留至少需要75GiB，加上压缩和索引开销，100GiB是合理起点。

组件间的依赖与故障影响

理解依赖关系有助于排障。CMO不可用时，已运行的Prometheus和Alertmanager仍能继续工作，但配置变更无法生效；Prometheus不可用时，Grafana和Thanos Querier的实时查询会失败，但对象存储中的历史数据仍可查询；Alertmanager不可用时，告警仍会由Prometheus产生并进入Alertmanager的队列，但通知无法发出；Thanos Querier不可用时，Grafana的长期查询和跨集群查询会中断，但Prometheus本地查询不受影响。这种分层设计意味着单点故障不会导致整个可观测性体系完全失效，但每一层的降级都需要被监控和告警覆盖。