搜索

监控

download PDF
OpenShift Container Platform 4.15

在 OpenShift Container Platform 中配置和使用监控堆栈

Red Hat OpenShift Documentation Team

摘要

使用监控堆栈提供的指标和自定义警报来跟踪 OpenShift Container Platform 集群上运行的应用程序的健康状态和性能。

第 1 章 监控概述

1.1. 关于 OpenShift Container Platform 监控

OpenShift Container Platform 包括一个预配置、预安装和自我更新的监控堆栈,可为核心平台组件提供监控。您还可以选择为用户定义的项目启用监控

集群管理员可以使用支持的配置对监控堆栈进行配置。OpenShift Container Platform 提供了与监控相关的现成的最佳实践。

其中默认包括一组警报,可立即就集群问题通知管理员。OpenShift Container Platform Web 控制台中的默认仪表板包括集群指标的直观表示,以帮助您快速了解集群状态。使用 OpenShift Container Platform Web 控制台,您可以 查看和管理指标警报,并查看监控仪表板

在 OpenShift Container Platform Web 控制台的 Observe 部分中,您可以访问和管理监控功能,如 指标警报监控仪表板指标目标

安装 OpenShift Container Platform 后,集群管理员可以选择性地为用户定义的项目启用监控。通过使用此功能,集群管理员、开发人员和其他用户可以指定在其自己的项目中如何监控服务和 Pod。作为集群管理员,您可以查找常见问题的回答,如用户指标不可用,以及 Prometheus 对监控问题进行故障排除的磁盘空间高可用性。

1.2. 了解监控堆栈

OpenShift Container Platform 监控堆栈基于 Prometheus 开源项目及其更广的生态系统。监控堆栈包括以下组件:

  • 默认平台监控组件。在 OpenShift Container Platform 安装过程中,默认会在 openshift-monitoring 项目中安装一组平台监控组件。这为包括 Kubernetes 服务在内的核心集群组件提供了监控。默认监控堆栈还为集群启用远程健康状态监控。

    下图中的默认安装部分说明了这些组件。

  • 用于监控用户定义项目的组件。在选择性地为用户定义的项目启用监控后,会在 openshift-user-workload-monitoring 项目中安装其他监控组件。这为用户定义的项目提供了监控。下图中的用户部分说明了这些组件。

OpenShift Container Platform monitoring architecture

1.2.1. 默认监控组件

默认情况下,OpenShift Container Platform 4.15 监控堆栈包括以下组件:

表 1.1. 默认监控堆栈组件
组件描述

Cluster Monitoring Operator

Cluster Monitoring Operator (CMO) 是监控堆栈的核心组件。它部署、管理和自动更新 Prometheus 和 Alertmanager 实例、Thanos Querier、Teleme Client 和 metrics 目标。CMO 由 Cluster Version Operator (CVO) 部署。

Prometheus Operator

openshift-monitoring 项目中的 Prometheus Operator (PO) 负责创建、配置和管理平台 Prometheus 实例和 Alertmanager 实例。它还会根据 Kubernetes 标签查询来自动生成监控目标配置。

Prometheus

Prometheus 是 OpenShift Container Platform 监控堆栈所依据的监控系统。Prometheus 是一个时间序列数据库和用于指标的规则评估引擎。Prometheus 将警报发送到 Alertmanager 进行处理。

Prometheus Adapter

Prometheus Adapter(上图中的 PA)负责转换 Kubernetes 节点和 Pod 查询以便在 Prometheus 中使用。转换的资源指标包括 CPU 和内存使用率指标。Prometheus Adapter 会公开用于 Pod 横向自动扩展的集群资源指标 API。Prometheus Adapter 也用于 oc adm top nodesoc adm top pods 命令。

指标服务器(技术预览)

如果启用,指标服务器组件会收集资源指标,并在 metrics.k8s.io Metrics API 服务中公开这些资源指标,以便其他工具和 API 使用它们,从而释放核心平台 Prometheus 堆栈来处理此功能。

如果您使用 TechPreviewNoUpgrade 选项配置 FeatureGate 自定义资源,则 Metrics Server 组件的技术预览会自动安装,而不是 Prometheus Adapter。有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

Alertmanager

Alertmanager 服务处理从 Prometheus 接收的警报。Alertmanager 还负责将警报发送到外部通知系统。

kube-state-metrics 代理

kube-state-metrics 导出器代理(上图中的 KSM)将 Kubernetes 对象转换为 Prometheus 可使用的指标。

monitoring-plugin

monitoring-plugin 动态插件组件在 OpenShift Container Platform Web 控制台的 Observe 部分中部署监控页面。您可以使用 Cluster Monitoring Operator (CMO) 配置映射设置来管理 web 控制台页面的 monitoring-plugin 资源。

openshift-state-metrics 代理

openshift-state-metrics 导出器(上图中的 OSM)通过添加了对特定 OpenShift Container Platform 资源的指标数据扩展了 kube-state-metrics。

node-exporter 代理

node-exporter 代理(上图中的NE)会收集有关集群中每个节点的指标。node-exporter 代理部署在每个节点上。

Thanos querier

Thanos Querier 将 OpenShift Container Platform 核心指标和用于用户定义项目的指标聚合在单个多租户接口下,并选择性地进行重复数据删除。

Telemeter Client

Telemeter Client 将数据的子部分从平台 Prometheus 实例发送到红帽,以便为集群提供远程健康状态监控。

监控堆栈中的所有组件都由堆栈监控,并在 OpenShift Container Platform 更新时自动更新。

注意

监控堆栈的所有组件都使用集群管理员集中配置的 TLS 安全配置集设置。如果您配置了使用 TLS 安全设置的监控堆栈组件,组件使用全局 OpenShift Container Platform apiservers.config.openshift.io/cluster 资源中的 tlsSecurityProfile 字段中已存在的 TLS 安全配置集设置。

1.2.2. 默认监控目标

除了堆栈本身的组件外,默认的监控堆栈还会监控额外的平台组件。

以下是监控目标的示例:

  • CoreDNS
  • etcd
  • HAProxy
  • 镜像 registry
  • Kubelets
  • Kubernetes API 服务器
  • Kubernetes 控制器管理器
  • Kubernetes 调度程序
  • OpenShift API 服务器
  • OpenShift Controller Manager
  • Operator Lifecycle Manager (OLM)
注意
  • 具体目标列表可能会因集群功能和安装的组件而异。
  • 每个 OpenShift Container Platform 组件负责自己的监控配置。对于 OpenShift Container Platform 组件监控 的问题,请针对该组件创建一个 Jira 问题,而不是针对常规的监控组件。

其他 OpenShift Container Platform 框架组件也可能会公开指标。如需详细信息,请参阅相应的文档。

1.2.3. 用于监控用户定义的项目的组件

OpenShift Container Platform 包括对监控堆栈的可选增强,供您用于监控用户定义的项目中的服务和 Pod。此功能包括以下组件:

表 1.2. 用于监控用户定义的项目的组件
组件描述

Prometheus Operator

openshift-user-workload-monitoring 项目中的 Prometheus Operator (PO) 在同一项目中创建、配置和管理 Prometheus 和 Thanos Ruler 实例。

Prometheus

Prometheus 是为用户定义的项目提供监控的监控系统。Prometheus 将警报发送到 Alertmanager 进行处理。

Thanos Ruler

Thanos Ruler 是 Prometheus 的一个规则评估引擎,作为一个独立的进程来部署。在 OpenShift Container Platform 中,Thanos Ruler 为监控用户定义的项目提供规则和警报评估。

Alertmanager

Alertmanager 服务处理从 Prometheus 和 Thanos Ruler 接收的警报。Alertmanager 还负责将用户定义的警报发送到外部通知系统。部署该服务是可选的。

注意

在为用户定义的项目启用监控后,会部署上表中的组件。

所有这些组件都由堆栈监控,并在 OpenShift Container Platform 更新时自动更新。

1.2.4. 用户定义的项目的监控目标

为用户定义的项目启用监控后,您可以监控:

  • 通过用户定义的项目中的服务端点提供的指标。
  • 在用户定义的项目中运行的 Pod。

1.3. OpenShift Container Platform 监控的常见术语表

此术语表定义了 OpenShift Container Platform 架构中使用的常见术语。

Alertmanager
Alertmanager 处理从 Prometheus 接收的警报。Alertmanager 还负责将警报发送到外部通知系统。
警报规则
警报规则包含一组概述集群中特定状态的条件。当这些条件满足时会触发警报。可为警报规则分配一个严重性来定义警报的路由方式。
Cluster Monitoring Operator
Cluster Monitoring Operator (CMO) 是监控堆栈的核心组件。它部署和管理 Prometheus 实例,如 Thanos Querier、Telemeter Client 和 metrics 目标,以确保它们保持最新状态。CMO 由 Cluster Version Operator (CVO) 部署。
Cluster Version Operator
Cluster Version Operator (CVO) 管理集群 Operator 的生命周期,其中许多默认安装在 OpenShift Container Platform 中。
配置映射
配置映射提供将配置数据注入 pod 的方法。您可以在类型为 ConfigMap 的卷中引用存储在配置映射中的数据。在 pod 中运行的应用程序可以使用这个数据。
Container
容器是一个轻量级的可执行镜像,包括软件及其所有依赖项。容器将虚拟化操作系统。因此,您可以在数据中心、公共或私有云以及开发人员的笔记本电脑中运行容器。
自定义资源 (CR)
CR 是 Kubernetes API 的扩展。您可以创建自定义资源。
etcd
etcd 是 OpenShift Container Platform 的键值存储,它存储所有资源对象的状态。
Fluentd

Fluentd 是一个日志收集器,它驻留在每个 OpenShift Container Platform 节点上。它收集应用程序、基础架构和审计日志并将其转发到不同的输出。

注意

Fluentd 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。作为 Fluentd 的替代选择,您可以使用 Vector。

Kubelets
在节点上运行并读取容器清单。确保定义的容器已启动且正在运行。
Kubernetes API 服务器
Kubernetes API 服务器验证并配置 API 对象的数据。
Kubernetes 控制器管理器
Kubernetes 控制器管理器管理集群的状态。
Kubernetes 调度程序
Kubernetes 调度程序将 pod 分配给节点。
labels
标签是可用于组织和选择对象子集(如 pod)的键值对。
node
OpenShift Container Platform 集群中的 worker 机器。节点是虚拟机 (VM) 或物理计算机。
Operator
在 OpenShift Container Platform 集群中打包、部署和管理 Kubernetes 应用程序的首选方法。Operator 将人类操作知识编码到一个软件程序中,易于打包并与客户共享。
Operator Lifecycle Manager (OLM)
OLM 可帮助您安装、更新和管理 Kubernetes 原生应用程序的生命周期。OLM 是一个开源工具包,用于以有效、自动化且可扩展的方式管理 Operator。
持久性存储
即便在设备关闭后也存储数据。Kubernetes 使用持久性卷来存储应用程序数据。
持久性卷声明 (PVC)
您可以使用 PVC 将 PersistentVolume 挂载到 Pod 中。您可以在不了解云环境的详情的情况下访问存储。
pod
pod 是 Kubernetes 中的最小逻辑单元。pod 由一个或多个容器组成,可在 worker 节点上运行。
Prometheus
Prometheus 是 OpenShift Container Platform 监控堆栈所依据的监控系统。Prometheus 是一个时间序列数据库和用于指标的规则评估引擎。Prometheus 将警报发送到 Alertmanager 进行处理。
Prometheus adapter
Prometheus Adapter 会转换 Kubernetes 节点和 pod 查询以便在 Prometheus 中使用。转换的资源指标包括 CPU 和内存使用率。Prometheus Adapter 会公开用于 Pod 横向自动扩展的集群资源指标 API。
Prometheus Operator
openshift-monitoring 项目中的 Prometheus Operator (PO) 负责创建、配置和管理平台 Prometheus 和 Alertmanager 实例。它还会根据 Kubernetes 标签查询来自动生成监控目标配置。
静默
可对警报应用静默,以防止在警报条件满足时发送通知。在您着手处理根本问题的同时,您可在初始通知后将警报静音。
storage
OpenShift Container Platform 支持许多类型的存储,包括内部存储和云供应商。您可以在 OpenShift Container Platform 集群中管理持久性和非持久性数据的容器存储。
Thanos Ruler
Thanos Ruler 是 Prometheus 的一个规则评估引擎,作为一个独立的进程来部署。在 OpenShift Container Platform 中,Thanos Ruler 为监控用户定义的项目提供规则和警报评估。
Vector
Vector 是一个日志收集器,它部署到每个 OpenShift Container Platform 节点。它从每个节点收集日志数据,转换数据并将其转发到配置的输出。
Web 控制台
用于管理 OpenShift Container Platform 的用户界面(UI)。

1.4. 其他资源

1.5. 后续步骤

第 2 章 配置监控堆栈

在安装前,OpenShift Container Platform 安装程序只提供少量的配置选项。大多数 OpenShift Container Platform 框架组件(包括集群监控堆栈)都在安装后进行配置。

本节介绍支持的配置,演示如何配置监控堆栈,并且展示几个常见的配置情景。

重要

并非所有监控堆栈的配置参数都会被公开。只有在 Cluster Monitoring Operator 的 Config map 引用中列出的参数和字段才支持进行配置。

2.1. 先决条件

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-* 项目中创建额外的 ServiceMonitorPodMonitorPrometheusRule 对象。
  • 修改 openshift-monitoringopenshift-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.io/cluster-monitoring: "true" 标签的命名空间中。
  • openshift.io/cluster-monitoring: "true" 标签添加到命名空间。该标签只适用于带有 OpenShift Container Platform 核心组件和红帽认证的组件的命名空间。
  • 在 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 内置的可靠性功能,并妨碍接收更新。在删除所有覆盖后,必须可以重现报告的问题方可获得支持。

2.2.3. 监控组件的支持版本列表

以下列表包含有关 OpenShift Container Platform 4.12 及更新的版本的监控组件版本的信息:

表 2.1. OpenShift Container Platform 和组件版本
OpenShift Container PlatformPrometheus OperatorPrometheusPrometheus Adapter指标服务器(技术预览)Alertmanagerkube-state-metrics 代理monitoring-pluginnode-exporter 代理Thanos

4.15

0.70.0

2.48.0

0.11.2

0.6.4

0.26.0

2.10.1

1.0.0

1.7.0

0.32.5

4.14

0.67.1

2.46.0

0.10.0

N/A

0.25.0

2.9.2

1.0.0

1.6.1

0.30.2

4.13

0.63.0

2.42.0

0.10.0

N/A

0.25.0

2.8.1

N/A

1.5.0

0.30.2

4.12

0.60.1

2.39.1

0.10.0

N/A

0.24.0

2.6.0

N/A

1.4.0

0.28.1

注意

openshift-state-metrics 代理和 Telemeter Client 是特定于 OpenShift 的组件。因此,它们的版本与 OpenShift Container Platform 的版本对应。

2.3. 准备配置监控堆栈

您可以通过创建和更新监控配置映射来配置监控堆栈。这些配置映射配置 Cluster Monitoring Operator (CMO),后者配置监控堆栈的组件。

2.3.1. 创建集群监控配置映射

您可以通过在 openshift-monitoring 项目中创建 cluster-monitoring-config ConfigMap 对象来配置 OpenShift Container Platform 核心监控组件。Cluster Monitoring Operator (CMO) 然后配置监控堆栈的核心组件。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 检查 cluster-monitoring-config ConfigMap 对象是否存在:

    $ oc -n openshift-monitoring get configmap cluster-monitoring-config
  2. 如果 ConfigMap 对象不存在:

    1. 创建以下 YAML 清单。在本例中,该文件名为 cluster-monitoring-config.yaml

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
    2. 应用配置以创建 ConfigMap 对象:

      $ oc apply -f cluster-monitoring-config.yaml

2.3.2. 创建用户定义的工作负载监控配置映射

您可以使用 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config ConfigMap 对象配置用户工作负载监控组件。然后,Cluster Monitoring Operator (CMO) 配置用于监控用户定义的项目的组件。

注意
  • 如果您为用户定义的项目启用监控,则默认创建 user-workload-monitoring-config ConfigMap 对象。
  • 当您将更改保存到 user-workload-monitoring-config ConfigMap 对象时,可能会重新部署 openshift-user-workload-monitoring 项目中的部分或全部 Pod。有时重新部署这些组件需要花费一段时间。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 检查 user-workload-monitoring-config ConfigMap 对象是否存在:

    $ oc -n openshift-user-workload-monitoring get configmap user-workload-monitoring-config
  2. 如果 user-workload-monitoring-config ConfigMap 对象不存在:

    1. 创建以下 YAML 清单。在本例中,该文件名为 user-workload-monitoring-config.yaml

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
    2. 应用配置以创建 ConfigMap 对象:

      $ oc apply -f user-workload-monitoring-config.yaml
      注意

      除非集群管理员为用户定义的项目启用了监控,否则应用到 user-workload-monitoring-config ConfigMap 的配置不会被激活。

2.4. 配置监控堆栈

在 OpenShift Container Platform 4.15 中,您可以使用 cluster-monitoring-configuser-workload-monitoring-config ConfigMap 配置监控堆栈。配置配置映射配置 Cluster Monitoring Operator(CMO),CMO 会配置堆栈的组件。

先决条件

  • 如果要配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 ConfigMap 对象。

    • 要配置 OpenShift Container Platform 核心监控组件

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. 将您的配置以键值对 <component_name>: <component_configuration> 的形式添加到 data/config.yaml 下:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>:
              <configuration_for_the_component>

        相应地替换 <component><configuration_for_the_component>

        以下示例 ConfigMap 对象为 Prometheus 配置持久性卷声明(PVC)。这与只监控 OpenShift Container Platform 核心组件的 Prometheus 实例相关:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: fast
                  volumeMode: Filesystem
                  resources:
                    requests:
                      storage: 40Gi
        1
        定义 Prometheus 组件,后面几行则定义其配置。
    • 要配置用于监控用户定义的项目的组件

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. 将您的配置以键值对 <component_name>: <component_configuration> 的形式添加到 data/config.yaml 下:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              <configuration_for_the_component>

        相应地替换 <component><configuration_for_the_component>

        以下示例 ConfigMap 对象为 Prometheus 配置数据保留周期和最低容器资源请求。这与仅监控用户定义的项目的 Prometheus 实例相关:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus: 1
              retention: 24h 2
              resources:
                requests:
                  cpu: 200m 3
                  memory: 2Gi 4
        1
        定义 Prometheus 组件,后面几行则定义其配置。
        2
        为监控用户定义的项目的 Prometheus 实例配置 24 小时的数据保留周期。
        3
        为 Prometheus 容器定义最低 200 毫秒的资源请求。
        4
        为 Prometheus 容器定义最低 2 GiB 内存的 Pod 资源请求。
        注意

        Prometheus 配置映射组件在 cluster-monitoring-configConfigMap 对象中被称为 prometheusK8s,在 user-workload-monitoring-config ConfigMap 对象中称为 prometheus

  2. 保存文件以将更改应用到 ConfigMap 对象。

    警告

    ConfigMap 对象的不同配置更改会导致不同的结果:

    • Pod 不会重新部署。因此,没有服务中断。
    • 受影响的 pod 被重新部署:

      • 对于单节点集群,这会导致临时服务中断。
      • 对于多节点集群,因为高可用性,受影响的 pod 会逐渐推出,监控堆栈仍然可用。
      • 无论高可用性如何,配置和重新定义持久性卷的大小始终会导致服务中断。

    每个需要更改配置映射中的步骤都包括其预期的结果。

其他资源

2.5. 可配置的监控组件

下表显示了您可以配置的监控组件,以及 cluster-monitoring-configuser-workload-monitoring-config ConfigMap 中用来指定这些组件的键。

表 2.2. 可配置的监控组件
组件cluster-monitoring-config 配置映射键user-workload-monitoring-config 配置映射键

Prometheus Operator

prometheusOperator

prometheusOperator

Prometheus

prometheusK8s

prometheus

Alertmanager

alertmanagerMain

alertmanager

kube-state-metrics

kubeStateMetrics

 

monitoring-plugin

monitoringPlugin

 

openshift-state-metrics

openshiftStateMetrics

 

Telemeter Client

telemeterClient

 

Prometheus Adapter

k8sPrometheusAdapter

 

Thanos querier

thanosQuerier

 

Thanos Ruler

 

thanosRuler

注意

Prometheus 键在 cluster-monitoring-config ConfigMap 对象中称为 prometheusK8s,在 user-workload-monitoring-config ConfigMap 对象中称为 prometheus

2.6. 使用节点选择器移动监控组件

通过将 nodeSelector 约束与标记的节点搭配使用,您可以将任何监控堆栈组件移到特定的节点上。通过这样做,您可以控制集群中监控组件的放置和分发。

通过控制监控组件的放置和分发,您可以根据特定要求或策略优化系统资源使用、提高性能和隔离工作负载。

2.6.1. 节点选择器与其他约束一起使用

如果使用节点选择器约束移动监控组件,请注意集群可能存在其他限制来控制 pod 调度:

  • 拓扑分布约束可能处于放置状态来控制 pod 放置。
  • Prometheus、Thanos Querier、Alertmanager 和其他监控组件会放置硬反关联性规则,以确保这些组件的多个 pod 始终分散到不同的节点上,因此始终具有高可用性。

将 pod 调度到节点时,pod 调度程序会在决定 pod 放置时尝试满足所有现有的限制。也就是说,当 pod 调度程序决定将哪些 pod 放置到哪些节点上时,所有约束都会编译。

因此,如果您配置节点选择器约束,但无法满足现有的约束,pod 调度程序无法与所有约束匹配,也不会调度 pod 放置到节点上。

为保持监控组件的弹性和高可用性,请确保有足够的节点可用,并在配置节点选择器约束以移动组件时匹配所有约束。

2.6.2. 将监控组件移到其他节点

要指定运行监控堆栈组件的集群中的节点,请在组件的 ConfigMap 对象中配置 nodeSelector 约束,以匹配分配给节点的标签。

注意

您不能将节点选择器约束直接添加到现有调度的 pod 中。

先决条件

  • 如果要配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 如果您还没有这样做,请在要运行监控组件的节点中添加标签:

    $ oc label nodes <node-name> <node-label>
  2. 编辑 ConfigMap 对象:

    • 要移动用于监控 OpenShift Container Platform 核心项目的组件

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml 下为组件指定 nodeSelector 约束的节点标签:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              nodeSelector:
                <node-label-1> 2
                <node-label-2> 3
                <...>
        1
        <component> 替换为适当的监控堆栈组件名称。
        2
        <node-label-1> 替换为添加到节点的标签。
        3
        可选:指定附加标签。如果您指定了额外的标签,则组件的 pod 仅调度到包含所有指定标签的节点上。
        注意

        如果在配置 nodeSelector 约束后监控组件仍然处于 Pending 状态,请检查 Pod 事件中与污点和容限相关的错误。

    • 要移动用于监控用户定义的项目的组件

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml 下为组件指定 nodeSelector 约束的节点标签:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              nodeSelector:
                <node-label-1> 2
                <node-label-2> 3
                <...>
        1
        <component> 替换为适当的监控堆栈组件名称。
        2
        <node-label-1> 替换为添加到节点的标签。
        3
        可选:指定附加标签。如果您指定了额外的标签,则组件的 pod 仅调度到包含所有指定标签的节点上。
        注意

        如果在配置 nodeSelector 约束后监控组件仍然处于 Pending 状态,请检查 Pod 事件中与污点和容限相关的错误。

  3. 保存文件以使改变生效。新配置中指定的组件会自动移到新节点上,受新配置影响的 pod 会被重新部署。

其他资源

2.7. 为监控组件分配容忍(tolerations)

您可以为任何监控堆栈组件分配容忍,以便将其移到污点。

先决条件

  • 如果要配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 ConfigMap 对象:

    • 要将容限分配给监控 OpenShift Container Platform 核心项目的组件

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. 为组件指定 tolerations

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>:
              tolerations:
                <toleration_specification>

        相应地替换 <component><toleration_specification>

        例如,oc adm taint nodes node1 key1=value1:NoSchedule 会将一个键为 key1 且值为 value1 的污点添加到 node1。这会防止监控组件在 node1 上部署 Pod,除非为该污点配置了容限。以下示例将 alertmanagerMain 组件配置为容许示例污点:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              tolerations:
              - key: "key1"
                operator: "Equal"
                value: "value1"
                effect: "NoSchedule"
    • 要将容限分配给监控用户定义的项目的组件

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. 为组件指定 tolerations

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              tolerations:
                <toleration_specification>

        相应地替换 <component><toleration_specification>

        例如,oc adm taint nodes node1 key1=value1:NoSchedule 会将一个键为 key1 且值为 value1 的污点添加到 node1。这会防止监控组件在 node1 上部署 Pod,除非为该污点配置了容限。以下示例将 thanosRuler 组件配置为容许示例污点:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              tolerations:
              - key: "key1"
                operator: "Equal"
                value: "value1"
                effect: "NoSchedule"
  2. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

其他资源

2.8. 为指标提取设置正文大小限制

默认情况下,针对从提取的指标目标返回的数据的未压缩正文大小没有限制。您可以设置正文大小限制,以帮助避免在提取目标返回包含大量数据时 Prometheus 消耗大量内存的情况。另外,通过设置正文大小限制,您可以降低恶意目标在 Prometheus 和整个集群中可能对这个影响。

enforcedBodySizeLimit 设置了一个值后,当至少有一个 Prometheus scrape 目标回复大于配置的值时,PrometheusScrapeBodySizeLimitHit 会触发警报。

注意

如果从目标中提取的指标数据有一个不压缩的正文大小超过配置的大小限制,则提取会失败。然后,Prometheus 会认为这个目标为停机状态,并将其 up 指标值设置为 0, 它将触发一个 TargetDown 警报。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-monitoring 命名空间中的 cluster-monitoring-config ConfigMap 对象:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. enforcedBodySizeLimit 的值添加到 data/config.yaml/prometheusK8s 中,以限制每个目标提取可接受的正文大小:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |-
        prometheusK8s:
          enforcedBodySizeLimit: 40MB 1
    1
    指定提取指标目标的最大正文大小。这个 enforceBodySizeLimit 示例将每个目标提取的未压缩大小限制为 40MB。有效数字值使用 Prometheus 数据大小格式:B (bytes), KB (kilobytes), MB (megabytes), GB (gigabytes), TB (terabytes), PB (petabytes), and EB (exabytes)。默认值为 0,代表没有指定限制。您还可以将值设为 automatic,以根据集群容量自动计算限制。
  3. 保存文件以使改变生效。新的配置会被自动应用。

2.9. 管理监控组件的 CPU 和内存资源

您可以通过为这些组件的资源限值和请求指定值来确保运行监控组件的容器具有足够的 CPU 和内存资源。

您可以为 openshift-monitoring 命名空间中的核心平台监控组件配置这些限制和请求,以及监控 openshift-user-workload-monitoring 命名空间中的用户定义的项目的组件。

2.9.1. 关于为监控组件指定限制和请求

您可以为核心平台监控组件以及监控用户定义的项目的组件配置资源限值和请求设置,包括以下组件:

  • Alertmanager (用于核心平台监控和用户定义的项目的)
  • kube-state-metrics
  • monitoring-plugin
  • node-exporter
  • openshift-state-metrics
  • Prometheus (用于核心平台监控和用户定义的项目的)
  • Prometheus Adapter
  • Prometheus Operator 及其准入 Webhook 服务
  • Telemeter Client
  • Thanos querier
  • Thanos Ruler

通过定义资源限值,您可以限制容器的资源使用情况,这会阻止容器超过 CPU 和内存资源指定的最大值。

通过定义资源请求,您可以指定容器只能调度到具有足够 CPU 和内存资源的节点,以匹配请求的资源。

2.9.2. 为监控组件指定限制和请求

要配置 CPU 和内存资源,在监控组件所在的命名空间的适当 ConfigMap 对象中为资源限值和请求指定值:

  • 用于核心平台监控的 openshift-monitoring 命名空间中的 cluster-monitoring-config 配置映射
  • openshift-user-workload-monitoring 命名空间中的 user-workload-monitoring-config 配置映射用于监控用户定义的项目的组件

先决条件

  • 如果要配置核心平台监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建了名为 cluster-monitoring-configConfigMap 对象。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 要配置核心平台监控组件,请编辑 openshift-monitoring 命名空间中的 cluster-monitoring-config 配置映射对象:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. 添加值,以定义您要配置的每个核心平台监控组件的资源限值和请求。

    重要

    确保为限制设置的值始终高于为请求设置的值。否则,会出现错误,容器将不会运行。

    Example

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        prometheusK8s:
          resources:
            limits:
              cpu: 500m
              memory: 3Gi
            requests:
              cpu: 200m
              memory: 500Mi
        prometheusOperator:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        k8sPrometheusAdapter:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        kubeStateMetrics:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        telemeterClient:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        openshiftStateMetrics:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        thanosQuerier:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        nodeExporter:
          resources:
            limits:
              cpu: 50m
              memory: 150Mi
            requests:
              cpu: 20m
              memory: 50Mi
        monitoringPlugin:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        prometheusOperatorAdmissionWebhook:
          resources:
            limits:
              cpu: 50m
              memory: 100Mi
            requests:
              cpu: 20m
              memory: 50Mi

  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

2.10. 配置持久性存储

使用持久性存储运行集群监控以获取以下优点:

  • 通过将指标和警报数据存储在持久性卷(PV)中来保护您的指标和警报数据。因此,它们可以在 pod 重启或重新创建后保留。
  • 避免获取重复的通知,并在 Alertmanager pod 重启时丢失警报静默。

在生产环境中,强烈建议配置持久性存储。

2.10.1. 持久性存储的先决条件

  • 分配充足的专用持久性存储,以确保磁盘不会被填满。
  • 在配置持久性卷时,使用 Filesystem 作为 volumeMode 参数的存储类型值。

    重要
    • 不要使用原始块卷,它由 PersistentVolume 资源中的 volumeMode: Block 描述。Prometheus 无法使用原始块卷。
    • Prometheus 不支持兼容 POSIX 的文件系统。例如,一些 NFS 文件系统实现不兼容 POSIX。如果要使用 NFS 文件系统进行存储,请验证与其 NFS 实现完全兼容 POSIX 的供应商。

2.10.2. 配置持久性卷声明

要将持久性卷 (PV) 用于监控组件,您必须配置持久性卷声明 (PVC)。

先决条件

  • 如果要配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 ConfigMap 对象:

    • 为监控 OpenShift Container Platform 核心项目的组件配置 PVC

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. 将组件的 PVC 配置添加到 data/config.yaml 下:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class> 2
                  resources:
                    requests:
                      storage: <amount_of_storage> 3
        1
        指定您要为其配置 PVC 的核心监控组件。
        2
        指定现有存储类。如果没有指定存储类,则使用默认存储类。
        3
        指定所需的存储量。

        如需有关如何指定 volumeClaimTemplate 的信息,请参阅 Kubernetes 文档中与 PersistentVolumeClaim 相关的内容

        以下示例配置了一个 PVC,它声明用于监控 OpenShift Container Platform 核心组件的 Prometheus 实例的持久性存储:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              volumeClaimTemplate:
                spec:
                  storageClassName: my-storage-class
                  resources:
                    requests:
                      storage: 40Gi
    • 要为监控用户定义的项目的组件配置 PVC

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. 将组件的 PVC 配置添加到 data/config.yaml 下:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class> 2
                  resources:
                    requests:
                      storage: <amount_of_storage> 3
        1
        指定您要为其配置 PVC 的用户定义监控的组件。
        2
        指定现有存储类。如果没有指定存储类,则使用默认存储类。
        3
        指定所需的存储量。

        如需有关如何指定 volumeClaimTemplate 的信息,请参阅 Kubernetes 文档中与 PersistentVolumeClaim 相关的内容

        以下示例配置了一个 PVC 来声明用于 Thanos Ruler 的持久性存储:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              volumeClaimTemplate:
                spec:
                  storageClassName: my-storage-class
                  resources:
                    requests:
                      storage: 10Gi
        注意

        thanosRuler 组件的存储要求取决于要评估的规则数量以及每个规则生成的样本数量。

  2. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署并应用新的存储配置。

    警告

    当您使用 PVC 配置更新配置映射时,受影响的 StatefulSet 对象会被重新创建,从而导致临时服务中断。

2.10.3. 重新定义持久性卷大小

您可以为监控组件(如 Prometheus、Thanos Ruler 或 Alertmanager)重新定义持久性卷 (PV) 大小。您需要手动扩展持久性卷声明 (PVC),然后更新配置组件的配置映射。

重要

您只能扩展 PVC 的大小。无法缩小存储大小。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 如果要配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
    • 至少有一个 PVC 用于 OpenShift Container Platform 核心监控组件。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
    • 至少有一个 PVC 用于监控用户定义的项目的组件。

流程

  1. 使用更新的存储请求手动扩展 PVC。如需更多信息,请参阅 扩展持久性卷 中的"使用文件系统扩展持久性卷声明 (PVC) "。
  2. 编辑 ConfigMap 对象:

    • 如果要配置 OpenShift Container Platform 核心监控组件

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml 下为组件添加新存储大小:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  resources:
                    requests:
                      storage: <amount_of_storage> 2
        1
        要更改存储大小的组件。
        2
        指定存储卷的新大小。它必须大于上一个值。

        以下示例将监控 OpenShift Container Platform 核心组件的 Prometheus 实例的新 PVC 请求设置为 100GB:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              volumeClaimTemplate:
                spec:
                  resources:
                    requests:
                      storage: 100Gi
    • 如果您要配置用于监控用户定义的项目的组件

      注意

      您可以调整 Thanos Ruler 的大小,以及监控用户定义的项目的 Alertmanager 和 Prometheus 实例。

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml 下更新监控组件的 PVC 配置:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  resources:
                    requests:
                      storage: <amount_of_storage> 2
        1
        要更改存储大小的组件。
        2
        指定存储卷的新大小。它必须大于上一个值。

        以下示例将 Thanos Ruler 的新 PVC 请求设置为 20GB:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              volumeClaimTemplate:
                spec:
                  resources:
                    requests:
                      storage: 20Gi
        注意

        thanosRuler 组件的存储要求取决于要评估的规则数量以及每个规则生成的样本数量。

  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

    警告

    当您使用新存储大小更新配置映射时,受影响的 StatefulSet 对象会被重新创建,从而导致临时服务中断。

2.10.4. 修改 Prometheus 指标数据的保留时间和大小

默认情况下,Prometheus 会在以下持续时间内保留指标数据:

  • 核心平台监控 :15 天
  • 监控用户定义的项目: 24 小时

您可以修改 Prometheus 的保留时间,以更改删除数据的时间。您还可以设置保留指标数据使用的最大磁盘空间量。如果数据达到这个大小限制,Prometheus 会首先删除最旧的数据,直到使用的磁盘空间重新低于限制。

请注意这些数据保留设置的行为:

  • 基于大小的保留策略适用于 /prometheus 目录中的所有数据块目录,包括持久性块、写入级日志(WAL)数据和 mmapped 块。
  • /wal/head_chunks 目录中的数据计入保留大小限制,但 Prometheus 永远不会根据基于大小或基于时间的保留策略从这些目录中清除数据。因此,如果您设置了保留大小限制,它小于为 /wal/head_chunks 目录设置的最大容量,则表示您将系统配置为不保留 /prometheus 数据目录中的任何数据块。
  • 只有在 Prometheus 切断新的数据块时,才会应用基于大小的保留策略,即在 WAL 最多包含三小时数据后每两小时进行。
  • 如果没有为 retentionretentionSize 明确定义值,则保留时间默认为 15 天,用于核心平台监控,为用户定义的项目监控 24 小时。不设置保留大小。
  • 如果 retentionretentionSize 都定义了值,则会应用这两个值。如果任何数据块超过定义的保留时间或定义的大小限制,Prometheus 会清除这些数据块。
  • 如果您为 retentionSize 定义了值,且没有定义 retention,则只应用 retentionSize 值。
  • 如果您没有为 retentionSize 定义值,且只为 retention 定义了值,则只应用 retention 值。
  • 如果将 retentionSizeretention 值设置为 0,则应用默认的设置。默认设置将核心平台监控的保留时间设置为 15 天,用户定义的项目监控为 24 小时。默认情况下,不会设置保留大小。
注意

数据压缩每两小时进行一次。因此,持久性卷 (PV) 可能会在压缩前已被填满,可能会超过 retentionSize 限制。在这种情况下,KubePersistentVolumeFillingUp 警报会触发,直到 PV 上的空间低于 retentionSize 限制。

先决条件

  • 如果要配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 ConfigMap 对象:

    • 要修改用于监控 OpenShift Container Platform 核心项目的 Prometheus 实例的保留时间和大小

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml 下添加保留时间和大小配置:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              retention: <time_specification> 1
              retentionSize: <size_specification> 2
        1
        保留时间:数字直接加上 ms (毫秒)、s (秒)、m (分钟)、h (小时)、d (天)、w (周)或 y (年)。您还可以组合指定时间值,如 1h30m15s
        2
        保留大小:数字直接加上 B (bytes), KB (kilobytes), MB (megabytes), GB (gigabytes), TB (terabytes), PB (petabytes), 和 EB (exabytes).。

        以下示例为监控 OpenShift Container Platform 核心组件的 Prometheus 实例将保留时间设置为 24 小时,保留大小设为 10GB:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              retention: 24h
              retentionSize: 10GB
    • 要修改监控用户定义的项目的 Prometheus 实例的保留时间和大小

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml 下添加保留时间和大小配置:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              retention: <time_specification> 1
              retentionSize: <size_specification> 2
        1
        保留时间:数字直接加上 ms (毫秒)、s (秒)、m (分钟)、h (小时)、d (天)、w (周)或 y (年)。您还可以组合指定时间值,如 1h30m15s
        2
        保留大小:数字直接加上 B (bytes), KB (kilobytes), MB (megabytes), GB (gigabytes), TB (terabytes), PB (petabytes), 或 EB (exabytes)。

        以下示例为监控用户定义的项目的 Prometheus 实例将保留时间设置为 24 小时,保留大小设为 10GB:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              retention: 24h
              retentionSize: 10GB
  2. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

2.10.5. 修改 Thanos Ruler 指标数据的保留时间

默认情况下,对于用户定义的项目,Thanos Ruler 会在 24 小时内自动保留指标数据。您可以通过在 openshift-user-workload-monitoring 命名空间中指定 user-workload-monitoring-config 配置映射中的 time 值来修改这些数据的保留时间。

先决条件

  • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. 将保留时间配置添加到 data/config.yaml 下:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          retention: <time_specification> 1
    1
    以以下格式指定保留时间:数字直接后跟 ms (毫秒)、s (秒)、m (分钟)、h (小时)、d (天)、w (周)或 y (年)。您还可以组合指定时间值,如 1h30m15s。默认值为 24h

    以下示例将 Thanos Ruler 数据的保留时间设置为 10 天:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          retention: 10d
  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

2.11. 配置远程写入存储

您可以配置远程写入存储,使 Prometheus 能够将最接近的指标发送到远程系统,以进行长期存储。这样做不会影响 Prometheus 存储指标的方式和时长。

先决条件

  • 如果要配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果您要配置用于监控用户定义的项目的组件:

    • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。
  • 您已设置了一个远程写入兼容端点(如 Thanos),并且知道端点 URL。有关与远程写入功能兼容的端点的信息,请参阅 Prometheus 远程端点和存储文档

    重要

    红帽只提供配置远程写入发送者的信息,而不提供有关配置接收器端点的指导。客户负责设置自己的端点,这些端点与远程写入兼容。端点接收器配置的问题不包括在红帽产品支持中。

  • 您已为远程写入端点在 Secret 对象中设置身份验证凭证。您必须在与配置远程写入的 Prometheus 对象相同的命名空间中创建 secret:用于默认平台监控的 openshift-monitoring 命名空间或 openshift-user-workload-monitoring 命名空间用于用户工作负载监控。

    警告

    要减少安全风险,请使用 HTTPS 和身份验证向端点发送指标。

流程

  1. 编辑 ConfigMap 对象:

    • 为监控 OpenShift Container Platform 核心项目的 Prometheus 实例配置远程写入

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml/prometheusK8s 下添加一个 remoteWrite: 部分。
      3. 在本节中添加端点 URL 和身份验证凭证:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com" 1
                <endpoint_authentication_credentials> 2
        1
        远程写入端点的 URL。
        2
        端点的身份验证方法和凭据。目前支持的身份验证方法有 AWS 签名版本 4,使用 HTTP Authorization 请求标头、基本身份验证、OAuth 2.0 和 TLS 客户端进行身份验证。有关支持的身份验证方法示例配置,请参阅支持的远程写入身份验证设置
      4. 在身份验证凭证后添加 write relabel 配置值:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                <endpoint_authentication_credentials>
                <your_write_relabel_configs> 1
        1
        写入重新标记配置设置。

        对于 <your_write_relabel_configs>,请替换您要发送到远程端点的指标写入重新标记配置列表。

        以下示例演示了如何转发名为 my_metric 的单个指标:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                writeRelabelConfigs:
                - sourceLabels: [__name__]
                  regex: 'my_metric'
                  action: keep

        有关写入重新标记配置选项的详情,请查看 Prometheus relabel_config 文档

    • 为监控用户定义的项目的 Prometheus 实例配置远程写入

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml/prometheus 下添加一个 remoteWrite: 部分。
      3. 在本节中添加端点 URL 和身份验证凭证:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com" 1
                <endpoint_authentication_credentials> 2
        1
        远程写入端点的 URL。
        2
        端点的身份验证方法和凭据。目前支持的身份验证方法有 AWS 签名版本 4,使用 HTTP Authorization 请求标头、基本身份验证、OAuth 2.0 和 TLS 客户端进行身份验证。有关支持的身份验证方法示例配置,请参见以下支持的远程写入身份验证设置
      4. 在身份验证凭证后添加 write relabel 配置值:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                <endpoint_authentication_credentials>
                <your_write_relabel_configs> 1
        1
        写入重新标记配置设置。

        对于 <your_write_relabel_configs>,请替换您要发送到远程端点的指标写入重新标记配置列表。

        以下示例演示了如何转发名为 my_metric 的单个指标:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                writeRelabelConfigs:
                - sourceLabels: [__name__]
                  regex: 'my_metric'
                  action: keep

        有关写入重新标记配置选项的详情,请查看 Prometheus relabel_config 文档

  2. 保存文件以使改变生效。新的配置会被自动应用。

2.11.1. 支持的远程写入身份验证设置

您可以使用不同的方法通过远程写入端点进行身份验证。目前支持的身份验证方法有 AWS 签名版本 4、基本身份验证、授权、OAuth 2.0 和 TLS 客户端。下表提供有关用于远程写入的受支持身份验证方法的详情。

身份验证方法配置映射字段描述

AWS 签名版本 4

sigv4

此方法使用 AWS 签名版本 4 身份验证为请求签名。您不能搭配授权、OAuth 2.0 或基本身份验证同时使用此方法。

基本身份验证(Basic authentication)

basicAuth

基本身份验证使用配置的用户名和密码在每个远程写入请求上设置授权标头。

授权

授权

授权使用配置的令牌在每个远程写入请求上设置 Authorization 标头。

OAuth 2.0

oauth2

OAuth 2.0 配置使用客户端凭据授予类型。Prometheus 使用指定的客户端 ID 和客户端 secret 从 tokenUrl 获取访问令牌来访问远程写入端点。您不能与授权、AWS 签名版本 4 或基本身份验证同时使用此方法。

TLS 客户端

tlsConfig

TLS 客户端配置指定 CA 证书、客户端证书和客户端密钥文件信息,用于使用 TLS 与远程写入端点服务器进行身份验证。示例配置假定您已创建了 CA 证书文件、客户端证书文件和客户端密钥文件。

2.11.2. 远程写入身份验证设置示例

以下示例展示了可用于连接到远程写入端点的不同身份验证设置。每个示例还演示了如何配置包含身份验证凭据和其他相关设置的对应 Secret 对象。每个示例配置身份验证,以用于 openshift-monitoring 命名空间中的默认平台监控。

例 2.1. AWS 签名版本 4 验证的 YAML 示例

以下显示了 openshift-monitoring 命名空间中名为 sigv4-credentialssigv4 secret 的设置。

apiVersion: v1
kind: Secret
metadata:
  name: sigv4-credentials
  namespace: openshift-monitoring
stringData:
  accessKey: <AWS_access_key> 1
  secretKey: <AWS_secret_key> 2
type: Opaque
1
AWS API 访问密钥。
2
AWS API secret 密钥。

下面显示了一个 AWS Signature Version 4 远程写入身份验证设置示例,它使用一个在 openshift-monitoring 命名空间中的名为 sigv4-credentialsSecret 对象:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      remoteWrite:
      - url: "https://authorization.example.com/api/write"
        sigv4:
          region: <AWS_region> 1
          accessKey:
            name: sigv4-credentials 2
            key: accessKey 3
          secretKey:
            name: sigv4-credentials 4
            key: secretKey 5
          profile: <AWS_profile_name> 6
          roleArn: <AWS_role_arn> 7
1
AWS 区域。
2 4
包含 AWS API 访问凭证的 Secret 对象的名称。
3
在指定 Secret 对象中包含 AWS API 访问密钥的密钥。
5
在指定的 Secret 对象中包含 AWS API secret 键的密钥。
6
用于验证的 AWS 配置集的名称。
7
分配给角色的 Amazon 资源名称(ARN)的唯一标识符。

例 2.2. 用于基本身份验证的 YAML 示例

以下显示了 openshift-monitoring 命名空间中名为 rw-basic-authSecret 对象基本身份验证设置示例:

apiVersion: v1
kind: Secret
metadata:
  name: rw-basic-auth
  namespace: openshift-monitoring
stringData:
  user: <basic_username> 1
  password: <basic_password> 2
type: Opaque
1
用户名。
2
密码。

以下示例显示了使用 openshift-monitoring 命名空间中名为 rw-basic-authSecret 对象的 basicAuth 远程写入配置。它假设您已为端点设置了身份验证凭据。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      remoteWrite:
      - url: "https://basicauth.example.com/api/write"
        basicAuth:
          username:
            name: rw-basic-auth 1
            key: user 2
          password:
            name: rw-basic-auth 3
            key: password 4
1 3
包含身份验证凭据的 Secret 对象的名称。
2
在指定的 Secret 对象中包含用户名的密钥。
4
在指定 Secret 对象中包含密码的密钥。

例 2.3. 使用 Secret 对象通过 bearer 令牌进行身份验证的 YAML 示例

以下显示了 openshift-monitoring 命名空间中名为 rw-bearer-authSecret 对象的 bearer 令牌设置:

apiVersion: v1
kind: Secret
metadata:
  name: rw-bearer-auth
  namespace: openshift-monitoring
stringData:
  token: <authentication_token> 1
type: Opaque
1
身份验证令牌。

以下显示了在 openshift-monitoring 命名空间中使用名为 rw-bearer-authSecret 对象的 bearer 令牌配置映射设置示例:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    enableUserWorkload: true
    prometheusK8s:
      remoteWrite:
      - url: "https://authorization.example.com/api/write"
        authorization:
          type: Bearer 1
          credentials:
            name: rw-bearer-auth 2
            key: token 3
1
请求的验证类型。默认值为 Bearer
2
包含身份验证凭据的 Secret 对象的名称。
3
在指定的 Secret 对象中包含身份验证令牌的密钥。

例 2.4. 用于 OAuth 2.0 验证的 YAML 示例

以下显示了 openshift-monitoring 命名空间中名为 oauth2-credentialsSecret 对象的 OAuth 2.0 设置示例:

apiVersion: v1
kind: Secret
metadata:
  name: oauth2-credentials
  namespace: openshift-monitoring
stringData:
  id: <oauth2_id> 1
  secret: <oauth2_secret> 2
type: Opaque
1
Oauth 2.0 ID。
2
OAuth 2.0 secret。

下面显示了一个 oauth2 远程写入身份验证示例配置,它使用 openshift-monitoring 命名空间中名为 oauth2-credentialsSecret 对象:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      remoteWrite:
      - url: "https://test.example.com/api/write"
        oauth2:
          clientId:
            secret:
              name: oauth2-credentials 1
              key: id 2
          clientSecret:
            name: oauth2-credentials 3
            key: secret 4
          tokenUrl: https://example.com/oauth2/token 5
          scopes: 6
          - <scope_1>
          - <scope_2>
          endpointParams: 7
            param1: <parameter_1>
            param2: <parameter_2>
1 3
对应的 Secret 对象的名称。请注意,ClientId 可以引用 ConfigMap 对象,但 clientSecret 必须引用 Secret 对象。
2 4
在指定 Secret 对象中包含 OAuth 2.0 凭证的密钥。
5
用于通过指定的 clientIdclientSecret 获取令牌的 URL。
6
授权请求的 OAuth 2.0 范围。这些范围限制了令牌可以访问的数据。
7
授权服务器所需的 OAuth 2.0 授权请求参数。

例 2.5. TLS 客户端身份验证的 YAML 示例

以下显示了 openshift-monitoring 命名空间中名为 mtls-bundletls Secret 对象的 TLS 客户端设置示例。

apiVersion: v1
kind: Secret
metadata:
  name: mtls-bundle
  namespace: openshift-monitoring
data:
  ca.crt: <ca_cert> 1
  client.crt: <client_cert> 2
  client.key: <client_key> 3
type: tls
1
Prometheus 容器中用于验证服务器证书的 CA 证书。
2
用于与服务器进行身份验证的客户端证书。
3
客户端密钥。

以下示例显示了使用名为 mtls-bundle 的 TLS Secret 对象的 tlsConfig 远程写入身份验证配置。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      remoteWrite:
      - url: "https://remote-write-endpoint.example.com"
        tlsConfig:
          ca:
            secret:
              name: mtls-bundle 1
              key: ca.crt 2
          cert:
            secret:
              name: mtls-bundle 3
              key: client.crt 4
          keySecret:
            name: mtls-bundle 5
            key: client.key 6
1 3 5
包含 TLS 身份验证凭证的对应 Secret 对象的名称。请注意,cacert 可以引用 ConfigMap 对象,但 keySecret 必须引用 Secret 对象。
2
指定 Secret 对象中的键,其中包含端点的 CA 证书。
4
指定 Secret 对象中的键,其中包含端点的客户端证书。
6
包含客户端密钥 secret 的指定 Secret 对象中的密钥。

其他资源

2.12. 在指标中添加集群 ID 标签

如果您管理多个 OpenShift Container Platform 集群,并使用远程写入功能将指标数据从这些集群发送到外部存储位置,您可以添加集群 ID 标签来识别来自不同集群的指标数据。然后,您可以查询这些标签来标识指标的源集群,并区分与其他集群发送的类似指标数据的数据。

这样,如果您为多个客户管理多个集群,并将指标数据发送到单个集中存储系统,您可以使用集群 ID 标签查询特定集群或客户的指标。

创建并使用集群 ID 标签涉及三个常规步骤:

  • 配置远程写入存储的写重新标记设置。
  • 将集群 ID 标签添加到指标。
  • 查询这些标签以标识源集群或指标客户。

2.12.1. 为指标创建集群 ID 标签

您可以为默认平台监控和用户工作负载监控创建集群 ID 标签。

对于默认平台监控,您可以在 openshift-monitoring 命名空间中为 cluster-monitoring-config 配置映射中的 write_relabel 设置中为指标添加集群 ID 标签。

对于用户工作负载监控,您可以编辑 openshift-user-workload-monitoring 命名空间中的 user-workload-monitoring-config 配置映射中的设置。

注意

当 Prometheus 提取公开 namespace 标签的用户工作负载目标时,系统会将此标签存储为 exported_namespace。此行为可确保最终命名空间标签值等于目标 pod 的命名空间。您不能将 PodMonitorServiceMonitor 对象的 honorLabels 字段的值设置为 true 来覆盖此默认配置。

先决条件

  • 如果要配置默认平台监控组件:

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果您要配置用于监控用户定义的项目的组件:

    • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。
  • 您已配置了远程写入存储。

流程

  1. 编辑 ConfigMap 对象:

    • 为 OpenShift Container Platform 核心指标创建集群 ID 标签:

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml/prometheusK8s/remoteWrite 中的 writeRelabelConfigs: 部分添加集群 ID 重新标记配置值:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                <endpoint_authentication_credentials>
                writeRelabelConfigs: 1
                  - <relabel_config> 2
        1
        为您要发送到远程端点的指标添加写入重新标记配置列表。
        2
        替换发送到远程写入端点的指标的标签配置。

        以下示例演示了如何在默认平台监控中使用集群 ID 标签 cluster_id 转发指标:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                writeRelabelConfigs:
                - sourceLabels:
                  - __tmp_openshift_cluster_id__ 1
                  targetLabel: cluster_id 2
                  action: replace 3
        1
        系统最初应用名为 __tmp_openshift_cluster_id__ 的临时集群 ID 源标签。此临时标签由您指定的集群 ID 标签名称替换。
        2
        指定发送到远程写入存储的指标的集群 ID 标签名称。如果您使用指标已存在的标签名称,则该值会使用这个集群 ID 标签的名称覆盖。对于标签名称,不要使用 __tmp_openshift_cluster_id__。最后重新标记步骤会删除使用此名称的标签。
        3
        replace write relabel 操作,将临时标签替换为传出指标的目标标签。这个操作是默认行为,如果没有指定任何操作,则会被应用。
    • 为用户定义的项目指标创建集群 ID 标签:

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml/prometheus/remoteWrite 下的 writeRelabelConfigs: 部分中,添加集群 ID 重新标记配置值:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                <endpoint_authentication_credentials>
                writeRelabelConfigs: 1
                  - <relabel_config> 2
        1
        为您要发送到远程端点的指标添加写入重新标记配置列表。
        2
        替换发送到远程写入端点的指标的标签配置。

        以下示例演示了如何在 user-workload 监控中使用集群 ID 标签 cluster_id 转发指标:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                writeRelabelConfigs:
                - sourceLabels:
                  - __tmp_openshift_cluster_id__ 1
                  targetLabel: cluster_id 2
                  action: replace 3
        1
        系统最初应用名为 __tmp_openshift_cluster_id__ 的临时集群 ID 源标签。此临时标签由您指定的集群 ID 标签名称替换。
        2
        指定发送到远程写入存储的指标的集群 ID 标签名称。如果您使用指标已存在的标签名称,则该值会使用这个集群 ID 标签的名称覆盖。对于标签名称,不要使用 __tmp_openshift_cluster_id__。最后重新标记步骤会删除使用此名称的标签。
        3
        replace write relabel 操作,将临时标签替换为传出指标的目标标签。这个操作是默认行为,如果没有指定任何操作,则会被应用。
  2. 保存文件以使改变生效。新的配置会被自动应用。

其他资源

2.13. 配置指标集合配置集

重要

使用指标集合配置集只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅 https://access.redhat.com/support/offerings/techpreview

默认情况下,Prometheus 会收集由 OpenShift Container Platform 组件中的所有默认指标目标公开的指标。但是,在某些情况下,您可能希望 Prometheus 从集群收集较少的指标:

  • 集群管理员只需要警报、遥测和控制台指标,且不需要其他指标数据。
  • 集群大小增加,且收集的默认指标数据的大小现在需要显著增加 CPU 和内存资源。

您可以使用指标集合配置集来收集默认指标数据数量或最小指标数据。当您收集最小指标数据时,警报等基本监控功能将继续工作。同时,Prometheus 所需的 CPU 和内存资源会减少。

2.13.1. 关于指标集合配置集

您可以启用两个指标集合配置集之一:

  • full :Prometheus 会收集由所有平台组件公开的指标数据。此设置是默认设置。
  • minimal :Prometheus 仅收集平台警报、记录规则、遥测和控制台仪表板所需的指标数据。

2.13.2. 选择指标集合配置集

要为 OpenShift Container Platform 核心监控组件选择指标集合配置集,请编辑 cluster-monitoring-config ConfigMap 对象。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已使用 FeatureGate 自定义资源 (CR) 启用了技术预览功能。
  • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。

流程

  1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml/prometheusK8s 下添加 metrics collection 配置集设置:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          collectionProfile: <metrics_collection_profile_name> 1
    1
    指标集合配置集的名称。可用值为 fullminimal。如果没有指定值,或者配置映射中不存在 collectionProfile 键名称,则会使用 full 的默认设置。

    以下示例将 Prometheus 核心平台实例的指标集合配置集设置为 minimal

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          collectionProfile: minimal
  3. 保存文件以使改变生效。新的配置会被自动应用。

其他资源

2.14. 控制用户定义的项目中未绑定指标属性的影响

开发人员可以使用键值对的形式为指标定义属性。潜在的键值对数量与属性的可能值数量对应。具有无限数量可能值的属性被称为未绑定属性。例如,customer_id 属性不绑定,因为它有无限多个可能的值。

每个分配的键值对都有唯一的时间序列。在标签中使用许多未绑定属性可导致所创建的时间序列数量出现指数增加。这可能会影响 Prometheus 性能,并消耗大量磁盘空间。

集群管理员可以使用以下方法控制用户定义的项目中未绑定指标属性的影响:

  • 限制用户定义的项目中每个目标提取可接受的示例数量
  • 限制提取标签数量、标签名称长度以及标签值长度
  • 创建在达到提取示例阈值或无法提取目标时触发的警报
注意

限制提取示例可帮助防止在标签中添加多个未绑定属性导致的问题。开发人员还可以通过限制其为指标定义的未绑定属性数量来防止底层原因。使用绑定到一组有限可能值的属性可减少潜在的键-值对组合数量。

2.14.1. 为用户定义的项目设置提取示例和标签限制

您可以限制用户定义的项目中每个目标提取可接受的示例数量。您还可以限制提取标签数量、标签名称长度以及标签值长度。

警告

如果您设置了 sample 或 label limits,则在达到限制后,不会为该目标提取获得进一步的示例数据。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. data/config.yaml 中添加 enforcedSampleLimit 配置,以限制用户定义的项目中每个目标提取可接受的示例数量:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          enforcedSampleLimit: 50000 1
    1
    如果指定此参数,则需要一个值。这个 enforceSampleLimit 示例将用户定义的项目中每个目标提取的示例数量限制为 50,000。
  3. enforcedLabelLimit, enforcedLabelNameLengthLimit, 和 enforcedLabelValueLengthLimit 配置添加到 data/config.yaml,以限制刮除的标签数量、标签名称长度以及用户定义的项目中的标签值长度:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          enforcedLabelLimit: 500 1
          enforcedLabelNameLengthLimit: 50 2
          enforcedLabelValueLengthLimit: 600 3
    1
    指定每次刮除的最大标签数。默认值为 0,代表没有指定限制。
    2
    指定标签名称字符的最大长度。默认值为 0,代表没有指定限制。
    3
    指定标签值字符的最大长度。默认值为 0,代表没有指定限制。
  4. 保存文件以使改变生效。限制会自动应用。

2.14.2. 创建提取示例警报

您可以创建在以下情况下通知您的警报:

  • 在指定的 for 持续时间内无法提取对象或对象不可用
  • 在指定的 for 持续时间内达到或超过提取示例阈值

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 您已经使用 enforcedSampleLimit 限制了用户定义的项目中每个目标提取可接受的示例数量。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 创建一个包含警报的 YAML 文件,用于在目标停机以及即将达到强制的示例限制时通知您。本例中的文件名为 monitoring-stack-alerts.yaml

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      labels:
        prometheus: k8s
        role: alert-rules
      name: monitoring-stack-alerts 1
      namespace: ns1 2
    spec:
      groups:
      - name: general.rules
        rules:
        - alert: TargetDown 3
          annotations:
            message: '{{ printf "%.4g" $value }}% of the {{ $labels.job }}/{{ $labels.service
              }} targets in {{ $labels.namespace }} namespace are down.' 4
          expr: 100 * (count(up == 0) BY (job, namespace, service) / count(up) BY (job,
            namespace, service)) > 10
          for: 10m 5
          labels:
            severity: warning 6
        - alert: ApproachingEnforcedSamplesLimit 7
          annotations:
            message: '{{ $labels.container }} container of the {{ $labels.pod }} pod in the {{ $labels.namespace }} namespace consumes {{ $value | humanizePercentage }} of the samples limit budget.' 8
          expr: scrape_samples_scraped/50000 > 0.8 9
          for: 10m 10
          labels:
            severity: warning 11
    1
    定义警报规则的名称。
    2
    指定要部署警报规则的用户定义的项目。
    3
    如果在 for 持续时间内无法提取目标或者目标不可用,则 TargetDown 警报将触发。
    4
    TargetDown 警报触发时输出的消息。
    5
    在这个持续时间内必须满足 TargetDown 警报的条件才会触发该警报。
    6
    定义 TargetDown 警报的严重性。
    7
    当在指定的 for 持续时间内达到或超过定义的提取示例阈值时,ApproachingEnforcedSamplesLimit 警报将触发。
    8
    ApproachingEnforcedSamplesLimit 警报触发时输出的消息。
    9
    ApproachingEnforcedSamplesLimit 警报的阈值。在本例中,当每个目标提取的示例数量超过强制示例限制 50000 的 80% 时,警报将触发。在警报触发前,还必须已经过了 for 持续时间。表达式 scrape_samples_scraped/<number> > <threshold> 中的 <number> 必须与 user-workload-monitoring-config ConfigMap 对象中定义的 enforcedSampleLimit 值匹配。
    10
    在这个持续时间内必须满足 ApproachingEnforcedSamplesLimit 警报的条件才会触发该警报。
    11
    定义 ApproachingEnforcedSamplesLimit 警报的严重性。
  2. 将配置应用到用户定义的项目中:

    $ oc apply -f monitoring-stack-alerts.yaml

其他资源

第 3 章 配置外部 Alertmanager 实例

OpenShift Container Platform 监控堆栈包含一个本地 Alertmanager 实例,用于从 Prometheus 路由警报。您可以添加外部 Alertmanager 实例,以路由 OpenShift Container Platform 核心项目或用户定义的项目的警报。

如果您为多个集群添加相同的外部 Alertmanager 配置,并且为每个集群禁用本地实例,则可以使用单个外部 Alertmanager 实例管理多个集群的警报路由。

先决条件

  • 如果要在 openshift-monitoring 项目中配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建了 cluster-monitoring-config 配置映射。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 ConfigMap 对象。

    • 配置额外的 Alertmanager 以路由来自 OpenShift Container Platform 核心项目的警报

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config 配置映射:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml/prometheusK8s 下添加一个 additionalAlertmanagerConfigs: 小节。
      3. 在本节中添加其他 Alertmanager 的配置详情:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              additionalAlertmanagerConfigs:
              - <alertmanager_specification>

        对于 <alertmanager_specification>,请替换额外的 Alertmanager 实例的身份验证和其他配置详情。目前支持的身份验证方法有 bearer 令牌 (bearerToken) 和客户端 TLS (tlsConfig)。以下示例配置映射使用 bearer 令牌和客户端 TLS 身份验证配置额外的 Alertmanager:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              additionalAlertmanagerConfigs:
              - scheme: https
                pathPrefix: /
                timeout: "30s"
                apiVersion: v1
                bearerToken:
                  name: alertmanager-bearer-token
                  key: token
                tlsConfig:
                  key:
                    name: alertmanager-tls
                    key: tls.key
                  cert:
                    name: alertmanager-tls
                    key: tls.crt
                  ca:
                    name: alertmanager-tls
                    key: tls.ca
                staticConfigs:
                - external-alertmanager1-remote.com
                - external-alertmanager1-remote2.com
    • 配置额外的 Alertmanager 实例以路由来自用户定义的项目的警报

      1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml/ 下添加一个 <component>/additionalAlertmanagerConfigs: 部分。
      3. 在本节中添加其他 Alertmanager 的配置详情:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              additionalAlertmanagerConfigs:
              - <alertmanager_specification>

        对于 <component>,替换两个支持的外部 Alertmanager 组件之一:prometheusthanosRuler

        对于 <alertmanager_specification>,请替换额外的 Alertmanager 实例的身份验证和其他配置详情。目前支持的身份验证方法有 bearer 令牌 (bearerToken) 和客户端 TLS (tlsConfig)。以下示例配置映射使用带有 bearer 令牌和客户端 TLS 身份验证的 Thanos Ruler 配置额外的 Alertmanager:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              additionalAlertmanagerConfigs:
              - scheme: https
                pathPrefix: /
                timeout: "30s"
                apiVersion: v1
                bearerToken:
                  name: alertmanager-bearer-token
                  key: token
                tlsConfig:
                  key:
                    name: alertmanager-tls
                    key: tls.key
                  cert:
                    name: alertmanager-tls
                    key: tls.crt
                  ca:
                    name: alertmanager-tls
                    key: tls.ca
                staticConfigs:
                - external-alertmanager1-remote.com
                - external-alertmanager1-remote2.com
  2. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

第 4 章 为 Alertmanager 配置 secret

OpenShift Container Platform 监控堆栈包括 Alertmanager,它将警报从 Prometheus 路由到端点接收器。如果您需要通过接收器进行身份验证以便 Alertmanager 能够向它发送警报,您可以将 Alertmanager 配置为使用包含接收器身份验证凭据的 secret。

例如,您可以将 Alertmanager 配置为使用 secret 与需要由私有证书颁发机构 (CA) 发布的证书的端点接收器进行身份验证。您还可以将 Alertmanager 配置为使用 secret 与需要用于基本 HTTP 身份验证密码文件的接收器进行身份验证。在这两种情况下,身份验证详情都包含在 Secret 对象中,而不是包括在 ConfigMap 对象中。

4.1. 在 Alertmanager 配置中添加 secret

您可以通过编辑 openshift-monitoring 项目中的 cluster-monitoring-config 配置映射,将 secret 添加到核心平台监控组件的 Alertmanager 配置中。

将 secret 添加到配置映射后,secret 作为一个卷挂载到 Alertmanager Pod 的 alertmanager 容器中的 /etc/alertmanager/secrets/<secret_name 的卷中。

先决条件

  • 如果要在 openshift-monitoring 项目中配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建了 cluster-monitoring-config 配置映射。
    • 您已创建了要在 openshift-monitoring 项目中的 Alertmanager 中配置的 secret。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 您已创建了要在 openshift-user-workload-monitoring 项目中的 Alertmanager 中配置的 secret。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 ConfigMap 对象。

    • 在 Alertmanager 中为核心平台监控添加 secret 配置

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config 配置映射:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml/alertmanagerMain 下添加一个 secrets: 部分,并具有以下配置:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              secrets: 1
              - <secret_name_1> 2
              - <secret_name_2>
        1
        本节包含要挂载到 Alertmanager 中的 secret。secret 必须位于与 Alertmanager 对象相同的命名空间中。
        2
        包含接收器身份验证凭证的 Secret 对象的名称。如果您添加多个 secret,请将每个 secret 放在新行中。

        以下示例配置映射设置将 Alertmanager 配置为使用名为 test-secret-basic-authtest-secret-api-token 的两个 Secret 对象:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              secrets:
              - test-secret-basic-auth
              - test-secret-api-token
    • 将 secret 配置添加到 Alertmanager 中用于用户定义的项目的监控

      1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. 使用以下配置,在 data/config.yaml/alertmanager/secrets 下添加一个 secrets: 部分:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            alertmanager:
              secrets: 1
              - <secret_name_1> 2
              - <secret_name_2>
        1
        本节包含要挂载到 Alertmanager 中的 secret。secret 必须位于与 Alertmanager 对象相同的命名空间中。
        2
        包含接收器身份验证凭证的 Secret 对象的名称。如果您添加多个 secret,请将每个 secret 放在新行中。

        以下示例配置映射设置将 Alertmanager 配置为使用名为 test-secrettest-secret-api-token 的两个 Secret 对象:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            alertmanager:
              enabled: true
              secrets:
              - test-secret
              - test-api-receiver-token
  2. 保存文件以使改变生效。新的配置会被自动应用。

4.2. 在时间序列和警报中附加额外标签

您可以使用 Prometheus 的外部标签功能,将自定义标签附加到离开 Prometheus 的所有时间序列和警报。

先决条件

  • 如果要配置 OpenShift Container Platform 核心监控组件

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果您要配置用于监控用户定义的项目的组件

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 ConfigMap 对象:

    • 对于监控 OpenShift Container Platform 核心项目的 Prometheus 实例,要将自定义标签附加到离开的所有时间序列和警报

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml 下定义每个指标要添加的标签映射:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              externalLabels:
                <key>: <value> 1
        1
        使用键值对替换 <key>: <value>,其中 <key> 是新标签的唯一名称,<value> 是它的值。
        警告
        • 不要使用 prometheus prometheus_replica 作为键的名称,因为它们是保留的并会被覆盖。
        • 不要使用 clustermanaged_cluster 作为密钥名称。使用它们可能会导致您无法在开发人员仪表板中看到数据的问题。

        例如,要将关于区域和环境的元数据添加到所有时间序列和警报中,请使用以下示例:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              externalLabels:
                region: eu
                environment: prod
      3. 保存文件以使改变生效。新的配置会被自动应用。
    • 对于监控用户定义的项目的 Prometheus 实例,要将自定义标签附加到离开的所有时间序列和警报

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml 下定义每个指标要添加的标签映射:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              externalLabels:
                <key>: <value> 1
        1
        使用键值对替换 <key>: <value>,其中 <key> 是新标签的唯一名称,<value> 是它的值。
        警告
        • 不要使用 prometheus prometheus_replica 作为键的名称,因为它们是保留的并会被覆盖。
        • 不要使用 clustermanaged_cluster 作为密钥名称。使用它们可能会导致您无法在开发人员仪表板中看到数据的问题。
        注意

        openshift-user-workload-monitoring 项目中,Prometheus 负责处理指标,而 Thanos Ruler 负责处理警报和记录规则。在 user-workload-monitoring-config ConfigMap 中为 prometheus 设置 externalLabels 只会为指标配置外部标签,而不会为任何规则配置外部标签。

        例如,要将有关地区和环境的元数据添加到与用户定义的项目相关的所有时间序列和警报中,请使用以下示例:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              externalLabels:
                region: eu
                environment: prod
      3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

其他资源

第 5 章 使用 pod 拓扑分布限制来监控

当 OpenShift Container Platform pod 部署到多个可用区时,您可以使用 pod 拓扑分布约束来控制监控 pod 如何分散到网络拓扑中。

Pod 拓扑分布约束适合在分层拓扑内控制 pod 调度,节点分散到不同的基础架构级别,如这些区域内的地区和区域。另外,通过能够在不同区中调度 pod,您可以在某些情况下提高网络延迟。

5.1. 配置 pod 拓扑分布限制

您可以为 Cluster Monitoring Operator 部署的所有 pod 配置 pod 拓扑分布限制,以控制如何在区调度到节点的 pod 副本。这样可确保 pod 具有高可用性并更有效地运行,因为工作负载分散在不同的数据中心或分层基础架构区域中。

您可以使用 cluster-monitoring-configuser-workload-monitoring-config 配置映射为监控 pod 配置 pod 拓扑分布限制。

先决条件

  • 如果要为 OpenShift Container Platform 核心监控配置 pod:

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果要为用户定义的监控配置 pod:

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  • 为 OpenShift Container Platform 核心监控配置 pod 拓扑分布限制:

    1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config 配置映射:

      $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
    2. data/config.yaml 字段中添加以下设置来配置 pod 拓扑分布限制:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          <component>: 1
            topologySpreadConstraints:
            - maxSkew: <n> 2
              topologyKey: <key> 3
              whenUnsatisfiable: <value> 4
              labelSelector: 5
                <match_option>
      1
      指定您要为其设置 pod 拓扑分布限制的组件名称。
      2
      maxSkew 指定数字值,它定义了允许不均匀分布 pod 的程度。
      3
      topologyKey 指定节点标签键。带有具有此键和相同值标签的节点被视为在同一拓扑中。调度程序会尝试将大量 pod 放置到每个域中。
      4
      whenUnsatisfiable 指定一个值。可用选项包括 DoNotScheduleScheduleAnyway。如果您希望 maxSkew 值定义目标拓扑和全局最小值中匹配 pod 数量之间允许的最大值,则指定 DoNotSchedule。如果您希望调度程序仍然调度 pod,但为可能降低 skew 的节点赋予更高的优先级,请指定 ScheduleAnyway
      5
      指定 labelSelector 来查找匹配的 pod。与此标签选择器匹配的 Pod 被计算,以确定其对应拓扑域中的 pod 数量。

      Prometheus 配置示例

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          prometheusK8s:
            topologySpreadConstraints:
            - maxSkew: 1
              topologyKey: monitoring
              whenUnsatisfiable: DoNotSchedule
              labelSelector:
                matchLabels:
                  app.kubernetes.io/name: prometheus

    3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
  • 为用户定义的监控配置 pod 拓扑分布限制:

    1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    2. data/config.yaml 字段中添加以下设置来配置 pod 拓扑分布限制:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          <component>: 1
            topologySpreadConstraints:
            - maxSkew: <n> 2
              topologyKey: <key> 3
              whenUnsatisfiable: <value> 4
              labelSelector: 5
                <match_option>
      1
      指定您要为其设置 pod 拓扑分布限制的组件名称。
      2
      maxSkew 指定数字值,它定义了允许不均匀分布 pod 的程度。
      3
      topologyKey 指定节点标签键。带有具有此键和相同值标签的节点被视为在同一拓扑中。调度程序会尝试将大量 pod 放置到每个域中。
      4
      whenUnsatisfiable 指定一个值。可用选项包括 DoNotScheduleScheduleAnyway。如果您希望 maxSkew 值定义目标拓扑和全局最小值中匹配 pod 数量之间允许的最大值,则指定 DoNotSchedule。如果您希望调度程序仍然调度 pod,但为可能降低 skew 的节点赋予更高的优先级,请指定 ScheduleAnyway
      5
      指定 labelSelector 来查找匹配的 pod。与此标签选择器匹配的 Pod 被计算,以确定其对应拓扑域中的 pod 数量。

      Thanos Ruler 的配置示例

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          thanosRuler:
            topologySpreadConstraints:
            - maxSkew: 1
              topologyKey: monitoring
              whenUnsatisfiable: ScheduleAnyway
              labelSelector:
                matchLabels:
                  app.kubernetes.io/name: thanos-ruler

    3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

5.2. 为监控组件设置日志级别

您可以为 Alertmanager、Prometheus Operator、Prometheus、Thanos Querier 和 Thanos Ruler 配置日志级别。

以下日志级别可应用到 cluster-monitoring-configuser-workload-monitoring-config ConfigMap 中的相关组件:

  • debug。记录调试、信息、警告和错误消息。
  • info。记录信息、警告和错误消息。
  • warn。仅记录警告和错误消息。
  • error。仅记录错误消息。

默认日志级别为 info

先决条件

  • 如果要为 openshift-monitoring 项目中的 Alertmanager、Prometheus Operator、Prometheus 或 Thanos Querier 设置日志级别

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果要为 openshift-user-workload-monitoring 项目中的 Prometheus Operator、Prometheus 或 Thanos Ruler 设置日志级别

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 ConfigMap 对象:

    • 要为 openshift-monitoring 项目中的组件设置日志级别

      1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml 下为组件添加 logLevel: <log_level>

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              logLevel: <log_level> 2
        1
        您要为其设置日志级别的监控堆栈组件。对于默认平台监控,可用组件值包括 prometheusK8salertmanagerMainprometheusOperatorthanosQuerier
        2
        为组件设置的日志级别。可用值为 errorwarninfodebug。默认值为 info
    • 要为 openshift-user-workload-monitoring 项目中的组件设置日志级别

      1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      2. data/config.yaml 下为组件添加 logLevel: <log_level>

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              logLevel: <log_level> 2
        1
        您要为其设置日志级别的监控堆栈组件。对于用户工作负载监控,可用组件值有 alertmanagerprometheusprometheusOperatorthanosRuler
        2
        应用到组件的日志级别。可用值为 errorwarninfodebug。默认值为 info
  2. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
  3. 通过查看相关项目中的部署或 Pod 配置来确认已应用了日志级别。以下示例检查 openshift-user-workload-monitoring 项目中的 prometheus-operator 部署中的日志级别:

    $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml | grep "log-level"

    输出示例

            - --log-level=debug

  4. 检查组件的 Pod 是否正在运行。以下示例列出了 openshift-user-workload-monitoring 项目中 Pod 的状态:

    $ oc -n openshift-user-workload-monitoring get pods
    注意

    如果 ConfigMap 中包含了一个未识别的 loglevel 值,则组件的 Pod 可能无法成功重启。

5.3. 为 Prometheus 启用查询日志文件

您可以将 Prometheus 配置为将引擎运行的所有查询写入到日志文件。对于默认平台监控和用户定义的工作负载监控,您可以这样做。

重要

由于不支持日志轮转,因此仅在需要对问题进行故障排除时才临时启用此功能。完成故障排除后,通过恢复您对 ConfigMap 对象所做的更改来禁用查询日志记录,以启用该功能。

先决条件

  • 如果要在 openshift-monitoring 项目中为 Prometheus 启用查询日志文件功能

    • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
    • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 如果要在 openshift-user-workload-monitoring 项目中为 Prometheus 启用查询日志文件功能

    • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
    • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  • 要在 openshift-monitoring 项目中为 Prometheus 设置查询日志文件

    1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

      $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
    2. data/config.yaml 下为 prometheusK8s 添加 queryLogFile: <path>:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          prometheusK8s:
            queryLogFile: <path> 1
      1
      将在其中记录查询的文件的路径。
    3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
    4. 验证组件的 pod 是否正在运行。以下示例命令列出了 openshift-monitoring 项目中的 pod 状态:

      $ oc -n openshift-monitoring get pods
    5. 读取查询日志:

      $ oc -n openshift-monitoring exec prometheus-k8s-0 -- cat <path>
      重要

      在检查了记录的查询信息后,恢复配置映射的设置。

  • 要在 openshift-user-workload-monitoring 项目中为 Prometheus 设置查询日志文件

    1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    2. data/config.yaml 下为 prometheus 添加 queryLogFile: <path>

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheus:
            queryLogFile: <path> 1
      1
      将在其中记录查询的文件的路径。
    3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
    4. 验证组件的 pod 是否正在运行。以下示例命令列出了 openshift-user-workload-monitoring 项目中的 pod 状态:

      $ oc -n openshift-user-workload-monitoring get pods
    5. 读取查询日志:

      $ oc -n openshift-user-workload-monitoring exec prometheus-user-workload-0 -- cat <path>
      重要

      在检查了记录的查询信息后,恢复配置映射的设置。

其他资源

5.4. 为 Thanos Querier 启用查询日志记录

对于 openshift-monitoring 项目中的默认平台监控,您可以启用 Cluster Monitoring Operator 来记录 Thanos Querier 运行的所有查询。

重要

由于不支持日志轮转,因此仅在需要对问题进行故障排除时才临时启用此功能。完成故障排除后,通过恢复您对 ConfigMap 对象所做的更改来禁用查询日志记录,以启用该功能。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 您已创建 cluster-monitoring-config ConfigMap 对象。

流程

您可以在 openshift-monitoring 项目中为 Thanos Querier 启用查询日志记录:

  1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml 中添加 thanosQuerier 部分并添加值,如下例所示:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        thanosQuerier:
          enableRequestLogging: <value> 1
          logLevel: <value> 2
    1
    将值设为 true 以启用日志记录,并将 false 设置为 disable logging。默认值为 false
    2
    将值设为 debuginfowarnerror。如果 logLevel 没有值,则日志级别默认为 error
  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

验证

  1. 验证 Thanos Querier pod 是否正在运行。以下示例命令列出了 openshift-monitoring 项目中的 pod 状态:

    $ oc -n openshift-monitoring get pods
  2. 使用以下示例命令作为模型运行测试查询:

    $ token=`oc create token prometheus-k8s -n openshift-monitoring`
    $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: Bearer $token" 'https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query?query=cluster_version'
  3. 运行以下命令来读取查询日志:

    $ oc -n openshift-monitoring logs <thanos_querier_pod_name> -c thanos-query
    注意

    因为 thanos-querier pod 是高度可用的(HA)pod,所以您可能只能看到一个 pod 的日志。

  4. 检查日志记录的查询信息后,通过将配置映射中的 enableRequestLogging 值更改为 false 来禁用查询日志记录。

其他资源

5.5. 为 Prometheus Adapter 设置审计日志级别

在默认平台监控中,您可以为 Prometheus Adapter 配置审计日志级别。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 您已创建 cluster-monitoring-config ConfigMap 对象。

流程

您可以在默认 openshift-monitoring 项目中为 Prometheus Adapter 设置审计日志级别:

  1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config ConfigMap 对象:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml 下的 k8sPrometheusAdapter/audit 部分中添加 profile:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        k8sPrometheusAdapter:
          audit:
            profile: <audit_log_level> 1
    1
    应用到 Prometheus Adapter 的审计日志级别。
  3. 使用 profile: 参数的以下值之一设置审计日志级别:

    • None :不记录事件。
    • Metadata :仅记录请求的元数据,如用户、时间戳等。不要记录请求文本和响应文本。metadata 是默认的审计日志级别。
    • Request :仅记录元数据和请求文本,而不记录响应文本。这个选项不适用于非资源请求。
    • RequestResponse :日志事件元数据、请求文本和响应文本。这个选项不适用于非资源请求。
  4. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

验证

  1. 在配置映射的 k8sPrometheusAdapter/audit/profile 下,将日志级别设置为 Request 并保存文件。
  2. 确认 Prometheus Adapter 的 pod 正在运行。以下示例列出了 openshift-monitoring 项目中的 pod 状态:

    $ oc -n openshift-monitoring get pods
  3. 确认正确配置了审计日志级别和审计日志文件路径:

    $ oc -n openshift-monitoring get deploy prometheus-adapter -o yaml

    输出示例

    ...
      - --audit-policy-file=/etc/audit/request-profile.yaml
      - --audit-log-path=/var/log/adapter/audit.log

  4. 确认 openshift-monitoring 项目中的 prometheus-adapter 部署中应用了正确的日志级别:

    $ oc -n openshift-monitoring exec deploy/prometheus-adapter -c prometheus-adapter -- cat /etc/audit/request-profile.yaml

    输出示例

    "apiVersion": "audit.k8s.io/v1"
    "kind": "Policy"
    "metadata":
      "name": "Request"
    "omitStages":
    - "RequestReceived"
    "rules":
    - "level": "Request"

    注意

    如果您为 ConfigMap 对象中的 Prometheus Adapter 输入了一个未识别的 profile 值,则不会对 Prometheus Adapter 进行任何更改,Cluster Monitoring Operator 会记录错误。

  5. 查看 Prometheus Adapter 的审计日志:

    $ oc -n openshift-monitoring exec -c <prometheus_adapter_pod_name> -- cat /var/log/adapter/audit.log

其他资源

5.6. 禁用本地 Alertmanager

在 OpenShift Container Platform 监控堆栈的 openshift-monitoring 项目中默认启用从 Prometheus 实例路由警报的本地 Alertmanager。

如果您不需要本地 Alertmanager,可以通过在 openshift-monitoring 项目中配置 cluster-monitoring-config 配置映射来禁用它。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 您已创建了 cluster-monitoring-config 配置映射。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-monitoring 项目中的 cluster-monitoring-config 配置映射:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml 下为 alertmanagerMain 组件添加 enabled: false

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          enabled: false
  3. 保存文件以使改变生效。应用更改时,Alertmanager 实例会自动禁用。

其他资源

5.7. 后续步骤

第 6 章 为用户定义的项目启用监控

在 OpenShift Container Platform 中,除了默认的平台监控外,您还可以为用户定义的项目启用监控。您可以监控 OpenShift Container Platform 中的自己的项目,而无需额外的监控解决方案。使用这个功能可以集中监控核心平台组件和用户定义的项目。

注意

使用 Operator Lifecycle Manager (OLM) 安装的 Prometheus Operator 版本与用户定义的监控不兼容。因此,OpenShift Container Platform 不支持作为由 OLM Prometheus Operator 管理的 Prometheus 自定义资源 (CR) 安装的自定义 Prometheus 实例。

6.1. 为用户定义的项目启用监控

集群管理员可以通过在集群监控 ConfigMap 中设置 enableUserWorkload: true 字段来为用户定义的项目启用监控。

重要

为用户定义的项目启用监控前,您必须删除任何自定义 Prometheus 实例。

注意

您必须可以使用具有 cluster-admin 集群角色的用户访问集群,才能在 OpenShift Container Platform 中为用户定义的项目启用监控。然后,集群管理员可以选择性地授予用户权限来配置负责监控用户定义的项目的组件。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您已创建 cluster-monitoring-config ConfigMap 对象。
  • 您已选择性地创建并配置 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config ConfigMap。您可以在该 ConfigMap 中为监控用户定义的项目的组件添加配置选项。

    注意

    每次您将配置更改保存到 user-workload-monitoring-config ConfigMap 时,都会重新部署 openshift-user-workload-monitoring 项目中的 Pod。可能需要稍等片刻,这些组件才会重新部署。

流程

  1. 编辑 cluster-monitoring-config ConfigMap 对象:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. enableUserWorkload: true 添加到 data/config.yaml 下:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        enableUserWorkload: true 1
    1
    当设置为 true 时,enableUserWorkload 参数为集群中用户定义的项目启用监控。
  3. 保存文件以使改变生效。然后会自动启用对用户定义的项目的监控。

    注意

    如果您为用户定义的项目启用监控,则默认创建 user-workload-monitoring-config ConfigMap 对象。

  4. 验证 prometheus-operatorprometheus-user-workloadthanos-ruler-user-workload Pod 是否在 openshift-user-workload-monitoring 项目中运行。Pod 启动可能需要片刻时间:

    $ oc -n openshift-user-workload-monitoring get pod

    输出示例

    NAME                                   READY   STATUS        RESTARTS   AGE
    prometheus-operator-6f7b748d5b-t7nbg   2/2     Running       0          3h
    prometheus-user-workload-0             4/4     Running       1          3h
    prometheus-user-workload-1             4/4     Running       1          3h
    thanos-ruler-user-workload-0           3/3     Running       0          3h
    thanos-ruler-user-workload-1           3/3     Running       0          3h

6.2. 授予用户权限来监控用户定义的项目

集群管理员可以监控所有 OpenShift Container Platform 核心项目和用户定义的项目。

您还可以向开发人员和其他用户授予不同的权限:

  • 监控用户定义的项目。
  • 要配置用于监控用户定义的项目的组件。
  • 为用户定义的项目配置警报路由。

您可以通过分配以下监控角色之一来授予权限:

角色名称描述

monitoring-rules-view

具有此集群角色的用户具有对用户定义的项目 PrometheusRule 自定义资源的读取访问权限。它们也可以在 OpenShift Container Platform Web 控制台的 Developer 视角中查看警报。

monitoring-rules-edit

具有此集群角色的用户可以为用户定义的项目创建、修改和删除 PrometheusRule 自定义资源。它们也可以在 OpenShift Container Platform Web 控制台的 Developer 视角中创建和静默警报。

monitoring-edit

具有此集群角色的用户具有与具有 monitoring-rules-edit 集群角色的用户相同的权限。另外,用户可以创建、修改和删除 ServiceMonitorPodMonitor 资源,以便从服务和 pod 中提取指标。

user-workload-monitoring-config-edit

此角色在 openshift-user-workload-monitoring 项目中提供。具有此角色的用户可以编辑 user-workload-monitoring-config ConfigMap 对象,为用户定义的工作负载监控配置 Prometheus、Prometheus Operator、Alertmanager 和 Thanos Ruler。

alert-routing-edit

具有此集群角色的用户可以为用户定义的项目创建、更新和删除 AlertmanagerConfig 自定义资源。

以下小节详细介绍了如何使用 OpenShift Container Platform Web 控制台或 CLI 分配这些角色。

6.2.1. 使用 Web 控制台授予用户权限

您可以使用 OpenShift Container Platform Web 控制台授予用户权限来监控其自己的项目。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 要将角色分配到的用户帐户已存在。

流程

  1. 在 OpenShift Container Platform Web 控制台内的 Administrator 视角中,进入到 User ManagementRole BindingsCreate Binding
  2. Binding Type 部分中,选择“Namespace Role Binding”类型。
  3. Name 字段中输入角色绑定的名称。
  4. Namespace 字段中,选择要授予访问权限的用户定义的项目。

    重要

    监控角色将绑定到您在 Namespace 字段中应用的项目。您使用此流程向用户授予的权限将只应用于所选项目。

  5. Role Name 列表中选择 monitoring-rules-viewmonitoring-rules-editmonitoring-edit
  6. Subject 部分,选择 User
  7. Subject Name 字段中,输入用户名称。
  8. 选择 Create 以应用角色绑定。

6.2.2. 使用 CLI 授予用户权限

您可以使用 OpenShift CLI (oc) 授予用户权限来监控其自己的项目。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 要将角色分配到的用户帐户已存在。
  • 已安装 OpenShift CLI(oc)。

流程

  • 为项目的用户分配一个监控角色:

    $ oc policy add-role-to-user <role> <user> -n <namespace> 1
    1
    <role> 替换为 monitoring-rules-viewmonitoring-rules-editmonitoring-edit
    重要

    无论您选择什么角色,必须以集群管理员的身份将其与特定项目进行绑定。

    例如,将 <role> 替换为 monitoring-edit<user> 替换为 johnsmith<namespace> 替换为 ns1。这会为用户 johnsmith 分配在 ns1 命名空间内设置指标数据收集以及创建警报规则的权限。

6.3. 授予用户权限来为用户定义的项目配置监控

作为集群管理员,您可以将 user-workload-monitoring-config-edit 角色分配给用户。这授予为用户定义的项目配置和管理监控的权限,而不授予他们配置和管理 OpenShift Container Platform 核心监控组件的权限。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 要将角色分配到的用户帐户已存在。
  • 已安装 OpenShift CLI(oc)。

流程

  1. user-workload-monitoring-config-edit 角色分配给 openshift-user-workload-monitoring 项目中的用户:

    $ oc -n openshift-user-workload-monitoring adm policy add-role-to-user \
      user-workload-monitoring-config-edit <user> \
      --role-namespace openshift-user-workload-monitoring
  2. 通过显示相关角色绑定来验证用户是否已正确分配给 user-workload-monitoring-config-edit 角色:

    $ oc describe rolebinding <role_binding_name> -n openshift-user-workload-monitoring

    示例命令

    $ oc describe rolebinding user-workload-monitoring-config-edit -n openshift-user-workload-monitoring

    输出示例

    Name:         user-workload-monitoring-config-edit
    Labels:       <none>
    Annotations:  <none>
    Role:
      Kind:  Role
      Name:  user-workload-monitoring-config-edit
    Subjects:
      Kind  Name  Namespace
      ----  ----  ---------
      User  user1           1

    1
    在本例中,user1 分配给 user-workload-monitoring-config-edit 角色。

6.4. 从集群外部访问自定义应用程序的指标

在使用用户定义的项目监控您自己的服务时,您可以从集群外部查询 Prometheus 指标。使用 thanos-querier 路由从集群外部访问这些数据。

此访问仅支持使用 Bearer 令牌进行身份验证。

先决条件

  • 您已按照用户定义的项目启用监控部署了自己的服务。
  • 您可以使用 cluster-monitoring-view 集群角色登录到帐户,它提供访问 Thanos Querier API 的权限。
  • 已登陆到一个有权获取 Thanos Querier API 路由的帐户。

    注意

    如果您的帐户没有权限获取 Thanos Querier API 路由,集群管理员可以提供路由的 URL。

流程

  1. 运行以下命令,提取身份验证令牌以连接到 Prometheus:

    $ TOKEN=$(oc whoami -t)
  2. 运行以下命令,提取 thanos-querier API 路由 URL:

    $ HOST=$(oc -n openshift-monitoring get route thanos-querier -ojsonpath={.spec.host})
  3. 使用以下命令,将命名空间设置为运行服务的命名空间:

    $ NAMESPACE=ns1
  4. 运行以下命令,在命令行中查询您自己的服务的指标:

    $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/query?" --data-urlencode "query=up{namespace='$NAMESPACE'}"

    输出显示 Prometheus 提取的每个应用程序 pod 的状态:

    输出示例

    {"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"up","endpoint":"web","instance":"10.129.0.46:8080","job":"prometheus-example-app","namespace":"ns1","pod":"prometheus-example-app-68d47c4fb6-jztp2","service":"prometheus-example-app"},"value":[1591881154.748,"1"]}]}}

6.5. 将用户定义的项目从监控中排除

用户工作负载监控中可以排除个别用户定义的项目。为此,只需将 openshift.io/user-monitoring 标签添加到项目的命名空间,值设为 false

流程

  1. 将标签添加到项目命名空间:

    $ oc label namespace my-project 'openshift.io/user-monitoring=false'
  2. 要重新启用监控,请从命名空间中删除该标签:

    $ oc label namespace my-project 'openshift.io/user-monitoring-'
    注意

    如果项目有任何活跃的监控目标,Prometheus 可能需要几分钟时间在添加标签后停止提取它们。

6.6. 为用户定义的项目禁用监控

为用户定义的项目启用监控后,您可以通过在集群监控 ConfigMap 对象中设置 enableUserWorkload: false 来再次禁用它。

注意

另外,您也可以通过删除 enableUserWorkload: true 来为用户定义的项目禁用监控。

流程

  1. 编辑 cluster-monitoring-config ConfigMap 对象:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
    1. data/config.yaml 下将 enableUserWorkload: 设置为 false

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          enableUserWorkload: false
  2. 保存文件以使改变生效。然后会自动禁用对用户定义的项目的监控。
  3. 检查 prometheus-operatorprometheus-user-workloadthanos-ruler-user-workload Pod 是否已在 openshift-user-workload-monitoring 项目中终止。这可能需要片刻时间:

    $ oc -n openshift-user-workload-monitoring get pod

    输出示例

    No resources found in openshift-user-workload-monitoring project.

注意

在禁用了对用户定义的项目的监控时,openshift-user-workload-monitoring 项目中的 user-workload-config ConfigMap 对象不会被自动删除。这是为了保留您可能已在 ConfigMap 中创建的任何自定义配置。

6.7. 后续步骤

第 7 章 为用户定义的项目启用警报路由

在 OpenShift Container Platform 4.15 中,集群管理员可以为用户定义的项目启用警报路由。这个过程由两个常规步骤组成:

  • 为用户定义的项目启用警报路由,以使用默认平台 Alertmanager 实例,或只为用户定义的项目启用单独的 Alertmanager 实例。
  • 授予用户权限来为用户定义的项目配置警报路由。

完成这些步骤后,开发人员和其他用户可以为用户定义的项目配置自定义警报和警报路由。

7.1. 了解用户定义的项目的警报路由

作为集群管理员,您可以为用户定义的项目启用警报路由。使用此功能,您可以允许用户使用 alert-routing-edit 角色的用户为用户定义的项目配置警报通知路由和接收器。这些通知由默认的 Alertmanager 实例路由,如果启用,则为专用于用户定义的监控的可选 Alertmanager 实例。

然后,用户可以通过为用户定义的项目创建或编辑 AlertmanagerConfig 对象来创建和配置用户定义的警报路由,而无需管理员的帮助。

用户为用户定义的项目定义了警报路由后,用户定义的警报通知会路由如下:

  • 如果使用默认平台 Alertmanager 实例,到 openshift-monitoring 命名空间中的 alertmanager-main pod。
  • 如果您为用户定义的项目启用了一个单独的 Alertmanager 实例,到 openshift-user-workload-monitoring 命名空间中的 alertmanager-user-workload Pod。
注意

以下是用户定义的项目的警报路由的限制:

  • 对于用户定义的警报规则,用户定义的路由范围到定义资源的命名空间。例如,命名空间 ns1 中的路由配置仅适用于同一命名空间中的 PrometheusRules 资源。
  • 当命名空间不包括在用户定义的监控中时,命名空间中的 AlertmanagerConfig 资源将成为 Alertmanager 配置的一部分。

7.2. 为用户定义的警报路由启用平台 Alertmanager 实例

您可以允许用户创建使用 Alertmanager 主平台实例的用户定义警报路由配置。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 cluster-monitoring-config ConfigMap 对象:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml 下添加 alertmanagerMain 部分中的 enableUserAlertmanagerConfig: true

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          enableUserAlertmanagerConfig: true 1
    1
    enableUserAlertmanagerConfig 值设置为 true,以便用户创建使用 Alertmanager 主平台实例的用户定义警报路由配置。
  3. 保存文件以使改变生效。新的配置会被自动应用。

7.3. 为用户定义的警报路由启用一个单独的 Alertmanager 实例

在一些集群中,您可能想要为用户定义的项目部署专用 Alertmanager 实例,这有助于降低默认平台 Alertmanager 实例的负载,并更好地将用户定义的警报与默认平台警报分开。在这些情况下,您可以选择性地启用一个单独的 Alertmanager 实例,以仅为用户定义的项目发送警报。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 您已为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 user-workload-monitoring-config ConfigMap 对象:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. data/config.yaml 下,添加 alertmanager 部分的 enabled: trueenableAlertmanagerConfig: true

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        alertmanager:
          enabled: true 1
          enableAlertmanagerConfig: true 2
    1
    enabled 值设为 true,为集群中的用户定义的项目启用 Alertmanager 专用实例。将值设为 false 或省略键可完全为用户定义的项目禁用 Alertmanager。如果将此值设置为 false,或者如果省略了密钥,则用户定义的警报会路由到默认平台 Alertmanager 实例。
    2
    enableAlertmanagerConfig 值设置为 true,以便用户使用 AlertmanagerConfig 对象定义自己的警报路由配置。
  3. 保存文件以使改变生效。用于用户定义的项目的 Alertmanager 专用实例会自动启动。

验证

  • 验证 user-workload Alertmanager 实例是否已启动:

    # oc -n openshift-user-workload-monitoring get alertmanager

    输出示例

    NAME            VERSION   REPLICAS   AGE
    user-workload   0.24.0    2          100s

7.4. 授予用户权限来为用户定义的项目配置警报路由

您可以授予用户权限来为用户定义的项目配置警报路由。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 您已为用户定义的项目启用了监控。
  • 要将角色分配到的用户帐户已存在。
  • 已安装 OpenShift CLI(oc)。

流程

  • alert-routing-edit 集群角色分配给用户定义的项目中的用户:

    $ oc -n <namespace> adm policy add-role-to-user alert-routing-edit <user> 1
    1
    对于 <namespace>,替换用户定义的项目的命名空间,如 ns1。对于 <user>,替换您要为其分配该角色的帐户的用户名。

7.5. 后续步骤

第 8 章 管理指标

您可以收集指标,以监控集群组件和您自己的工作负载的表现情况。

8.1. 了解指标

在 OpenShift Container Platform 4.15 中,集群组件的监控方式是提取通过服务端点公开的指标。您还可以为用户定义的项目配置指标集合。借助指标,您可以监控集群组件和您自己的工作负载的表现情况。

您可以通过在应用程序级别使用 Prometheus 客户端库来定义您要为您自己的工作负载提供的指标。

在 OpenShift Container Platform 中,指标通过 /metrics 规范名称下的 HTTP 服务端点公开。您可以通过针对 http://<endpoint>/metrics 运行 curl 查询来列出服务的所有可用指标。例如,您可以向 prometheus-example-app 示例应用程序公开路由,然后运行以下命令来查看其所有可用指标:

$ curl http://<example_app_endpoint>/metrics

输出示例

# HELP http_requests_total Count of all HTTP requests
# TYPE http_requests_total counter
http_requests_total{code="200",method="get"} 4
http_requests_total{code="404",method="get"} 2
# HELP version Version information about this binary
# TYPE version gauge
version{version="v0.1.0"} 1

8.2. 为用户定义的项目设置指标集合

您可以创建一个 ServiceMonitor 资源,从用户定义的项目中的服务端点提取指标。这假设您的应用程序使用 Prometheus 客户端库向 /metrics 规范名称公开指标。

本节介绍了如何在用户定义的项目中部署示例服务,然后创建一个 ServiceMonitor 资源来定义应该如何监控该服务。

8.2.1. 部署示例服务

要为用户定义的项目中服务测试监控,您可以部署示例服务。

流程

  1. 为服务配置创建 YAML 文件。在本例中,该文件名为 prometheus-example-app.yaml
  2. 在该文件中添加以下部署和服务配置详情:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: ns1
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: prometheus-example-app
      name: prometheus-example-app
      namespace: ns1
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: prometheus-example-app
      template:
        metadata:
          labels:
            app: prometheus-example-app
        spec:
          containers:
          - image: ghcr.io/rhobs/prometheus-example-app:0.4.2
            imagePullPolicy: IfNotPresent
            name: prometheus-example-app
    ---
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: prometheus-example-app
      name: prometheus-example-app
      namespace: ns1
    spec:
      ports:
      - port: 8080
        protocol: TCP
        targetPort: 8080
        name: web
      selector:
        app: prometheus-example-app
      type: ClusterIP

    此配置会在用户定义的 ns1 项目中部署名为 prometheus-example-app 的服务。此服务会公开自定义 version 指标。

  3. 将配置应用到集群:

    $ oc apply -f prometheus-example-app.yaml

    部署该服务需要一些时间。

  4. 您可以检查该 Pod 是否正在运行:

    $ oc -n ns1 get pod

    输出示例

    NAME                                      READY     STATUS    RESTARTS   AGE
    prometheus-example-app-7857545cb7-sbgwq   1/1       Running   0          81m

8.2.2. 指定如何监控服务

要使用服务公开的指标,需要将 OpenShift Container Platform 监控配置为从 /metrics 端点中提取指标。您可以使用一个 ServiceMonitor 自定义资源定义(CRD)应该如何监控服务,或使用一个 PodMonitor CRD 指定应该如何监控 pod。前者需要 Service 对象,而后者则不需要,允许 Prometheus 直接从 Pod 公开的指标端点中提取指标。

此流程演示了如何为用户定义的项目中的服务创建 ServiceMonitor 资源。

先决条件

  • 您可以使用具有 cluster-admin 集群角色或 monitoring-edit 集群角色的用户访问集群。
  • 您已为用户定义的项目启用了监控。
  • 在本例中,您已在 ns1 项目中部署了 prometheus-example-app 示例服务。

    注意

    prometheus-example-app 示例服务不支持 TLS 身份验证。

流程

  1. 创建名为 example-app-service-monitor.yaml 的新 YAML 配置文件。
  2. ServiceMonitor 资源添加到 YAML 文件中。以下示例创建一个名为 prometheus-example-monitor 的服务监控器,用于提取 ns1 命名空间中的 prometheus-example-app 服务公开的指标:

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: prometheus-example-monitor
      namespace: ns1 1
    spec:
      endpoints:
      - interval: 30s
        port: web 2
        scheme: http
      selector: 3
        matchLabels:
          app: prometheus-example-app
    1
    指定服务运行的用户定义的命名空间。
    2
    指定要由 Prometheus 提取的端点端口。
    3
    配置选择器,根据其元数据标签匹配您的服务。
    注意

    用户定义的命名空间中的 ServiceMonitor 资源只能发现同一命名空间中的服务。也就是说,ServiceMonitor 资源的 namespaceSelector 字段总是被忽略。

  3. 将配置应用到集群:

    $ oc apply -f example-app-service-monitor.yaml

    部署 ServiceMonitor 资源需要一些时间。

  4. 验证 ServiceMonitor 资源是否正在运行:

    $ oc -n <namespace> get servicemonitor

    输出示例

    NAME                         AGE
    prometheus-example-monitor   81m

8.2.3. 服务端点身份验证设置示例

您可以使用 ServiceMonitorPodMonitor 自定义资源定义(CRD) 为用户定义的项目监控配置服务端点身份验证。

以下示例显示了 ServiceMonitor 资源的不同身份验证设置。每个示例演示了如何配置包含身份验证凭据和其他相关设置的对应 Secret 对象。

8.2.3.1. 使用 bearer 令牌的 YAML 身份验证示例

以下示例显示了 ns1 命名空间中名为 example-bearer-authSecret 对象的 bearer 令牌设置:

bearer 令牌 secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: example-bearer-auth
  namespace: ns1
stringData:
  token: <authentication_token> 1

1
指定身份验证令牌。

以下示例显示了 ServiceMonitor CRD 的 bearer 令牌身份验证设置。这个示例使用名为 example-bearer-authSecret 对象:

bearer 令牌身份验证设置示例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1
spec:
  endpoints:
  - authorization:
      credentials:
        key: token 1
        name: example-bearer-auth 2
    port: web
  selector:
    matchLabels:
      app: prometheus-example-app

1
在指定的 Secret 对象中包含身份验证令牌的密钥。
2
包含身份验证凭据的 Secret 对象的名称。
重要

不要使用 bearerTokenFile 来配置 bearer 令牌。如果使用 bearerTokenFile 配置,ServiceMonitor 资源将被拒绝。

8.2.3.2. 用于基本身份验证的 YAML 示例

以下示例显示了 ns1 命名空间中名为 example-basic-authSecret 对象基本身份验证设置:

基本身份验证 secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: example-basic-auth
  namespace: ns1
stringData:
  user: <basic_username> 1
  password: <basic_password>  2

1
指定用于身份验证的用户名。
2
指定用于身份验证的密码。

以下示例显示了 ServiceMonitor CRD 的基本身份验证设置。这个示例使用名为 example-basic-authSecret 对象:

基本身份验证设置示例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1
spec:
  endpoints:
  - basicAuth:
      username:
        key: user 1
        name: example-basic-auth 2
      password:
        key: password 3
        name: example-basic-auth 4
    port: web
  selector:
    matchLabels:
      app: prometheus-example-app

1
在指定的 Secret 对象中包含用户名的密钥。
2 4
包含基本身份验证的 Secret 对象的名称。
3
在指定 Secret 对象中包含密码的密钥。

8.2.3.3. 使用 OAuth 2.0 的 YAML 身份验证示例

以下示例显示了 ns1 命名空间中名为 example-oauth2Secret 对象的 OAuth 2.0 设置:

OAuth 2.0 secret 示例

apiVersion: v1
kind: Secret
metadata:
  name: example-oauth2
  namespace: ns1
stringData:
  id: <oauth2_id> 1
  secret: <oauth2_secret> 2

1
指定 Oauth 2.0 ID。
2
指定 Oauth 2.0 secret。

以下示例显示了 ServiceMonitor CRD 的 OAuth 2.0 身份验证设置。这个示例使用名为 example-oauth2Secret 对象:

OAuth 2.0 身份验证设置示例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1
spec:
  endpoints:
  - oauth2:
      clientId:
        secret:
          key: id 1
          name: example-oauth2 2
      clientSecret:
        key: secret 3
        name: example-oauth2 4
      tokenUrl: https://example.com/oauth2/token 5
    port: web
  selector:
    matchLabels:
      app: prometheus-example-app

1
在指定 Secret 对象中包含 OAuth 2.0 ID 的密钥。
2 4
包含 OAuth 2.0 凭证的 Secret 对象的名称。
3
在指定 Secret 对象中包含 OAuth 2.0 secret 的密钥。
5
用于通过指定的 clientIdclientSecret 获取令牌的 URL。

8.3. 查看可用指标列表

作为集群管理员或具有所有项目查看权限的用户,您可以查看集群中可用的指标列表,并以 JSON 格式输出列表。

先决条件

  • 您是一个集群管理员,或者您可以使用具有 cluster-monitoring-view 集群角色的用户访问集群。
  • 已安装 OpenShift Container Platform CLI (oc)。
  • 您已获取 Thanos Querier 的 OpenShift Container Platform API 路由。
  • 您可以使用 oc whoami -t 命令获取 bearer 令牌。

    重要

    您只能使用 bearer 令牌身份验证来访问 Thanos Querier API 路由。

流程

  1. 如果您还没有为 Thanos Querier 获取 OpenShift Container Platform API 路由,请运行以下命令:

    $ oc get routes -n openshift-monitoring thanos-querier -o jsonpath='{.status.ingress[0].host}'
  2. 运行以下命令,以 JSON 格式从 Thanos Querier API 路由检索指标列表。此命令使用 oc 通过 bearer 令牌进行身份验证。

    $ curl -k -H "Authorization: Bearer $(oc whoami -t)" https://<thanos_querier_route>/api/v1/metadata 1
    1
    <thanos_querier_route> 替换为 Thanos Querier 的 OpenShift Container Platform API 路由。

8.4. 查询指标

OpenShift Container Platform 监控仪表板可供您运行 Prometheus Query Language (PromQL) 查询来查看图表中呈现的指标。此功能提供有关集群以及要监控的任何用户定义工作负载的状态信息。

作为集群管理员,您可以查询所有 OpenShift Container Platform 核心项目和用户定义的项目的指标。

作为开发者,您必须在查询指标时指定项目名称。您必须具有所需权限才能查看所选项目的指标。

8.4.1. 以集群管理员身份查询所有项目的指标

作为集群管理员,或具有所有项目的查看权限的用户,您可以在 Metrics UI 中访问所有 OpenShift Container Platform 默认项目和用户定义的项目的指标。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群,或者具有所有项目的查看权限。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 从 OpenShift Container Platform Web 控制台中的 Administrator 视角,选择 ObserveMetrics
  2. 要添加一个或多个查询,请执行以下操作之一:

    选项描述

    创建自定义查询。

    将 Prometheus Query Language (PromQL) 查询添加到 Expression 字段中。

    当您输入 PromQL 表达式时,自动完成建议会出现在下拉列表中。这些建议包括功能、指标、标签和时间令牌。您可以使用键盘箭头选择其中一项建议的项目,然后按 Enter 将项目添加到您的表达式中。您还可以将鼠标指针移到建议的项目上,以查看该项目的简短描述。

    添加多个查询。

    选择 Add query

    复制现有的查询。

    选择查询旁边的 Options 菜单 kebab ,然后选择 Duplicate 查询

    禁用查询正在运行。

    选择查询旁边的 Options 菜单 kebab 并选择 Disable query

  3. 要运行您创建的查询,请选择 Run queries。图表中会直观呈现查询的指标。如果查询无效,则 UI 会显示错误消息。

    注意

    如果查询对大量数据进行运算,这可能会在绘制时序图时造成浏览器超时或过载。要避免这种情况,请选择 Hide graph 并且仅使用指标表来校准查询。然后,在找到可行的查询后,启用图表来绘制图形。

    注意

    默认情况下,查询表会显示一个展开的视图,列出每个指标及其当前值。您可以选择 ˅ 来最小化查询的展开视图。

  4. 可选:页面 URL 现在包含您运行的查询。要在以后再次使用这一组查询,请保存这个 URL。
  5. 探索视觉化指标。最初,图表中显示所有启用的查询中的所有指标。您可以通过执行以下操作来选择显示哪些指标:

    选项描述

    隐藏查询中的所有指标。

    点查询的 Options 菜单 kebab 并点 Hide all series

    隐藏特定指标。

    前往查询表,再点指标名称旁边的带颜色的方格。

    放大图表并更改时间范围。

    任一:

    • 点击图表并在水平方向上拖动,以可视化方式选择时间范围。
    • 使用左上角的菜单来选择时间范围。

    重置时间范围。

    选择 Reset zoom

    在特定时间点显示所有查询的输出。

    将鼠标光标悬停在图表上。弹出框中会显示查询输出。

    隐藏图表。

    选择 Hide graph

其他资源

8.4.2. 以开发者身份查询用户定义的项目的指标

您可以以开发者或具有项目查看权限的用户身份访问用户定义项目的指标。

Developer 视角中, Metrics UI 包括所选项目的一些预定义 CPU、内存、带宽和网络数据包查询。您还可以对项目的 CPU、内存、带宽、网络数据包和应用程序指标运行自定义 Prometheus Query Language (PromQL) 查询。

注意

开发者只能使用 Developer 视角,而不能使用 Administrator 视角。作为开发者,您一次只能查询一个项目的指标。

先决条件

  • 对于您要查看指标的项目,您可以作为开发者或具有查看权限的用户访问集群。
  • 您已为用户定义的项目启用了监控。
  • 您已在用户定义的项目中部署了服务。
  • 您已为该服务创建了 ServiceMonitor 自定义资源定义(CRD),以定义如何监控该服务。

流程

  1. 在 OpenShift Container Platform web 控制台中的 Developer 视角中,选择 ObserveMetrics
  2. Project: 列表中选择您要查看指标的项目。
  3. Select query 列表中选择查询,或者通过选择 Show PromQL 根据所选查询创建自定义 PromQL 查询。图表中会直观呈现查询的指标。

    注意

    在 Developer 视角中,您一次只能运行一个查询。

  4. 通过执行以下操作来探索视觉化的指标:

    选项描述

    放大图表并更改时间范围。

    任一:

    • 点击图表并在水平方向上拖动,以可视化方式选择时间范围。
    • 使用左上角的菜单来选择时间范围。

    重置时间范围。

    选择 Reset zoom

    在特定时间点显示所有查询的输出。

    将鼠标光标悬停在图表上。查询输出会出现在弹出窗口中。

其他资源

8.5. 获取有关指标目标的详细信息

在 OpenShift Container Platform Web 控制台的 Administrator 视角中,您可以使用 Metrics Targets 页面查看、搜索和过滤当前用于提取的端点,这有助于识别和排除问题。例如,您可以查看目标端点的当前状态,以查看 OpenShift Container Platform Monitoring 无法从目标组件中提取指标。

Metrics Targets 页面显示默认 OpenShift Container Platform 项目和用户定义的项目的目标。

先决条件

  • 您可以访问集群,作为您要查看指标目标的项目的管理员。

流程

  1. Administrator 视角中,选择 ObserveTargets。此时会打开 Metrics targets 页面,其中包含为指标提取的所有服务端点目标的列表。

    本页显示了 OpenShift Container Platform 默认项目和用户定义的项目的目标的详细信息。本页列出了每个目标的以下信息:

    • 正在提取的服务端点 URL
    • 被监控的 ServiceMonitor 组件
    • 目标的 updown 状态
    • 命名空间
    • 最后提取的时间
    • 最后一次提取持续的时间
  2. 可选:指标目标列表可能比较长。要查找特定目标,请执行以下操作之一:

    选项描述

    根据状态和源过滤目标。

    Filter 列表中选择过滤。

    可用的过滤选项如下:

    • Status 过滤器:

      • Up。目标当前已启动,正在主动抓取指标。
      • Down。目标当前已停机,没有提取指标。
    • Source 过滤器:

      • Platform。平台级别的目标仅与 AWS 默认项目的 Red Hat OpenShift Service 相关。这些项目提供 Red Hat OpenShift Service on AWS 核心功能。
      • User。用户目标与用户定义的项目相关。这些项目是用户创建的,可以进行自定义。

    根据名称或标签搜索目标。

    在搜索框旁边的 TextLabel 字段中输入搜索词。

    对目标进行排序。

    点一个或多个 Endpoint Status,Namespace,Last Scrape, 和 Scrape Duration 列标头。

  3. 单击目标的 Endpoint 列中的 URL,以导航到其 Target 详情页面。本页提供有关目标的信息,包括:

    • 为指标提取的端点 URL
    • 目标的当前 UpDown 状态
    • 到命名空间的链接
    • 到 ServiceMonitor 详情的链接
    • 附加到目标的标签
    • 为指标提取目标的最长时间

第 9 章 管理警报

在 OpenShift Container Platform 4.15 中,您可以通过 Alerting UI 管理警报、静默和警报规则。

  • 警报规则。警报规则包含一组概述集群中特定状态的条件。当这些条件满足时会触发警报。可为警报规则分配一个严重性来定义警报的路由方式。
  • 警报。当警报规则中定义的条件为满足时会触发警报。警报提供一条通知,说明一组情况在 OpenShift Container Platform 集群中显而易见。
  • 静默。可对警报应用静默,以防止在警报条件满足时发送通知。在您着手处理根本问题的同时,您可在初始通知后将警报静音。
注意

Alerting UI 中可用的警报、静默和警报规则与您可访问的项目相关。例如,如果您以具有 cluster-admin 角色的用户身份登录,您可以访问所有警报、静默和警报规则。

如果您是非管理员用户,如果您被分配了以下用户角色,您可以创建和静默警报:

  • cluster-monitoring-view 集群角色,允许您访问 Alertmanager
  • monitoring-alertmanager-edit 角色,允许您在 web 控制台的 Administrator 视角中创建和静默警报
  • monitoring-rules-edit 集群角色,允许您在 web 控制台的 Developer 视角中创建和静默警报。

9.1. 在 Administrator 和 Developer 视角中访问 Alerting UI

Alerting UI 可通过 OpenShift Container Platform Web 控制台的 Administrator 视角和 Developer 视角访问。

  • Administrator 视角中,进入 ObserveAlerting。此视角中的 Alerting UI 中的三个主要页面是 AlertsSilencesAlerting 规则 页面。
  • Developer 视角中,进入 Observe<project_name>Alerts。在这个视角中,警报、静默和警报规则都通过 Alerts 页面管理。Alerts 页面中显示的结果特定于所选项目。
注意

Developer 视角中,您可以从可在 Project: <project_name> 列表中访问的核心 OpenShift Container Platform 和用户定义的项目中选择。但是,如果您没有以集群管理员身份登录,则不会显示与 OpenShift Container Platform 核心项目相关的警报、静默和警报规则。

9.2. 搜索和过滤警报、静默和警报规则

您可以过滤 Alerting UI 中显示的警报、静默和警报规则。本节介绍每个可用的过滤选项。

了解警报过滤器

Administrator 视角中,Alerting UI 中的 Alerts 页面针对与 OpenShift Container Platform 默认项目和用户定义的项目相关的警报提供了详细信息。该页面包括每个警报的严重性、状态和来源摘要。另外还会显示警报进入其当前状态的时间。

您可以按警报状态、严重性和来源进行过滤。默认情况下,只会显示处于 Firing 状态的 Platform 警报。下面描述了每个警报过滤选项:

  • State 过滤器:

    • Firing。警报正在触发,因为满足警报条件,且可选的 for 持续时间已过。当条件保持 true 时,警报将继续触发。
    • Pending。该警报处于活跃状态,但正在等待警报规则中指定的持续时间,然后再触发警报。
    • Silenced。现在,警报在定义的时间段内处于静默状态。静默会根据您定义的一组标签选择器临时将警报静音。对于与所有列出的值或正则表达式匹配的警报,不会发送通知。
  • Severity 过滤器:

    • Critical。触发了警报的条件可能会产生重大影响。该警报在触发时需要立即关注,并且通常会传给个人或关键响应团队。
    • Warning。该警报针对可能需要注意的事件提供警告通知,以防止问题的发生。警告通常会路由到一个问题单系统进行非即时的审阅。
    • Info。该警报仅用于提供信息。
    • None。该警报没有定义的严重性。
    • 您还可以针对与用户定义的项目相关的警报创建自定义严重性定义。
  • Source 过滤器:

    • Platform。平台级别的警报仅与 OpenShift Container Platform 默认项目相关。这些项目提供 OpenShift Container Platform 核心功能。
    • User。用户警报与用户定义的项目相关。这些警报是用户创建的,并可自定义。用户定义的工作负载监控可在安装后启用,以便您观察自己的工作负载。

了解静默过滤器

Administrator 视角中,Alerting UI 中的 Silences 页面针对应用到 OpenShift Container Platform 默认项目和用户定义项目中的警报的静默提供了详细信息。该页面包括每个静默的状态以及静默结束时间的摘要。

您可以按静默状态进行过滤。默认情况下,仅显示 ActivePending 静默。下面描述了每个静默状态过滤器选项:

  • State 过滤器:

    • Active。静默处于活跃状态,在静默到期前,警报将静音。
    • Pending。静默已被调度,但还没有激活。
    • Expired。静默已过期,如果满足警报条件,将发送通知。

了解警报规则过滤器

Administrator 视角中,Alerting UI 中的 Alerts Rules 页面针对与 OpenShift Container Platform 默认项目和用户定义的项目相关的警报规则提供了详细信息。该页面包括每个警报规则的状态、严重性和来源摘要。

您可以按警报状态、严重性和来源过滤警报规则。默认情况下,只会显示 Platform 警报规则。下面描述了每个警报规则过滤选项:

  • 警报状态 过滤器:

    • Firing。警报正在触发,因为满足警报条件,且可选的 for 持续时间已过。当条件保持 true 时,警报将继续触发。
    • Pending。该警报处于活跃状态,但正在等待警报规则中指定的持续时间,然后再触发警报。
    • Silenced。现在,警报在定义的时间段内处于静默状态。静默会根据您定义的一组标签选择器临时将警报静音。对于与所有列出的值或正则表达式匹配的警报,不会发送通知。
    • Not Firing。警报未触发。
  • Severity 过滤器:

    • Critical。警报规则中定义的条件可能会产生重大影响。如果满足这些条件,需要立即关注。与该规则相关的警报通常会传给个人或关键响应团队。
    • Warning。警报规则中定义的条件可能需要注意,以防止问题的发生。与该规则相关的警报通常会路由到一个问题单系统进行非即时的审阅。
    • Info。警报规则仅提供信息警报。
    • None。该警报规则没有定义的严重性。
    • 您还可以针对与用户定义的项目相关的警报规则创建自定义严重性定义。
  • Source 过滤器:

    • Platform。平台级别的警报规则仅与 OpenShift Container Platform 默认项目相关。这些项目提供 OpenShift Container Platform 核心功能。
    • User。用户定义的工作负载警报规则与用户定义的项目相关。这些警报规则是用户创建的,并可自定义。用户定义的工作负载监控可在安装后启用,以便您观察自己的工作负载。

在 Developer 视角中搜索和过滤警报、静默和警报规则

Developer 视角中,Alerting UI 中的 Alerts 页面提供了与所选项目相关的警报和静默的组合视图。对于每个显示的警报,都提供了相关警报规则的链接。

在该视图中,您可以按警报状态和严重性进行过滤。默认情况下,如果您有访问所选项目的权限,则会显示项目中的所有警报。这些过滤器与针对 Administrator 视角描述的过滤器相同。

9.3. 获取关于警报、静默和警报规则的信息

Alerting UI 提供有关警报及其相关警报规则和静默的详细信息。

先决条件

  • 对于您要查看警告的项目,您可以作为开发者或具有查看权限的用户访问集群。

流程

要在 Administrator 视角中获取有关警报的信息

  1. 打开 OpenShift Container Platform Web 控制台,并导航至 ObserveAlertingAlerts 页面。
  2. 可选:使用搜索列表中的 Name 字段按名称搜索警报。
  3. 可选:通过选择 Filter 列表中的过滤器来按状态、严重性和来源过滤警报。
  4. 可选:点击 NameSeverityStateSource 列标题中的一个或多个标题对警报进行排序。
  5. 点警报的名称查看其 Alert details 页面。该页面包含一个说明警报时间序列数据的图形。它还提供有关警报的以下信息:

    • 警报的描述
    • 与警报关联的消息
    • 附加到警报的标签
    • 其相关警报规则的链接
    • 警报的静默(如果存在)

要在 Administrator 视角中获取有关静默的信息

  1. 进入 ObserveAlertingSilences 页面。
  2. 可选:使用 Search by name 字段按名称过滤静默。
  3. 可选:通过选择 Filter 列表中的过滤器来按状态过滤静默。默认情况下会应用 ActivePending 过滤器。
  4. 可选:点一个或多个 NameFiring AlertsStateCreator 栏上面的标头来对静默进行排序。
  5. 选择静默的名称来查看其 Silence 详情页面。该页面包括以下详情:

    • 警报指定条件
    • 开始时间
    • 结束时间
    • 静默状态
    • 触发警报的数目和列表

要在 Administrator 视角中获取有关警报规则的信息

  1. 进入 ObserveAlertingAlerting rules 页面。
  2. 可选:通过选择 Filter 列表中的过滤器来按状态、严重性和来源过滤警报规则。
  3. 可选:点 Name,Severity,Alert state, 和 Source 列标题中的一个或多个标题对警报规则进行排序。
  4. 选择警报规则的名称来查看其 Alerting 规则详情页面。该页面提供有关警报规则的以下详情:

    • 警报规则名称、严重性和描述。
    • 定义触发警报的条件的表达式。
    • 触发警报的条件应满足的时间。
    • 受警报规则约束的各个警报的图形,其中显示了触发该警报的值
    • 受警报规则约束的所有警报的列表

要在 Developer 视角中获取有关警报、静默和警报规则的信息

  1. 进入 Observe → < project_name>Alerts 页面。
  2. 查看警报、静默或警报规则的详情:

    • 可以通过在警报名称旁边点大于符号(>)来查看警报详情,然后从列表中选择警报。
    • 可以通过在 Alert details 页面的 Silenced by 部分点静默详情来查看静默详情Silence details 页面包括以下信息:

      • 警报指定条件
      • 开始时间
      • 结束时间
      • 静默状态
      • 触发警报的数目和列表
    • 可以通过在 Alerts 页面中点警报旁的 kebab 菜单来查看 警报规则详情,然后点 View Alerting Rule
注意

Developer 视角中仅显示与所选项目相关的警报、静默和警报规则。

其他资源

9.4. 管理静默

您可以在 AdministratorDeveloper 视角中的 OpenShift Container Platform Web 控制台中为警报创建静默。创建静默后,不会在警报触发时收到有关警报的通知。

当您收到了初始警报通知,并且不希望在解决与这个初始警报相关的底层问题时接收到因为解决相关问题所触发的警报通知,可以创建静默。

在创建静默时,您必须指定它是立即激活,还是稍后激活。您还必须设置静默在多长一段时间后到期。

在创建静默后,您可以查看、编辑这个静默,并可以使其过期。

注意

在创建静默时,它们会在 Alertmanager pod 之间复制。但是,如果您没有为 Alertmanager 配置持久性存储,静默可能会丢失。例如,如果所有 Alertmanager pod 同时重启,会出现这种情况。

其他资源

9.4.1. 静默警报

您可以静默特定的警报或静默与您定义的规格匹配的警报。

先决条件

  • 如果您是集群管理员,可以使用具有 cluster-admin 角色的用户访问集群。
  • 如果您是非管理员用户,您可以使用具有以下用户角色的用户访问集群:

    • cluster-monitoring-view 集群角色,允许您访问 Alertmanager。
    • monitoring-alertmanager-edit 角色,允许您在 web 控制台的 Administrator 视角中创建和静默警报
    • monitoring-rules-edit 集群角色,允许您在 web 控制台的 Developer 视角中创建和静默警报。

流程

Administrator 视角中静默特定警报:

  1. 在 OpenShift Container Platform web 控制台中,进入 ObserveAlertingAlerts
  2. 对于要静默的警报,点 kebab ,选择 Silence alert 打开 Silence alert 页,其中包括了所选警报的默认配置。
  3. 可选:更改静默的默认配置详情。

    注意

    在保存静默前,需要添加一个注释信息。

  4. 要保存静默,点 Silence

要在 Developer 视角中静默特定警报:

  1. 在 OpenShift Container Platform web 控制台中进入 Observe<project_name > → Alerts
  2. 如有必要,通过选择警报名称旁的符号(>)来扩展警报的详情。
  3. 在扩展视图中点警报消息以打开警报的 Alert details 页面。
  4. Silence alert,打开带有警报默认配置的静默警报页。
  5. 可选:更改静默的默认配置详情。

    注意

    在保存静默前,需要添加一个注释信息。

  6. 要保存静默,点 Silence

Administrator 视角中创建静默配置来静默一组警报:

  1. 进入 OpenShift Container Platform Web 控制台中的 ObserveAlertingSilences
  2. Create silence
  3. Create silence 页面中,设置警报的调度、持续时间和标签详情。

    注意

    在保存静默前,需要添加一个注释信息。

  4. 要为与您输入的标签匹配的警报创建静默,请点 Silence

Developer 视角中创建静默配置来静默一组警报:

  1. 进入 OpenShift Container Platform Web 控制台中的 Observe<project_name > → Silences
  2. Create silence
  3. Create silence 页面中,设置警报的持续时间和标签详情。

    注意

    在保存静默前,需要添加一个注释信息。

  4. 要为与您输入的标签匹配的警报创建静默,请点 Silence

9.4.2. 编辑静默

您可以编辑一个静默,这会使现有静默到期,然后创建一个带有相关配置变化的静默。

先决条件

  • 如果您是集群管理员,可以使用具有 cluster-admin 角色的用户访问集群。
  • 如果您是非管理员用户,您可以使用具有以下用户角色的用户访问集群:

    • cluster-monitoring-view 集群角色,允许您访问 Alertmanager。
    • monitoring-alertmanager-edit 角色,允许您在 web 控制台的 Administrator 视角中创建和静默警报
    • monitoring-rules-edit 集群角色,允许您在 web 控制台的 Developer 视角中创建和静默警报。

流程

要在 Administrator 视角中编辑静默:

  1. 进入 ObserveAlertingSilences
  2. 针对您想要修改的静默,点 kebab 并选择 Edit silence

    或者,您可以点 Actions,然后在静默的 Silence details 页面中选择 Edit silence

  3. Edit silence 页面中,进行更改并点 Silence。这样做会使现有静默到期,并创建带有更新的配置。

要在 Developer 视角中编辑静默:

  1. 进入 Observe<project_name>Silences
  2. 针对您想要修改的静默,点 kebab 并选择 Edit silence

    或者,您可以点 Actions,然后在静默的 Silence details 页面中选择 Edit silence

  3. Edit silence 页面中,进行更改并点 Silence。这样做会使现有静默到期,并创建带有更新的配置。

9.4.3. 使静默到期

您可以使单个静默或多个静默到期。使静默过期的效果是,永久取消激活它。

注意

您无法删除已过期、静默的警报。超过 120 小时的过期的静默会被垃圾收集。

先决条件

  • 如果您是集群管理员,可以使用具有 cluster-admin 角色的用户访问集群。
  • 如果您是非管理员用户,您可以使用具有以下用户角色的用户访问集群:

    • cluster-monitoring-view 集群角色,允许您访问 Alertmanager。
    • monitoring-alertmanager-edit 角色,允许您在 web 控制台的 Administrator 视角中创建和静默警报
    • monitoring-rules-edit 集群角色,允许您在 web 控制台的 Developer 视角中创建和静默警报。

流程

要在 Administrator 视角中使静默过期:

  1. 进入 ObserveAlertingSilences
  2. 对于您要过期的静默,选择对应行的复选框。
  3. Expire 1 silence 使一个静默过期,或点 Expire <n> silences 使多个静默过期(其中 <n> 是你选择的静默数)。

    另外,要使单个静默到期,您还可以点 Actions,然后在静默的 Silence details 页面中选择 Expire silence

要在 Developer 视角中使静默到期:

  1. 进入 Observe<project_name>Silences
  2. 对于您要过期的静默,选择对应行的复选框。
  3. Expire 1 silence 使一个静默过期,或点 Expire <n> silences 使多个静默过期(其中 <n> 是你选择的静默数)。

    另外,要使单个静默到期,您还可以点 Actions,然后在静默的 Silence details 页面中选择 Expire silence

9.5. 管理用于核心平台监控的警报规则

OpenShift Container Platform 4.15 监控附带一组用于平台指标的默认警报规则。作为集群管理员,您可以以两种方式自定义这组规则:

  • 通过调整阈值或添加和修改标签来修改现有平台警报规则的设置。例如,您可以将一个警报的 severity 标签从 warning 改为 critical 以帮助您来处理相关的问题。
  • 通过基于 openshift-monitoring 命名空间中的核心平台指标构建查询表达式,定义和添加新的自定义警报规则。

核心平台警报规则考虑

  • 新的警报规则必须基于默认的 OpenShift Container Platform 监控指标。
  • 您必须在 openshift-monitoring 命名空间中创建 AlertingRuleAlertRelabelConfig 对象。
  • 您只能添加和修改警报规则。您无法创建新的记录规则或修改现有的记录规则。
  • 如果您使用 AlertRelabelConfig 对象修改现有平台警报规则,您的修改不会反映在 Prometheus 警报 API 中。因此,任何丢弃的警报仍出现在 OpenShift Container Platform web 控制台中,即使它们不再被转发到 Alertmanager。另外,任何对警报的修改(如更改了 severity 标签)都不会出现在 web 控制台中。

9.5.1. 为核心平台监控优化警报规则的建议

如果您需要自定义核心平台警报规则来满足机构的特定需求,请遵循以下准则,确保自定义规则可以实现预期的目且高效。

  • 使用尽可能少的新规则。仅创建符合您特定要求的规则。通过使用最少的规则数量,您可以在监控环境中创建更易管理且集中的警报系统。
  • 专注于症状而不是原因。创建规则来通知用户症状而不是造成症状的根本原因。这可以确保,在出现相关症状时用户可以获得警报,用户可以调查触发警报的根本原因。使用这个策略,可以显著降低了您需要创建的规则的总数量。
  • 在实施更改之前,规划并评估您的需求。首先,明确哪些症状是重要的,以及在出现这些症状时您希望用户执行哪些操作。然后,评估现有规则,决定是否可以通过修改这些规则来实现您的目的,而不用为每个症状都创建一个新的规则。通过修改现有规则并谨慎创建新规则,可帮助您简化警报系统。
  • 提供明确的警报信息。当您创建警报消息时,包括症状的描述、可能的原因和推荐的操作。包括的信息应该明确、简明,并包括故障排除步骤或更多相关信息的链接。这样做有助于用户快速评估情况并做出适当响应。
  • 包括严重性级别。为您的规则分配严重性级别,以提示用户在出现症状并触发警报时如何响应。例如,将警报严重性级别定为 关键(Critical) 信号,代表相关人员需要马上做出响应。通过定义严重性级别,可以帮助用户决定在收到警报时应如何响应,并确保对紧急的问题马上做出响应

9.5.2. 创建新警报规则

作为集群管理员,您可以根据平台指标创建新的警报规则。这些警报规则根据所选指标的值触发警报。

注意
  • 如果您基于现有平台警报规则创建自定义 AlertingRule 资源,请静默原始警报以避免收到冲突的警报。
  • 为了帮助用户了解警报的影响和原因,请确保您的警报规则包含警报消息和严重性值。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 创建一个名为 example-alerting-rule.yaml 的新 YAML 配置文件。
  2. 向 YAML 文件添加 AlertingRule 资源。以下示例创建一个名为 example 的新警报规则,类似于默认的 Watchdog 警报:

    apiVersion: monitoring.openshift.io/v1
    kind: AlertingRule
    metadata:
      name: example
      namespace: openshift-monitoring 1
    spec:
      groups:
      - name: example-rules
        rules:
        - alert: ExampleAlert 2
          for: 1m 3
          expr: vector(1) 4
          labels:
            severity: warning 5
          annotations:
            message: This is an example alert. 6
    1
    确保命名空间为 openshift-monitoring
    2
    您要创建的警报规则的名称。
    3
    触发警报前条件应为 true 的持续时间。
    4
    定义新规则的 PromQL 查询表达式。
    5
    警报规则分配给警报的严重性。
    6
    与警报关联的消息。
    重要

    您必须在 openshift-monitoring 命名空间中创建 AlertingRule 对象。否则,将不接受警报规则。

  3. 将配置文件应用到集群:

    $ oc apply -f example-alerting-rule.yaml

9.5.3. 修改核心平台警报规则

作为集群管理员,您可以在 Alertmanager 将核心平台警报路由到接收器前修改核心平台警报。例如,您可以更改警报的严重性标签,添加自定义标签,或者从发送到 Alertmanager 中排除警报。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 创建名为 example-modified-alerting-rule.yaml 的新 YAML 配置文件。
  2. 在 YAML 文件中添加 AlertRelabelConfig 资源。以下示例将默认平台 watchdog 警报规则的 severity 设置改为 critical

    apiVersion: monitoring.openshift.io/v1
    kind: AlertRelabelConfig
    metadata:
      name: watchdog
      namespace: openshift-monitoring 1
    spec:
      configs:
      - sourceLabels: [alertname,severity] 2
        regex: "Watchdog;none" 3
        targetLabel: severity 4
        replacement: critical 5
        action: Replace 6
    1
    确保命名空间为 openshift-monitoring
    2
    要修改的值的源标签。
    3
    匹配的 sourceLabels 值的正则表达式。
    4
    要修改的值的目标标签。
    5
    要替换目标标签的新值。
    6
    基于正则表达式匹配替换旧值的重新标记操作。默认操作为 Replace。其他可能的值有 Keep,Drop,HashMod,LabelMap,LabelDrop, LabelKeep
    重要

    您必须在 openshift-monitoring 命名空间中创建 AlertRelabelConfig 对象。否则,警报标签不会改变。

  3. 将配置文件应用到集群:

    $ oc apply -f example-modified-alerting-rule.yaml

其他资源

9.6. 为用户定义的项目管理警报规则

OpenShift Container Platform 监控附带一组默认的警报规则。作为集群管理员,您可以查看默认警报规则。

在 OpenShift Container Platform 4.15 中,您可以在用户定义的项目中创建、查看、编辑和删除警报规则。

警报规则注意事项

  • 默认的警报规则专门用于 OpenShift Container Platform 集群。
  • 有些警报规则特意使用相同的名称。它们发送关于同一事件但具有不同阈值和/或不同严重性的警报。
  • 如果较低严重性警报在较高严重性警报触发的同时触发,禁止规则可防止在这种情况下发送通知。

9.6.1. 为用户定义的项目优化警报

要优化您自己的项目的警报,您可以在创建警报规则时考虑以下建议:

  • 尽可能减少您为项目创建的警报规则数量。创建警报规则来针对会影响您的条件通知您。如果您为不会影响您的条件生成多个警报,则更难以注意到相关警报。
  • 为症状而不是原因创建警报规则。创建警报规则来针对条件通知您,而无论根本原因是什么。然后可以调查原因。如果每个警报规则都只与特定原因相关,则需要更多警报规则。然后,可能会错过一些原因。
  • 在编写警报规则前进行规划。确定对您很重要的症状以及一旦发生您想要采取什么操作。然后为每个症状构建警报规则。
  • 提供明确的警报信息。在警报消息中说明症状和推荐操作。
  • 在警报规则中包含严重性级别。警报的严重性取决于当报告的症状发生时您需要如何做出反应。例如,如果症状需要个人或关键响应团队立即关注,就应该触发关键警报。

其他资源

  • 如需更多有关优化警报的指南,请参阅 Prometheus 警报文档
  • 如需了解有关 OpenShift Container Platform 4.15 监控架构的详细信息,请参阅监控概述

9.6.2. 关于为用户定义的项目创建警报规则

如果您为用户定义的项目创建警报规则,请在定义新规则时请考虑以下关键行为和重要限制:

  • 除了核心平台监控的默认指标外,用户定义的警报规则也可以包括由其自身项目公开的指标。您不能包含其他用户定义的项目的指标。

    例如,ns1 用户定义的项目的警报规则除核心平台指标(如 CPU 和内存指标)外还可以使用 ns1 项目公开的指标。但是,该规则无法包含来自不同 ns2 用户定义的项目的指标。

  • 要缩短延迟并最小化核心平台监控组件的负载,您可以将 openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus 标签添加到规则中。此标签只强制 openshift-user-workload-monitoring 项目中部署的 Prometheus 实例评估警报规则,并防止 Thanos Ruler 实例这样做。

    重要

    如果警报规则具有此标签,则您的警报规则只能使用用户定义的项目公开的这些指标。您基于默认平台指标创建的警报规则可能无法触发警报。

9.6.3. 为用户定义的项目创建警报规则

您可以为用户定义的项目创建警报规则。这些警报规则将根据所选指标的值触发警报。

注意
  • 当创建警报规则时,如果在其他项目中存在具有相同名称的规则,则对其强制使用项目标签。
  • 为了帮助用户了解警报的影响和原因,请确保您的警报规则包含警报消息和严重性值。

先决条件

  • 您已为用户定义的项目启用了监控。
  • 对于您要创建警报规则的项目,您已作为具有 monitoring-rules-edit 集群角色的用户登录。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 为警报规则创建 YAML 文件。在本例中,该文件名为 example-app-alerting-rule.yaml
  2. 向 YAML 文件添加警报规则配置。以下示例创建一个名为 example-alert 的新警报规则。当示例服务公开的 version 指标变为 0 时,警报规则会触发警报:

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: example-alert
      namespace: ns1
    spec:
      groups:
      - name: example
        rules:
        - alert: VersionAlert 1
          for: 1m 2
          expr: version{job="prometheus-example-app"} == 0 3
          labels:
            severity: warning 4
          annotations:
            message: This is an example alert. 5
    1
    您要创建的警报规则的名称。
    2
    触发警报前条件应为 true 的持续时间。
    3
    定义新规则的 PromQL 查询表达式。
    4
    警报规则分配给警报的严重性。
    5
    与警报关联的消息。
  3. 将配置文件应用到集群:

    $ oc apply -f example-app-alerting-rule.yaml

其他资源

  • 如需了解有关 OpenShift Container Platform 4.15 监控架构的详细信息,请参阅监控概述

9.6.4. 访问用户定义的项目的警报规则

要列出用户定义的项目的警报规则,您必须已被分配该项目的 monitoring-rules-view 集群角色。

先决条件

  • 您已为用户定义的项目启用了监控。
  • 您以具有项目的 monitoring-rules-view 集群角色的用户身份登录。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 列出 <project> 中的警报规则:

    $ oc -n <project> get prometheusrule
  2. 要列出警报规则的配置,请运行以下命令:

    $ oc -n <project> get prometheusrule <rule> -o yaml

9.6.5. 在单个视图中列出所有项目的警报规则

作为集群管理员,您可以在单个视图中一起列出 OpenShift Container Platform 核心项目和用户定义的项目的警报规则。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. Administrator 视角中,进入到 ObserveAlertingAlerting rules
  2. Filter 下拉菜单中选择 PlatformUser 来源。

    注意

    默认会选择 Platform 来源。

9.6.6. 为用户定义的项目删除警报规则

您可以为用户定义的项目删除警报规则。

先决条件

  • 您已为用户定义的项目启用了监控。
  • 对于您要创建警报规则的项目,您已作为具有 monitoring-rules-edit 集群角色的用户登录。
  • 已安装 OpenShift CLI(oc)。

流程

  • 要删除 <namespace> 中的规则 <foo>,请运行以下命令:

    $ oc -n <namespace> delete prometheusrule <foo>

其他资源

9.7. 将通知发送到外部系统

在 OpenShift Container Platform 4.15 中,可在 Alerting UI 中查看触发警报。默认不会将警报配置为发送到任何通知系统。您可以将 OpenShift Container Platform 配置为将警报发送到以下类型的接收器:

  • PagerDuty
  • Webhook
  • 电子邮件
  • Slack
  • Microsoft Teams

通过将警报路由到接收器,您可在出现故障时及时向适当的团队发送通知。例如,关键警报需要立即关注,通常会传给个人或关键响应团队。相反,提供非关键警告通知的警报可能会被路由到一个问题单系统进行非即时的审阅。

使用 watchdog 警报检查警报是否工作正常

OpenShift Container Platform 监控功能包含持续触发的 watchdog 警报。Alertmanager 重复向已配置的通知提供程序发送 watchdog 警报通知。此提供程序通常会配置为在其停止收到 watchdog 警报时通知管理员。这种机制可帮助您快速识别 Alertmanager 和通知提供程序之间的任何通信问题。

9.7.1. 配置警报接收器

您可以配置警报接收器,以确保了解集群出现的重要问题。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。

流程

  1. Administrator 视角中,进入 AdministrationCluster SettingsConfigurationAlertmanager

    注意

    或者,您还可以通过 notification drawer 访问同一页面。选择 OpenShift Container Platform Web 控制台右上角的铃铛图标,并在 AlertmanagerReceiverNotConfigured 警报中选择 Configure

  2. 在页面的 Receivers 部分中,点 Create Receiver
  3. Create Receiver 表单中,添加 Receiver Name,然后从列表中选择 Receiver Type
  4. 编辑接收器配置:

    • 对于 PagerDuty 接收器:

      1. 选择集成类型并添加 PagerDuty 集成密钥。
      2. 添加 PagerDuty 安装的 URL。
      3. 如果要编辑客户端和事件详情或严重性规格,请点 Show advanced configuration
    • 对于 Webhook 接收器:

      1. 添加将 HTTP POST 请求发送到的端点。
      2. 如果要编辑将已解析的警报发送给接收器的默认选项,请点 Show advanced configuration
    • 对于电子邮件接收器:

      1. 添加要将通知发送到的电子邮件地址。
      2. 添加 SMTP 配置详情,包括发送通知的地址、用来发送电子邮件的智能主机和端口号、SMTP 服务器的主机名以及验证详情。
      3. 选择是否需要 TLS。
      4. 如果要将默认选项编辑为不向接收器发送已解析的警报,或编辑电子邮件通知正文配置,请点 Show advanced configuration
    • 对于 Slack 接收器:

      1. 添加 Slack Webhook 的 URL。
      2. 添加要将通知发送到的 Slack 频道或用户名。
      3. 如果要将默认选项编辑为不向接收器发送已解析的警报,或编辑图标和用户名配置,请选择 Show advanced configuration。您还可以选择是否查找并链接频道名称和用户名。
  5. 默认情况下,如果触发的警报带有与所有选择器匹配的标签,将被发送到接收器。如果您希望触发的警报在发送到接收器前完全匹配的标签值,请执行以下步骤:

    1. 在表单的 Routing Labels 部分中添加路由标签名称和值。
    2. Add label 来添加更多路由标签。
  6. Create 创建接收器。

9.7.2. 为默认平台警报和用户定义的警报配置不同的警报接收器

您可以为默认平台警报和用户定义的警报配置不同的警报接收器,以确保以下结果:

  • 所有默认平台警报都发送到团队拥有的接收器,以收取这些警报。
  • 所有用户定义的警报都发送到另一个接收器,以便团队只能专注于平台警报。

您可以使用 Cluster Monitoring Operator 添加到所有平台警报的 openshift_io_alert_source="platform" 标签来实现此目的:

  • 使用 openshift_io_alert_source="platform" matcher 来匹配默认平台警报。
  • 使用 openshift_io_alert_source!="platform"'openshift_io_alert_source="" 匹配程序来匹配用户定义的警报。
注意

如果您启用了专用于用户定义的警报的 Alertmanager 实例,则此配置不适用。

9.7.3. 为用户定义的项目创建警报路由

如果您是一个带有 alert-routing-edit 集群角色的非管理员用户,您可以创建或编辑用户定义的项目的警报路由。

先决条件

  • 集群管理员为用户定义的项目启用了监控。
  • 集群管理员为用户定义的项目启用了警报路由。
  • 您以具有您要为其创建警报路由的项目的 alert-routing-edit 集群角色的用户身份登录。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 创建用于警报路由的 YAML 文件。此流程中的示例使用名为 example-app-alert-routing.yaml 的文件。
  2. 在文件中添加 AlertmanagerConfig YAML 定义。例如:

    apiVersion: monitoring.coreos.com/v1beta1
    kind: AlertmanagerConfig
    metadata:
      name: example-routing
      namespace: ns1
    spec:
      route:
        receiver: default
        groupBy: [job]
      receivers:
      - name: default
        webhookConfigs:
        - url: https://example.org/post
    注意

    对于用户定义的警报规则,用户定义的路由范围到定义资源的命名空间。例如,AlertmanagerConfig 对象中为命名空间 ns1 定义的路由配置仅适用于同一命名空间中的 PrometheusRules 资源。

  3. 保存该文件。
  4. 将资源应用到集群:

    $ oc apply -f example-app-alert-routing.yaml

    配置会自动应用到 Alertmanager pod。

9.8. 应用自定义 Alertmanager 配置

您可以通过编辑 Alertmanager 平台实例的 openshift-monitoring 命名空间中的 alertmanager-main secret 来覆盖默认的 Alertmanager 配置。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。

流程

要从 CLI 更改 Alertmanager 配置:

  1. 将当前活跃的 Alertmanager 配置输出到 alertmanager.yaml 文件:

    $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
  2. 编辑 alertmanager.yaml 中的配置:

    global:
      resolve_timeout: 5m
    route:
      group_wait: 30s 1
      group_interval: 5m 2
      repeat_interval: 12h 3
      receiver: default
      routes:
      - matchers:
        - "alertname=Watchdog"
        repeat_interval: 2m
        receiver: watchdog
      - matchers:
        - "service=<your_service>" 4
        routes:
        - matchers:
          - <your_matching_rules> 5
          receiver: <receiver> 6
    receivers:
    - name: default
    - name: watchdog
    - name: <receiver>
    #  <receiver_configuration>
    1
    group_wait 值指定,Alertmanager 在为一组警报发送初始通知前要等待的时间。这个值控制 Alertmanager 在发送通知前为同一组收集初始警报时等待的时间。
    2
    group_interval 值指定 Alertmanager 发送通知添加到已经发送初始通知的一组警报前必须经过的时间。
    3
    repeat_interval 值指定重复警报通知前必须经过的最小时间。如果您希望通知在每个组间隔重复,请将 repeat_interval 值设置为小于 group_interval 的值。但是,重复的通知仍然可能延迟,例如,当某些 Alertmanager pod 重启或重新调度时。
    4
    service 值指定触发警报的服务。
    5
    <your_matching_rules> 值指定目标警报。
    6
    receiver 值指定用于警报的接收器。
    注意

    使用 matchers 键名称来指示警报要与节点匹配的匹配者。不要使用 matchmatch_re 键名称,它们都已弃用,并计划在以后的发行版本中删除。

    另外,如果您定义了禁止规则,请使用 target_matchers 键名称来指示目标匹配者和 source_matchers 键名称来指示源匹配器。不要使用 target_match,target_match_re,source_match, 或 source_match_re 键名称,这些名称已弃用,并计划在以后的发行版本中删除。

    以下 Alertmanager 配置示例将 PagerDuty 配置为警报接收器:

    global:
      resolve_timeout: 5m
    route:
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 12h
      receiver: default
      routes:
      - matchers:
        - "alertname=Watchdog"
        repeat_interval: 2m
        receiver: watchdog
      - matchers:
        - "service=example-app"
        routes:
        - matchers:
          - "severity=critical"
          receiver: team-frontend-page*
    receivers:
    - name: default
    - name: watchdog
    - name: team-frontend-page
      pagerduty_configs:
      - service_key: "_your-key_"

    采用此配置时,由 example-app 服务触发的、严重性为 critical 的警报将使用 team-frontend-page 接收器发送。通常情况下,这些类型的警报会传给个人或关键响应团队。

  3. 应用文件中的新配置:

    $ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-monitoring replace secret --filename=-

要从 OpenShift Container Platform Web 控制台更改 Alertmanager 配置:

  1. 进入 web 控制台的 AdministrationCluster SettingsConfigurationAlertmanagerYAML 页面。
  2. 修改 YAML 配置文件。
  3. 点击 Save

9.9. 将自定义配置应用到 Alertmanager 以进行用户定义的警报路由

如果您已经启用了单独的 Alertmanager 实例,专用于用户定义的警报路由,您可以通过编辑 openshift-user-workload-monitoring 命名空间中的 alertmanager-user-workload secret 来覆盖此 Alertmanager 实例的配置。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 将当前活跃的 Alertmanager 配置输出到 alertmanager.yaml 文件:

    $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
  2. 编辑 alertmanager.yaml 中的配置:

    route:
      receiver: Default
      group_by:
      - name: Default
      routes:
      - matchers:
        - "service = prometheus-example-monitor" 1
        receiver: <receiver> 2
    receivers:
    - name: Default
    - name: <receiver>
    #  <receiver_configuration>
    1
    指定与路由匹配的警报。本例显示具有 service="prometheus-example-monitor" 标签的所有警报。
    2
    指定用于警报组的接收器。
  3. 应用文件中的新配置:

    $ oc -n openshift-user-workload-monitoring create secret generic alertmanager-user-workload --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-user-workload-monitoring replace secret --filename=-

其他资源

9.10. 后续步骤

第 10 章 查看监控仪表板

OpenShift Container Platform 4.15 提供了一组全面的监控仪表板,可帮助您了解集群组件和用户定义的工作负载的状态。

使用 Administrator 视角访问 OpenShift Container Platform 核心组件的仪表板,包括以下项目:

  • API 性能
  • etcd
  • Kubernetes 计算资源
  • Kubernetes 网络资源
  • Prometheus
  • 与集群和节点性能相关的 USE 方法仪表板
  • 节点性能指标

图 10.1. Administrator 视角中的仪表板示例

监控仪表板管理员

使用 Developer 视角访问为所选项目提供以下应用程序指标的 Kubernetes 计算资源仪表板:

  • CPU 用量
  • 内存用量
  • 带宽信息
  • 数据包速率信息

图 10.2. Developer 视角中的仪表板示例

观察仪表板开发人员
注意

Developer 视角中,您一次只能查看一个项目的仪表板。

10.1. 以集群管理员身份查看监控仪表板

Administrator 视角中,您可以查看与 OpenShift Container Platform 集群核心组件相关的仪表板。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。

流程

  1. 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入到 ObserveDashboards
  2. Dashboard 列表中选择一个仪表板。有些仪表板(如 etcdPrometheus 仪表板)在被选中时会生成额外的子菜单。
  3. 可选:在 Time Range 列表中为图形选择一个时间范围。

    • 选择预定义的时间段。
    • 通过选择 Time Range 列表中的 Custom 时间范围 来设置自定义时间范围。

      1. 输入或选择 FromTo date and time。
      2. 单击 Save 以保存自定义时间范围。
  4. 可选:选择一个 Refresh Interval
  5. 将鼠标悬停在仪表板中的每个图形上,以显示具体项目的详细信息。

10.2. 以开发者身份查看监控仪表板

Developer 视角中,您可以查看与所选项目相关的仪表板。您必须具有监控项目的访问权限,才能查看其仪表板信息。

先决条件

  • 您可以使用开发人员或用户访问集群。
  • 有您通过仪表板查看的项目的查看权限。

流程

  1. 在 OpenShift Container Platform web 控制台的 Developer 视角中,导航到 ObserveDashboard
  2. Project: 下拉列表中选择一个项目。
  3. Dashboard 下拉列表中选择一个仪表板,以查看过滤的指标。

    注意

    选择时,所有仪表板会生成额外的子菜单,但 Kubernetes / Compute Resources / Namespace(Pods) 除外。

  4. 可选:在 Time Range 列表中为图形选择一个时间范围。

    • 选择预定义的时间段。
    • 通过选择 Time Range 列表中的 Custom 时间范围 来设置自定义时间范围。

      1. 输入或选择 FromTo date and time。
      2. 单击 Save 以保存自定义时间范围。
  5. 可选:选择一个 Refresh Interval
  6. 将鼠标悬停在仪表板中的每个图形上,以显示特定项目的详细信息。

10.3. 后续步骤

第 11 章 使用 CLI 访问监控 API

在 OpenShift Container Platform 4.15 中,您可以从命令行界面 (CLI) 访问一些监控组件的 Web 服务 API。

重要

在某些情况下,访问 API 端点可能会降低集群的性能和可扩展性,特别是在使用端点来检索、发送或查询大量指标数据时。

要避免这些问题,请遵循以下建议:

  • 避免频繁查询端点。将查询限制为每 30 秒最多一个。
  • 不要尝试通过 Prometheus 的 /federate 端点检索所有指标数据。只有在您要检索有限、聚合的数据集时才会查询。例如,检索每个请求数量少于 1,000 个样本,有助于最大程度降低性能下降的风险。

11.1. 关于访问监控 Web 服务 API

您可以从命令行直接访问以下监控堆栈组件的 Web 服务 API 端点:

  • Prometheus
  • Alertmanager
  • Thanos Ruler
  • Thanos querier
注意

要访问 Thanos Ruler 和 Thanos Querier 服务 API,请求的帐户必须具有命名空间资源的 get 权限,这些资源可通过向帐户授予 cluster-monitoring-view 集群角色来完成。

当您访问监控组件的 Web 服务 API 端点时,请注意以下限制:

  • 您只能使用 Bearer Token 身份验证来访问 API 端点。
  • 您只能访问路由的 /api 路径中的端点。如果您试图在 Web 浏览器中访问 API 端点,则会出现一个 Application is not available 的错误。要在网页浏览器中访问监控功能,请使用 OpenShift Container Platform Web 控制台查看监控仪表板。

其他资源

11.2. 访问监控 Web 服务 API

以下示例演示了如何查询服务 API 接收器以获取核心平台监控中使用的 Alertmanager 服务。您可以使用类似的方法访问核心平台 Prometheus 的 prometheus-k8s 服务,以及 Thanos Ruler 的 thanos-ruler 服务。

先决条件

  • 您已登录到与 openshift-monitoring 命名空间中的 monitoring-alertmanager-edit 角色绑定的帐户。
  • 已登陆到一个有权获取 Alertmanager API 路由的帐户。

    注意

    如果您的帐户没有获取 Alertmanager API 路由的权限,集群管理员可以提供路由的 URL。

流程

  1. 运行以下命令来提取身份验证令牌:

    $ TOKEN=$(oc whoami -t)
  2. 运行以下命令提取 alertmanager-main API 路由 URL:

    $ HOST=$(oc -n openshift-monitoring get route alertmanager-main -ojsonpath={.spec.host})
  3. 运行以下命令,查询 Alertmanager 的服务 API 接收器:

    $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v2/receivers"

11.3. 使用 Prometheus 的联邦端点查询指标

您可以使用 Prometheus 的联邦端点从集群外的网络位置提取平台和用户定义的指标。为此,请通过 OpenShift Container Platform 路由访问集群的 Prometheus /federate 端点。

重要

使用联邦时检索指标数据的延迟。这个延迟可能会影响提取指标的准确性和时间表。

使用联邦端点也可以降低集群的性能和可扩展性,特别是在使用联邦端点来获取大量指标数据时。要避免这些问题,请遵循以下建议:

  • 不要尝试通过 Prometheus 的联邦端点检索所有指标数据。只有在您要检索有限、聚合的数据集时才会查询。例如,检索每个请求数量少于 1,000 个样本,有助于最大程度降低性能下降的风险。
  • 避免频繁查询 Prometheus 的联邦端点。将查询限制为每 30 秒最多一个。

如果您需要在集群外转发大量数据,请使用远程写入。如需更多信息,请参阅配置远程写入存储部分。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-monitoring-view 集群角色的用户,或者获取了对 命名空间 资源具有 get 权限的 bearer 令牌来访问集群。

    注意

    您只能使用 bearer 令牌身份验证来访问 Prometheus 联邦端点。

  • 已登陆到一个有权获取 Prometheus 联邦路由的帐户。

    注意

    如果您的帐户没有获取 Prometheus 联邦路由的权限,集群管理员可以提供路由的 URL。

流程

  1. 运行以下命令来检索 bearer 令牌:

    $ TOKEN=$(oc whoami -t)
  2. 运行以下命令来获取 Prometheus 联邦路由 URL:

    $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s-federate -ojsonpath={.spec.host})
  3. 查询 /federate 路由的指标。以下示例命令 up 指标 :

    $ curl -G -k -H "Authorization: Bearer $TOKEN" https://$HOST/federate --data-urlencode 'match[]=up'

    输出示例

    # TYPE up untyped
    up{apiserver="kube-apiserver",endpoint="https",instance="10.0.143.148:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035322214
    up{apiserver="kube-apiserver",endpoint="https",instance="10.0.148.166:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035338597
    up{apiserver="kube-apiserver",endpoint="https",instance="10.0.173.16:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035343834
    ...

11.4. 从集群外部访问自定义应用程序的指标

在使用用户定义的项目监控您自己的服务时,您可以从集群外部查询 Prometheus 指标。使用 thanos-querier 路由从集群外部访问这些数据。

此访问仅支持使用 Bearer 令牌进行身份验证。

先决条件

  • 您已按照用户定义的项目启用监控部署了自己的服务。
  • 您可以使用 cluster-monitoring-view 集群角色登录到帐户,它提供访问 Thanos Querier API 的权限。
  • 已登陆到一个有权获取 Thanos Querier API 路由的帐户。

    注意

    如果您的帐户没有权限获取 Thanos Querier API 路由,集群管理员可以提供路由的 URL。

流程

  1. 运行以下命令,提取身份验证令牌以连接到 Prometheus:

    $ TOKEN=$(oc whoami -t)
  2. 运行以下命令,提取 thanos-querier API 路由 URL:

    $ HOST=$(oc -n openshift-monitoring get route thanos-querier -ojsonpath={.spec.host})
  3. 使用以下命令,将命名空间设置为运行服务的命名空间:

    $ NAMESPACE=ns1
  4. 运行以下命令,在命令行中查询您自己的服务的指标:

    $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/query?" --data-urlencode "query=up{namespace='$NAMESPACE'}"

    输出显示 Prometheus 提取的每个应用程序 pod 的状态:

    输出示例

    {"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"up","endpoint":"web","instance":"10.129.0.46:8080","job":"prometheus-example-app","namespace":"ns1","pod":"prometheus-example-app-68d47c4fb6-jztp2","service":"prometheus-example-app"},"value":[1591881154.748,"1"]}]}}

11.5. 其他资源

第 12 章 监控问题的故障排除

查找核心平台和用户定义的项目监控常见问题的故障排除步骤。

12.1. 调查用户定义的项目指标不可用的原因

通过 ServiceMonitor 资源,您可以确定如何使用用户定义的项目中的服务公开的指标。如果您创建了 ServiceMonitor 资源,但无法在 Metrics UI 中看到任何对应的指标,请按该流程中所述的步骤操作。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您已为用户定义的项目启用并配置了监控。
  • 您已创建了 ServiceMonitor 资源。

流程

  1. 在服务和 ServiceMonitor 资源配置中检查对应的标签是否匹配

    1. 获取服务中定义的标签。以下示例在 ns1 项目中查询 prometheus-example-app 服务:

      $ oc -n ns1 get service prometheus-example-app -o yaml

      输出示例

        labels:
          app: prometheus-example-app

    2. 检查 ServiceMonitor 资源配置中的 matchLabels 定义是否与上一步中的标签输出匹配。以下示例在 ns1 项目中查询 prometheus-example-monitor 服务监控器:

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      输出示例

      apiVersion: v1
      kind: ServiceMonitor
      metadata:
        name: prometheus-example-monitor
        namespace: ns1
      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app

      注意

      您可以作为具有项目查看权限的开发者检查服务和 ServiceMonitor 资源标签。

  2. openshift-user-workload-monitoring 项目中检查 Prometheus Operator 的日志

    1. 列出 openshift-user-workload-monitoring 项目中的 Pod:

      $ oc -n openshift-user-workload-monitoring get pods

      输出示例

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

    2. prometheus-operator Pod 中的 prometheus-operator 容器获取日志。在以下示例中,Pod 名为 prometheus-operator-776fcbbd56-2nbfm

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      如果服务监控器出现问题,日志可能包含类似本例的错误:

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload
  3. 在 OpenShift Container Platform Web 控制台 UI 中的 Metrics 目标 页面中查看您的端点的目标状态

    1. 登录到 OpenShift Container Platform web 控制台,进入 Administrator 视角中的 ObserveTargets
    2. 在列表中找到指标端点,并在 Status 列中查看目标的状态。
    3. 如果 StatusDown,点端点的 URL 查看该指标目标的 Target Details 页面的更多信息。
  4. openshift-user-workload-monitoring 项目中为 Prometheus Operator 配置 debug 级别的日志记录

    1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    2. data/config.yaml 下为 prometheusOperator 添加 logLevel: debug,将日志级别设置为 debug

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug
      # ...
    3. 保存文件以使改变生效。受影响的 prometheus-operator Pod 会自动重新部署。
    4. 确认 debug 日志级别已应用到 openshift-user-workload-monitoring 项目中的 prometheus-operator 部署:

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      输出示例

              - --log-level=debug

      Debug 级别日志记录将显示 Prometheus Operator 发出的所有调用。

    5. 检查 prometheus-operator Pod 是否正在运行:

      $ oc -n openshift-user-workload-monitoring get pods
      注意

      如果配置映射中包含了一个未识别的 Prometheus Operator loglevel 值,则 prometheus-operator Pod 可能无法成功重启。

    6. 查看 debug 日志,以了解 Prometheus Operator 是否在使用 ServiceMonitor 资源。查看日志中的其他相关错误。

其他资源

12.2. 确定为什么 Prometheus 消耗大量磁盘空间

开发人员可以使用键值对的形式为指标定义属性。潜在的键值对数量与属性的可能值数量对应。具有无限数量可能值的属性被称为未绑定属性。例如,customer_id 属性不绑定,因为它有无限多个可能的值。

每个分配的键值对都有唯一的时间序列。在标签中使用许多未绑定属性可导致所创建的时间序列数量出现指数增加。这可能会影响 Prometheus 性能,并消耗大量磁盘空间。

当 Prometheus 消耗大量磁盘时,您可以使用以下方法:

  • 使用 Prometheus HTTP API 检查时间序列数据库(TSDB)状态,以了解有关哪些标签创建最多时间序列数据的更多信息。这样做需要集群管理员特权。
  • 检查正在收集的提取示例数量
  • 减少创建的唯一时间序列数量,您可以减少分配给用户定义的指标的未绑定属性数量

    注意

    使用绑定到一组有限可能值的属性可减少潜在的键-值对组合数量。

  • 对可在用户定义的项目中提取的示例数量实施限制。这需要集群管理员特权。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. Administrator 视角中,进入到 ObserveMetrics
  2. Expression 字段中输入 Prometheus Query Language (PromQL) 查询。以下示例查询有助于识别可能导致高磁盘空间消耗的高卡性指标:

    • 通过运行以下查询,您可以识别具有最高提取示例数的十个作业:

      topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))
    • 通过运行以下查询,您可以通过识别在上一小时内创建了最多时间序列数据的十个作业,从而找出相关的时间序列:

      topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))
  3. 如果指标的提取示例数大于预期,请检查分配给指标的未绑定标签值数量:

    • 如果指标与用户定义的项目相关,请查看分配给您的工作负载的指标键-值对。它们通过应用程序级别的 Prometheus 客户端库实施。尝试限制标签中引用的未绑定属性数量。
    • 如果指标与 OpenShift Container Platform 核心项目相关,请在红帽客户门户网站上创建一个红帽支持问题单。
  4. 以集群管理员身份登录时,按照以下步骤使用 Prometheus HTTP API 查看 TSDB 状态:

    1. 运行以下命令来获取 Prometheus API 路由 URL:

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.spec.host})
    2. 运行以下命令来提取身份验证令牌:

      $ TOKEN=$(oc whoami -t)
    3. 运行以下命令,查询 Prometheus 的 TSDB 状态:

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"

      输出示例

      "status": "success","data":{"headStats":{"numSeries":507473,
      "numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
      "maxTime":1712257935346},"seriesCountByMetricName":
      [{"name":"etcd_request_duration_seconds_bucket","value":51840},
      {"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
      ...

12.3. 解决 Prometheus 的 KubePersistentVolumeFillingUp 警报触发的问题

作为集群管理员,您可以解析 Prometheus 触发的 KubePersistentVolumeFillingUp 警报。

openshift-monitoring 项目中的 prometheus-k8s-* pod 声明的持久性卷 (PV) 时,关键警报会在剩余的总空间少于 3% 时触发。这可能导致 Prometheus 正常正常工作。

注意

有两个 KubePersistentVolumeFillingUp 警报:

  • Critical 警报 :当挂载的 PV 小于 3% 的总空间时,会触发具有 severity="critical" 标签的警报。
  • Warning 警报 :当挂载的 PV 的总空间低于 15% 时,会触发带有 severity="warning" 标签的警报,且预期在四天内填满。

要解决这个问题,您可以删除 Prometheus 时间序列数据库 (TSDB) 块来为 PV 创建更多空间。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令,列出所有 TSDB 块的大小,从最旧的到最新排序:

    $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \1
    -c prometheus --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \2
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
    -- sh -c 'cd /prometheus/;du -hs $(ls -dt */ | grep -Eo "[0-9|A-Z]{26}")'
    1 2
    <prometheus_k8s_pod_name> 替换为 KubePersistentVolumeFillingUp 警报描述中提到的 pod。

    输出示例

    308M    01HVKMPKQWZYWS8WVDAYQHNMW6
    52M     01HVK64DTDA81799TBR9QDECEZ
    102M    01HVK64DS7TRZRWF2756KHST5X
    140M    01HVJS59K11FBVAPVY57K88Z11
    90M     01HVH2A5Z58SKT810EM6B9AT50
    152M    01HV8ZDVQMX41MKCN84S32RRZ1
    354M    01HV6Q2N26BK63G4RYTST71FBF
    156M    01HV664H9J9Z1FTZD73RD1563E
    216M    01HTHXB60A7F239HN7S2TENPNS
    104M    01HTHMGRXGS0WXA3WATRXHR36B

  2. 确定可以删除哪些块以及多少块,然后删除块。以下示例命令从 prometheus-k8s-0 pod 中删除三个最旧的 Prometheus TSDB 块:

    $ oc debug prometheus-k8s-0 -n openshift-monitoring \
    -c prometheus --image=$(oc get po -n openshift-monitoring prometheus-k8s-0 \
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
    -- sh -c 'ls -latr /prometheus/ | egrep -o "[0-9|A-Z]{26}" | head -3 | \
    while read BLOCK; do rm -r /prometheus/$BLOCK; done'
  3. 运行以下命令,验证挂载的 PV 的使用并确保有足够的可用空间:

    $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \1
    --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \2
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') -- df -h /prometheus/
    1 2
    <prometheus_k8s_pod_name> 替换为 KubePersistentVolumeFillingUp 警报描述中提到的 pod。

    以下示例显示了由 prometheus-k8s-0 pod 声明的挂载的 PV,该 pod 剩余 63%:

    输出示例

    Starting pod/prometheus-k8s-0-debug-j82w4 ...
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme0n1p4  40G   15G  40G  37% /prometheus
    
    Removing debug pod ...

第 13 章 Cluster Monitoring Operator 的配置映射引用

13.1. Cluster Monitoring Operator 配置参考

OpenShift Container Platform 集群监控的一部分是可配置的。该 API 可通过设置各种配置映射中定义的参数来访问。

  • 要配置监控组件,请编辑 openshift-monitoring 命名空间中的名为 cluster-monitoring-configConfigMap 对象。这些配置由 ClusterMonitoringConfiguration 定义。
  • 要配置用于监控用户定义的项目的监控组件,请编辑 openshift-user-workload-monitoring 命名空间中名为 user-workload-monitoring-configConfigMap 对象。这些配置由 UserWorkloadConfiguration 定义。

配置文件始终在配置映射数据的 config.yaml 键下定义。

重要
  • 并非所有监控堆栈的配置参数都会被公开。只有此引用中列出的参数和字段才支持进行配置。有关支持的配置的更多信息,请参阅维护和支持
  • 配置集群监控是可选的。
  • 如果配置不存在或为空,则使用默认值。
  • 如果配置无效 YAML 数据,Cluster Monitoring Operator 会在 Operator 状态条件中停止协调资源并报告 Degraded=True

13.2. AdditionalAlertmanagerConfig

13.2.1. 描述

AdditionalAlertmanagerConfig 资源定义组件如何与其他 Alertmanager 实例通信的设置。

13.2.2. 必需

  • apiVersion

会出现在: PrometheusK8sConfigPrometheusRestrictedConfigThanosRulerConfig

属性类型描述

apiVersion

字符串

定义 Alertmanager 的 API 版本。可能的值有 v1v2。默认值为 v2

bearerToken

*v1.SecretKeySelector

定义包含 Alertmanager 身份验证时要使用的 bearer 令牌的 secret 密钥引用。

pathPrefix

字符串

定义要在推送端点路径前面添加的路径前缀。

scheme

字符串

定义与 Alertmanager 实例通信时要使用的 URL 方案。可能的值有 httphttps。默认值为 http

staticConfigs

[]string

<hosts>:<port> 的形式静态配置的 Alertmanager 端点列表。

timeout

*string

定义发送警报时使用的超时值。

tlsConfig

TLSConfig

定义用于 Alertmanager 连接的 TLS 设置。

13.3. AlertmanagerMainConfig

13.3.1. 描述

AlertmanagerMainConfig 资源定义 openshift-monitoring 命名空间中的 Alertmanager 组件的设置。

出现在:ClusterMonitoringConfiguration

属性类型描述

enabled

*bool

此布尔值标志,用于启用或禁用 openshift-monitoring 命名空间中的主 Alertmanager 实例。默认值为 true

enableUserAlertmanagerConfig

bool

一个布尔值标志,用于启用或禁用要用于 AlertmanagerConfig 查找的用户定义命名空间。只有在未启用 Alertmanager 的用户工作负载监控实例时,此设置才适用。默认值为 false

logLevel

字符串

定义 Alertmanager 的日志级别设置。可能的值有:error,warn,info,debug。默认值为 info

nodeSelector

map[string]string

定义 Pod 被调度到的节点。

资源

*v1.ResourceRequirements

为 Alertmanager 容器定义资源请求和限值。

secrets

[]string

定义要挂载到 Alertmanager 中的 secret 列表。secret 必须位于与 Alertmanager 对象相同的命名空间中。它们作为名为 secret-<secret-name> 的卷添加,并挂载到 Alertmanager pod 的 alertmanager 容器中的 /etc/alertmanager/secrets/<secret-name>

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布约束。

volumeClaimTemplate

*monv1.EmbeddedPersistentVolumeClaim

为 Alertmanager 定义持久性存储。使用这个设置配置持久性卷声明,包括存储类、卷大小和名称。

13.4. AlertmanagerUserWorkloadConfig

13.4.1. 描述

AlertmanagerUserWorkloadConfig 资源定义用于用户定义的项目的 Alertmanager 实例的设置。

出现在: UserWorkloadConfiguration

属性类型描述

enabled

bool

此布尔值标志,用于启用或禁用 openshift-user-workload-monitoring 命名空间中用户定义的警报的 Alertmanager 专用实例。默认值为 false

enableAlertmanagerConfig

bool

AlertmanagerConfig 查找启用或禁用用户定义的命名空间的布尔值标志。默认值为 false

logLevel

字符串

定义 Alertmanager 用户工作负载监控的日志级别设置。可能的值有 errorwarninfodebug。默认值为 info

资源

*v1.ResourceRequirements

为 Alertmanager 容器定义资源请求和限值。

secrets

[]string

定义要挂载到 Alertmanager 中的 secret 列表。secret 必须位于与 Alertmanager 对象相同的命名空间中。它们作为名为 secret-<secret-name> 的卷添加,并挂载到 Alertmanager pod 的 alertmanager 容器中的 /etc/alertmanager/secrets/<secret-name>

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布约束。

volumeClaimTemplate

*monv1.EmbeddedPersistentVolumeClaim

为 Alertmanager 定义持久性存储。使用这个设置配置持久性卷声明,包括存储类、卷大小和名称。

13.5. ClusterMonitoringConfiguration

13.5.1. 描述

ClusterMonitoringConfiguration 资源定义通过 openshift-monitoring 命名空间中的 cluster-monitoring-config 配置映射自定义默认平台监控堆栈的设置。

属性类型描述

alertmanagerMain

*AlertmanagerMainConfig

AlertmanagerMainConfig 定义了 openshift-monitoring 命名空间中的 Alertmanager 组件的设置。

enableUserWorkload

*bool

UserWorkloadEnabled 是一个布尔值标志,可为用户定义的项目启用监控。

k8sPrometheusAdapter

*K8sPrometheusAdapter

K8sPrometheusAdapter 为 Prometheus Adapter 组件定义设置。

kubeStateMetrics

*KubeStateMetricsConfig

KubeStateMetricsConfig 定义 kube-state-metrics 代理的设置。

metricsServer

*MetricsServerConfig

MetricsServer 定义 Metrics 服务器组件的设置。

prometheusK8s

*PrometheusK8sConfig

PrometheusK8sConfig 定义 Prometheus 组件的设置。

prometheusOperator

*PrometheusOperatorConfig

PrometheusOperatorConfig 定义 Prometheus Operator 组件的设置。

prometheusOperatorAdmissionWebhook

*PrometheusOperatorAdmissionWebhookConfig

PrometheusOperatorAdmissionWebhookConfig 定义 Prometheus Operator 的准入 webhook 组件的设置。

openshiftStateMetrics

*OpenShiftStateMetricsConfig

OpenShiftMetricsConfig 定义 openshift-state-metrics 代理的设置。

telemeterClient

*TelemeterClientConfig

TelemeterClientConfig 为 Telemeter Client 组件定义设置。

thanosQuerier

*ThanosQuerierConfig

ThanosQuerierConfig 定义 Thanos Querier 组件的设置。

nodeExporter

NodeExporterConfig

NodeExporterConfig 定义 node-exporter 代理的设置。

monitoringPlugin

*MonitoringPluginConfig

MonitoringPluginConfig 定义了监控 console-plugin 组件的设置。

13.6. DedicatedServiceMonitors

13.6.1. 描述

重要

此设置已弃用,计划在以后的 OpenShift Container Platform 版本中删除。在当前版本中,此设置仍然存在,但没有影响。

您可以使用 DedicatedServiceMonitors 资源为 Prometheus Adapter 配置专用 Service Monitors

会出现:K8sPrometheusAdapter

属性类型描述

enabled

bool

enabled 设置为 true 时,Cluster Monitoring Operator (CMO) 会部署一个专门的 Service Monitor,它会公开 kubelet /metrics/resource 端点。此 Service Monitor 会设置 honorTimestamps: true,并只保留与 Prometheus Adapter 的 pod 资源查询相关的指标。另外,Prometheus Adapter 被配置为使用这些专用指标。总体而言,此功能提高了由 oc adm top pod 命令或 Horizontal Pod Autoscaler 使用的基于 Prometheus Adapter 的 CPU 用量测量的一致性。

13.7. K8sPrometheusAdapter

13.7.1. 描述

K8sPrometheusAdapter 资源定义 Prometheus Adapter 组件的设置。

出现在:ClusterMonitoringConfiguration

属性类型描述

audit

*Audit

定义 Prometheus Adapter 实例使用的审计配置。可能的配置集值包括:Metadata, Request, RequestResponse, 和 None默认值为 Metadata

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

资源

*v1.ResourceRequirements

PrometheusAdapter 容器定义资源请求和限值。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布约束。

dedicatedServiceMonitors

*DedicatedServiceMonitors

定义专用服务监控器。

13.8. KubeStateMetricsConfig

13.8.1. 描述

KubeStateMetricsConfig 资源定义 kube-state-metrics 代理的设置。

出现在:ClusterMonitoringConfiguration

属性类型描述

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

资源

*v1.ResourceRequirements

KubeStateMetrics 容器定义资源请求和限值。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布约束。

13.9. MetricsServerConfig

13.9.1. 描述

重要

指标服务器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

MetricsServerConfig 资源定义 Metrics Server 组件的设置。请注意,此设置仅在启用 TechPreviewNoUpgrade 功能门时才适用。

出现在:ClusterMonitoringConfiguration

属性类型描述

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

resources

*v1.ResourceRequirements

为 Metrics Server 容器定义资源请求和限值。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布约束。

13.10. PrometheusOperatorAdmissionWebhookConfig

13.10.1. 描述

PrometheusOperatorAdmissionWebhookConfig 资源定义 Prometheus Operator 的准入 Webhook 工作负载的设置。

出现在:ClusterMonitoringConfiguration

属性类型描述

resources

*v1.ResourceRequirements

prometheus-operator-admission-webhook 容器定义资源请求和限值。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布约束。

13.11. MonitoringPluginConfig

13.11.1. 描述

MonitoringPluginConfig 资源定义 openshift-monitoring 命名空间中的 web 控制台插件组件的设置。

出现在:ClusterMonitoringConfiguration

属性类型描述

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

资源

*v1.ResourceRequirements

console-plugin 容器定义资源请求和限值。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布约束。

13.12. NodeExporterCollectorBuddyInfoConfig

13.12.1. 描述

NodeExporterCollectorBuddyInfoConfig 资源充当 node-exporter 代理的 buddyinfo 收集器的 on/off 开关。默认情况下,buddyinfo 收集器被禁用。

出现在:NodeExporterCollectorConfig

属性类型描述

enabled

bool

启用或禁用 buddyinfo 收集器的布尔值标志。

13.13. NodeExporterCollectorConfig

13.13.1. 描述

NodeExporterCollectorConfig 资源定义 node-exporter 代理的独立收集器的设置。

出现在:NodeExporterConfig

属性类型描述

cpufreq

NodeExporterCollectorCpufreqConfig

定义 cpufreq 收集器的配置,用于收集 CPU 频率统计。默认禁用此选项。

tcpstat

NodeExporterCollectorTcpStatConfig

定义 tcpstat 收集器的配置,用于收集 TCP 连接统计信息。默认禁用此选项。

netdev

NodeExporterCollectorNetDevConfig

定义 netdev 收集器的配置,用于收集网络设备统计信息。默认启用此选项。

netclass

NodeExporterCollectorNetClassConfig

定义 netclass 收集器的配置,用于收集有关网络设备的信息。默认启用此选项。

buddyinfo

NodeExporterCollectorBuddyInfoConfig

定义 buddyinfo 收集器的配置,它从 node_buddyinfo_blocks 指标收集有关内存碎片的统计信息。此指标从 /proc/buddyinfo 收集数据。默认禁用此选项。

mountstats

NodeExporterCollectorMountStatsConfig

定义 mountstats 收集器的配置,用于收集有关 NFS 卷 I/O 活动的统计信息。默认禁用此选项。

ksmd

NodeExporterCollectorKSMDConfig

定义 ksmd 收集器的配置,该收集器从内核的 same-page merger 守护进程中收集统计信息。默认禁用此选项。

进程

NodeExporterCollectorProcessesConfig

定义 processes 收集器的配置,它从系统的进程和线程中收集统计信息。默认禁用此选项。

systemd

NodeExporterCollectorSystemdConfig

定义 systemd 收集器的配置,用于收集 systemd 守护进程及其受管服务的统计信息。默认禁用此选项。

13.14. NodeExporterCollectorCpufreqConfig

13.14.1. 描述

使用 NodeExporterCollectorCpufreqConfig 资源启用或禁用 node-exporter 代理的 cpufreq 收集器。默认情况下禁用 cpufreq 收集器。在某些情况下,启用 cpufreq 收集器会增加带有多个内核的机器上的 CPU 使用量。如果您启用此收集器并具有许多内核的机器,请密切监控您的系统以了解过量 CPU 用量。

出现在:NodeExporterCollectorConfig

属性类型描述

enabled

bool

启用或禁用 cpufreq 收集器的布尔值标志。

13.15. NodeExporterCollectorKSMDConfig

13.15.1. 描述

使用 NodeExporterCollectorKSMDConfig 资源启用或禁用 node-exporter 代理的 ksmd 收集器。默认情况下禁用 ksmd 收集器。

出现在:NodeExporterCollectorConfig

属性类型描述

enabled

bool

启用或禁用 ksmd 收集器的布尔值标志。

13.16. NodeExporterCollectorMountStatsConfig

13.16.1. 描述

使用 NodeExporterCollectorMountStatsConfig 资源启用或禁用 node-exporter 代理的 mountstats 收集器。默认情况下禁用 mountstats 收集器。如果启用收集器,则以下指标可用: node_mountstats_nfs_read_bytes_total,node_mountstats_nfs_write_bytes_total, 和 node_mountstats_nfs_operations_requests_total.请注意,这些指标可能会有高基数如果启用此收集器,请密切监控 prometheus-k8s Pod 的内存用量增加。

出现在:NodeExporterCollectorConfig

属性类型描述

enabled

bool

启用或禁用 mountstats 收集器的布尔值标志。

13.17. NodeExporterCollectorNetClassConfig

13.17.1. 描述

使用 NodeExporterCollectorNetClassConfig 资源启用或禁用 node-exporter 代理的 netclass 收集器。默认情况下启用 netclass 收集器。如果禁用此收集器,则以下指标不可用:node_network_info, node_network_address_assign_type, node_network_carrier, node_network_carrier_changes_total, node_network_carrier_up_changes_total, node_network_carrier_down_changes_total, node_network_device_id, node_network_dormant, node_network_flags, node_network_iface_id, node_network_iface_link, node_network_iface_link_mode, node_network_mtu_bytes, node_network_name_assign_type, node_network_net_dev_group, node_network_speed_bytes, node_network_transmit_queue_length, 和 node_network_protocol_type

出现在:NodeExporterCollectorConfig

属性类型描述

enabled

bool

启用或禁用 netclass 收集器的布尔值标志。

useNetlink

bool

激活 netclass 收集器的 netlink 实现的布尔值标志。默认值是 true,这会激活 netlink 模式。此实现提高了 netclass 收集器的性能。

13.18. NodeExporterCollectorNetDevConfig

13.18.1. 描述

使用 NodeExporterCollectorNetDevConfig 资源启用或禁用 node-exporter 代理的 netdev 收集器。默认情况下启用 netdev 收集器。如果禁用,以下指标不可用:node_network_receive_bytes_total, node_network_receive_compressed_total, node_network_receive_drop_total, node_network_receive_errs_total, node_network_receive_fifo_total, node_network_receive_frame_total, node_network_receive_multicast_total, node_network_receive_nohandler_total, node_network_receive_packets_total, node_network_transmit_bytes_total, node_network_transmit_carrier_total, node_network_transmit_colls_total, node_network_transmit_compressed_total, node_network_transmit_drop_total, node_network_transmit_errs_total, node_network_transmit_fifo_total, 和 node_network_transmit_packets_total

出现在:NodeExporterCollectorConfig

属性类型描述

enabled

bool

启用或禁用 netdev 收集器的布尔值标志。

13.19. NodeExporterCollectorProcessesConfig

13.19.1. 描述

使用 NodeExporterCollectorProcessesConfig 资源启用或禁用 node-exporter 代理的 processes 收集器。如果启用了收集器,则以下指标可用: node_processes_max_processes,node_processes_pids,node_processes_state,node_processes_threads,node_processes_threads_state.指标 node_processes_statenode_processes_threads_state 最多可以有五个系列,具体取决于进程和线程的状态。进程或线程的可能状态为:D (UNINTERRUPTABLE_SLEEP), R (RUNNING & RUNNABLE), S (INTERRUPTABLE_SLEEP), T (STOPPED), or Z (ZOMBIE)。默认情况下禁用 processes 收集器。

出现在:NodeExporterCollectorConfig

属性类型描述

enabled

bool

用于启用或禁用 processes 收集器的布尔值标志。

13.20. NodeExporterCollectorSystemdConfig

13.20.1. 描述

使用 NodeExporterCollectorSystemdConfig 资源启用或禁用 node-exporter 代理的 systemd 收集器。默认情况下禁用 systemd 收集器。如果启用,则以下指标可用: node_systemd_system_running,node_systemd_units,node_systemd_version.如果单元使用一个套接字,它还会生成以下指标:node_systemd_socket_accepted_connections_total,node_systemd_socket_current_connections,node_systemd_socket_refused_connections_total。您可以使用 units 参数选择 systemd 收集器中包含的 systemd 单元。所选单元用于生成 node_systemd_unit_state 指标,其中显示每个 systemd 单元的状态。但是,这个指标的基数可能很高(每个节点至少五个系列)。如果您使用所选单元列表启用此收集器,请仔细监控 prometheus-k8s 部署以了解过量内存用量。请注意,只有在将 units 参数的值配置为 logrotate.timer 时才会显示 node_systemd_timer_last_trigger_seconds 指标。

出现在:NodeExporterCollectorConfig

属性类型描述

enabled

bool

启用或禁用 systemd 收集器的布尔值标志。

units

[]string

systemd 收集器包含的 systemd 单元匹配的正则表达式(regex)特征列表。默认情况下,列表为空,因此收集器不会公开 systemd 单元的指标。

13.21. NodeExporterCollectorTcpStatConfig

13.21.1. 描述

NodeExporterCollectorTcpStatConfig 资源充当 node-exporter 代理的 tcpstat 收集器的 on/off 开关。默认情况下,tcpstat 收集器被禁用。

出现在:NodeExporterCollectorConfig

属性类型描述

enabled

bool

启用或禁用 tcpstat 收集器的布尔值标志。

13.22. NodeExporterConfig

13.22.1. 描述

NodeExporterConfig 资源定义 node-exporter 代理的设置。

出现在:ClusterMonitoringConfiguration

属性类型描述

收集器

NodeExporterCollectorConfig

定义启用哪些收集器及其额外的配置参数。

maxProcs

uint32

运行 node-exporter 的 CPU 的目标数量。默认值为 0,这意味着 node-exporter 在所有 CPU 上运行。如果发生内核死锁,或者当同时从 sysfs 读取时性能下降,您可以将这个值改为 1,这会将 node-exporter 限制为在一个 CPU 上运行。对于具有高 CPU 数量的节点,您可以将此限制设置为一个低的数量,这可以防止将 Go 例程调度到所有 CPU 上来运行,从而达到保存资源的目的。但是,如果 maxProcs 值设置得太低,并收集很多指标,则 I/O 性能会降低。

ignoredNetworkDevices

*[]string

您要从相关收集器配置中排除的网络设备列表,如 netdevnetclass。如果没有指定列表,Cluster Monitoring Operator 将使用预定义的设备列表来最小化对内存用量的影响。如果列表为空,则不会排除任何设备。如果修改了此设置,请密切监控 prometheus-k8s 部署以了解过量内存用量。

resources

*v1.ResourceRequirements

NodeExporter 容器定义资源请求和限值。

13.23. OpenShiftStateMetricsConfig

13.23.1. 描述

OpenShiftStateMetricsConfig 资源定义 openshift-state-metrics 代理的设置。

出现在:ClusterMonitoringConfiguration

属性类型描述

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

资源

*v1.ResourceRequirements

OpenShiftStateMetrics 容器定义资源请求和限值。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布限制。

13.24. PrometheusK8sConfig

13.24.1. 描述

PrometheusK8sConfig 资源定义 Prometheus 组件的设置。

出现在:ClusterMonitoringConfiguration

属性类型描述

additionalAlertmanagerConfigs

[]AdditionalAlertmanagerConfig

配置额外的 Alertmanager 实例,从 Prometheus 组件接收警报。默认情况下,没有配置额外的 Alertmanager 实例。

enforcedBodySizeLimit

字符串

为 Prometheus 提取的指标强制实施正文大小限制。如果提取的目标正文响应大于限制,则提取将失败。以下值是有效的:一个空值,用于指定没有限制、以 Prometheus 大小格式(如 64MB)的数字值,或者字符串 automatic,这表示将根据集群容量自动计算限制。默认值为空,这代表没有限制。

externalLabels

map[string]string

定义在与外部系统通信时要添加到任何时间序列或警报的标签,如联邦、远程存储和 Alertmanager。默认情况下不会添加任何标签。

logLevel

字符串

定义 Prometheus 的日志级别设置。可能的值有: errorwarninfodebug。默认值为 info

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

queryLogFile

字符串

指定记录 PromQL 查询的文件。此设置可以是文件名,在这种情况下,查询被保存到位于 /var/log/prometheusemptyDir 卷,或者挂载到挂载 emptyDir 卷的位置的完整路径,并保存查询。支持写入 /dev/stderr/dev/stdout/dev/null,但不支持写入任何其他 /dev/ 路径。不支持相对路径。默认情况下,PromQL 查询不会被记录。

remoteWrite

[]RemoteWriteSpec

定义远程写入配置,包括 URL、身份验证和重新标记设置。

资源

*v1.ResourceRequirements

Prometheus 容器定义资源请求和限值。

保留

字符串

定义 Prometheus 保留数据的持续时间。这个定义必须使用以下正则表达式模式指定:[0-9]+(ms|s|m|h|d|w|y) (ms = milliseconds, s= seconds,m = minutes, h = hours, d = days, w = weeks, y = years)。默认值为 15d

retentionSize

字符串

定义数据块使用的最大磁盘空间量加上 write-ahead log (WAL)。支持的值包括 B, KB, KiB, MB, MiB, GB, GiB, TB, TiB, PB, PiB, EB, 和 EiB。默认情况下不定义任何限制。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布限制。

collectionProfile

CollectionProfile

定义 Prometheus 用来从平台组件收集指标的指标集合配置集。支持的值是 fullminimal。在 full 配置集(默认)中,Prometheus 会收集平台组件公开的所有指标。在 minimal 配置集中,Prometheus 只收集默认平台警报、记录规则、遥测和控制台仪表板所需的指标。

volumeClaimTemplate

*monv1.EmbeddedPersistentVolumeClaim

为 Prometheus 定义持久性存储。使用这个设置配置持久性卷声明,包括存储类、卷大小和名称。

13.25. PrometheusOperatorConfig

13.25.1. 描述

PrometheusOperatorConfig 资源定义 Prometheus Operator 组件的设置。

出现在:ClusterMonitoringConfiguration,UserWorkloadConfiguration

属性类型描述

logLevel

字符串

定义 Prometheus Operator 的日志级别设置。可能的值有 errorwarninfodebug。默认值为 info

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

资源

*v1.ResourceRequirements

PrometheusOperator 容器定义资源请求和限值。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布限制。

13.26. PrometheusRestrictedConfig

13.26.1. 描述

PrometheusRestrictedConfig 资源定义监控用户定义的项目的 Prometheus 组件的设置。

出现在: UserWorkloadConfiguration

属性类型描述

additionalAlertmanagerConfigs

[]AdditionalAlertmanagerConfig

配置额外的 Alertmanager 实例,从 Prometheus 组件接收警报。默认情况下,没有配置额外的 Alertmanager 实例。

enforcedLabelLimit

*uint64

指定示例可接受的标签数的 per-scrape 限制。如果标签数量在指标重新标记后超过这个限制,则整个提取将被视为失败。默认值为 0,这表示没有设置限制。

enforcedLabelNameLengthLimit

*uint64

为示例指定标签名称长度的 per-scrape 限制。如果标签名称的长度在指标重新标记后超过这个限制,则整个提取将被视为失败。默认值为 0,这表示没有设置限制。

enforcedLabelValueLengthLimit

*uint64

为示例指定标签值长度的 per-scrape 限值。如果标签值的长度在指标重新标记后超过这个限制,则整个提取将被视为失败。默认值为 0,这表示没有设置限制。

enforcedSampleLimit

*uint64

指定一个接受的提取示例数量的全局限制。如果值大于 enforcedTargetLimit,则此设置覆盖任何用户定义的 ServiceMonitorPodMonitor 对象中设置的 SampleLimit 值。管理员可以使用此设置来保持控制下的总样本数量。默认值为 0,这表示没有设置限制。

enforcedTargetLimit

*uint64

指定提取目标数量的全局限制。如果值大于 enforcedSampleLimit,则此设置会覆盖任何用户定义的 ServiceMonitorPodMonitor 对象中设置的 TargetLimit 值。管理员可以使用此设置保持控制下的目标总数。默认值为 0

externalLabels

map[string]string

定义在与外部系统通信时要添加到任何时间序列或警报的标签,如联邦、远程存储和 Alertmanager。默认情况下不会添加任何标签。

logLevel

字符串

定义 Prometheus 的日志级别设置。可能的值有 errorwarninfodebug。默认设置为 info

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

queryLogFile

字符串

指定记录 PromQL 查询的文件。此设置可以是文件名,在这种情况下,查询被保存到位于 /var/log/prometheusemptyDir 卷,或者挂载到挂载 emptyDir 卷的位置的完整路径,并保存查询。支持写入 /dev/stderr/dev/stdout/dev/null,但不支持写入任何其他 /dev/ 路径。不支持相对路径。默认情况下,PromQL 查询不会被记录。

remoteWrite

[]RemoteWriteSpec

定义远程写入配置,包括 URL、身份验证和重新标记设置。

资源

*v1.ResourceRequirements

为 Prometheus 容器定义资源请求和限值。

保留

字符串

定义 Prometheus 保留数据的持续时间。这个定义必须使用以下正则表达式模式指定:[0-9]+(ms|s|m|h|d|w|y) (ms = milliseconds, s= seconds,m = minutes, h = hours, d = days, w = weeks, y = years)。默认值为 15d

retentionSize

字符串

定义数据块使用的最大磁盘空间量加上 write-ahead log (WAL)。支持的值包括 B, KB, KiB, MB, MiB, GB, GiB, TB, TiB, PB, PiB, EB, 和 EiB。默认值为 nil

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布限制。

volumeClaimTemplate

*monv1.EmbeddedPersistentVolumeClaim

为 Prometheus 定义持久性存储。使用此设置配置卷的存储类和大小。

13.27. RemoteWriteSpec

13.27.1. 描述

RemoteWriteSpec 资源定义远程写入存储的设置。

13.27.2. 必需

  • url

会出现在: PrometheusK8sConfigPrometheusRestrictedConfig

属性类型描述

授权

*monv1.SafeAuthorization

定义远程写入存储的授权设置。

basicAuth

*monv1.BasicAuth

定义远程写入端点 URL 的基本身份验证设置。

bearerTokenFile

字符串

定义包含远程写入端点的 bearer 令牌的文件。但是,因为您无法在 pod 中挂载 secret,所以在实践中,您只能引用服务帐户的令牌。

标头

map[string]string

指定要随每个远程写入请求一起发送的自定义 HTTP 标头。Prometheus 设置的标头不能被覆盖。

metadataConfig

*monv1.MetadataConfig

定义向远程写入存储发送一系列元数据的设置。

name

字符串

定义远程写入队列的名称。此名称用于指标和日志记录来区分队列。如果指定,此名称必须是唯一的。

oauth2

*monv1.OAuth2

定义远程写入端点的 OAuth2 身份验证设置。

proxyUrl

字符串

定义可选的代理 URL。

queueConfig

*monv1.QueueConfig

允许针对远程写入队列参数调整配置。

remoteTimeout

字符串

定义对远程写入端点的请求的超时值。

sendExemplars

*bool

启用通过远程写入发送 exemplars。启用后,此设置将 Prometheus 配置为在内存中存储最多 100,000 个 exemplars。此设置仅适用于用户定义的监控,不适用于核心平台监控。

sigv4

*monv1.Sigv4

定义 AWS 签名版本 4 身份验证设置。

tlsConfig

*monv1.SafeTLSConfig

定义远程写入端点的 TLS 身份验证设置。

url

字符串

定义要向其发送示例的远程写入端点的 URL。

writeRelabelConfigs

[]monv1.RelabelConfig

定义远程写入重新标记配置的列表。

13.28. TLSConfig

13.28.1. 描述

TLSConfig 资源配置 TLS 连接的设置。

13.28.2. 必需

  • insecureSkipVerify

出现在: AdditionalAlertmanagerConfig

属性类型描述

ca

*v1.SecretKeySelector

定义包含用于远程主机的证书颁发机构 (CA) 的 secret 密钥引用。

cert

*v1.SecretKeySelector

定义包含用于远程主机的公共证书的 secret 密钥引用。

key

*v1.SecretKeySelector

定义包含用于远程主机的私钥的 secret 密钥引用。

serverName

字符串

用于验证返回的证书主机名。

insecureSkipVerify

bool

当设置为 true 时,将禁用远程主机的证书和名称的验证。

13.29. TelemeterClientConfig

13.29.1. 描述

TelemeterClientConfig 为 Telemeter Client 组件定义设置。

13.29.2. 必需

  • nodeSelector
  • 容限(tolerations)

出现在:ClusterMonitoringConfiguration

属性类型描述

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

资源

*v1.ResourceRequirements

TelemeterClient 容器定义资源请求和限值。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布限制。

13.30. ThanosQuerierConfig

13.30.1. 描述

ThanosQuerierConfig 资源定义 Thanos Querier 组件的设置。

出现在:ClusterMonitoringConfiguration

属性类型描述

enableRequestLogging

bool

启用或禁用请求日志记录的布尔值标志。默认值为 false

logLevel

字符串

定义 Thanos Querier 的日志级别设置。可能的值有 errorwarninfodebug。默认值为 info

enableCORS

bool

启用设置 CORS 标头的布尔值标志。标头允许从任何来源访问。默认值为 false

nodeSelector

map[string]string

定义在其上调度 pod 的节点。

资源

*v1.ResourceRequirements

为 Thanos Querier 容器定义资源请求和限值。

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布限制。

13.31. ThanosRulerConfig

13.31.1. 描述

ThanosRulerConfig 资源定义面向用户定义的项目的 Thanos Ruler 实例的配置。

出现在: UserWorkloadConfiguration

属性类型描述

additionalAlertmanagerConfigs

[]AdditionalAlertmanagerConfig

配置 Thanos Ruler 组件如何与其他 Alertmanager 实例通信。默认值为 nil

logLevel

字符串

定义 Thanos Ruler 的日志级别设置。可能的值有 errorwarninfodebug。默认值为 info

nodeSelector

map[string]string

定义 Pod 被调度到的节点。

资源

*v1.ResourceRequirements

为 Alertmanager 容器定义资源请求和限值。

保留

字符串

定义 Prometheus 保留数据的持续时间。这个定义必须使用以下正则表达式模式指定:[0-9]+(ms|s|m|h|d|w|y) (ms = milliseconds, s= seconds,m = minutes, h = hours, d = days, w = weeks, y = years)。默认值为 15d

容限(tolerations)

[]v1.Toleration

为 pod 定义容限。

topologySpreadConstraints

[]v1.TopologySpreadConstraint

定义 pod 的拓扑分布限制。

volumeClaimTemplate

*monv1.EmbeddedPersistentVolumeClaim

为 Thanos Ruler 定义持久性存储。使用此设置配置卷的存储类和大小。

13.32. UserWorkloadConfiguration

13.32.1. 描述

UserWorkloadConfiguration 资源定义了在 openshift-user-workload-monitoring 命名空间中的 user-workload-monitoring-config 配置映射中的用于定义的项目的设置。只有在 openshift-monitoring 命名空间内的 cluster-monitoring-config 配置映射中的 enableUserWorkload 设置被为 true 后,您才可以启用 UserWorkloadConfiguration

属性类型描述

alertmanager

*AlertmanagerUserWorkloadConfig

在用户工作负载监控中定义 Alertmanager 组件的设置。

prometheus

*PrometheusRestrictedConfig

在用户工作负载监控中定义 Prometheus 组件的设置。

prometheusOperator

*PrometheusOperatorConfig

在用户工作负载监控中定义 Prometheus Operator 组件的设置。

thanosRuler

*ThanosRulerConfig

在用户工作负载监控中定义 Thanos Ruler 组件的设置。

法律通告

Copyright © 2024 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 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

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

© 2024 Red Hat, Inc.