OpenShift 文档正在迁移，不久后将仅在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

配置监控堆栈

监控的维护和支持

并非所有监控堆栈的配置选项都已公开。配置 OpenShift Dedicated 监控的唯一支持方法是使用集群监控操作符 (CMO) 配置参考中描述的选项配置集群监控操作符 (CMO)。请勿使用其他配置，因为它们不受支持。

配置范例可能会在 Prometheus 版本之间发生变化，并且只有在控制所有配置可能性的情况下才能很好地处理此类情况。如果您使用集群监控操作符 (CMO) 配置参考中未描述的配置，则您的更改将会消失，因为 CMO 会自动协调任何差异，并默认且按设计将任何不受支持的更改重置回最初定义的状态。

安装另一个 Prometheus 实例不受 Red Hat 站点可靠性工程师 (SRE) 支持。

监控的支持注意事项

不保证指标、记录规则或告警规则的向后兼容性。

明确不支持以下修改

  • 在 OpenShift Dedicated 上安装自定义 Prometheus 实例。自定义实例是由 Prometheus Operator 管理的 Prometheus 自定义资源 (CR)。

  • 修改默认平台监控组件。您不应修改cluster-monitoring-config 配置映射中定义的任何组件。Red Hat SRE 使用这些组件来监控核心集群组件和 Kubernetes 服务。

监控组件的支持版本矩阵

下表包含有关 OpenShift Dedicated 4.12 及更高版本中监控组件版本的信息

表 1. OpenShift Dedicated 和组件版本
OpenShift Dedicated Prometheus Operator Prometheus Metrics Server Alertmanager kube-state-metrics 代理 monitoring-plugin node-exporter 代理 Thanos

4.17

0.75.2

2.53.1

0.7.1

0.27.0

2.13.0

1.0.0

1.8.2

0.35.1

4.16

0.73.2

2.52.0

0.7.1

0.26.0

2.12.0

1.0.0

1.8.0

0.35.0

4.15

0.70.0

2.48.0

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

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

N/A

0.25.0

2.8.1

N/A

1.5.0

0.30.2

4.12

0.60.1

2.39.1

N/A

0.24.0

2.6.0

N/A

1.4.0

0.28.1

openshift-state-metrics 代理和 Telemeter Client 是 OpenShift 特定的组件。因此，它们的版本与 OpenShift Dedicated 的版本相对应。

配置监控堆栈

在 OpenShift Dedicated 中，您可以使用user-workload-monitoring-config ConfigMap 对象配置监控用户定义项目中工作负载的堆栈。配置映射配置集群监控操作符 (CMO)，后者又配置堆栈的组件。

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 编辑ConfigMap 对象。

    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下添加您的配置，作为键值对<component_name>: <component_configuration>

      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 资源请求。

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

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

    • Pod 未重新部署。因此，没有服务中断。

    • 受影响的 Pod 将重新部署

      • 对于单节点集群，这会导致临时服务中断。

      • 对于多节点集群，由于高可用性，受影响的 Pod 将逐步推出，监控堆栈将保持可用。

      • 配置和调整持久卷的大小总是会导致服务中断，无论是否具有高可用性。

    每个需要更改配置映射的过程都包含其预期结果。
其他资源

可配置的监控组件

此表显示您可以配置的监控组件以及用于在user-workload-monitoring-config ConfigMap 对象中指定组件的键。

不要修改cluster-monitoring-config ConfigMap 对象中的监控组件。Red Hat 站点可靠性工程师 (SRE) 使用这些组件来监控核心集群组件和 Kubernetes 服务。
表 2. 可配置的监控组件
组件 user-workload-monitoring-config 配置映射键

Alertmanager

alertmanager

Prometheus Operator

prometheusOperator

Prometheus

prometheus

Thanos Ruler

thanosRuler

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

通过使用带有标记节点的nodeSelector 约束，您可以将任何监控堆栈组件移动到特定节点。通过这样做，您可以控制监控组件在集群中的放置和分布。

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

节点选择器如何与其他约束一起工作

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

  • 可能已设置拓扑分布约束以控制 Pod 的放置。

  • Prometheus、Thanos Querier、Alertmanager 和其他监控组件已设置严格的反亲和性规则，以确保这些组件的多个 Pod 始终分布在不同的节点上，因此始终具有高可用性。

在将 Pod 调度到节点时，Pod 调度程序会在确定 Pod 放置位置时尝试满足所有现有约束。也就是说，所有约束在 Pod 调度程序确定哪些 Pod 将放置在哪些节点上时都会复合。

因此，如果您配置了节点选择器约束，但现有的约束无法全部满足，则 Pod 调度程序将无法匹配所有约束，并且不会将 Pod 调度到任何节点上。

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

其他资源

将监控组件移动到不同的节点

您可以将监控用户定义项目工作负载的任何组件移动到特定的工作节点。不允许将组件移动到控制平面或基础设施节点。

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 如果您尚未这样做，请为要在其上运行监控组件的节点添加标签。

    $ oc label nodes <node-name> <node-label>

  2. 编辑ConfigMap对象

    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 会重新部署。

其他资源

为监控组件分配容忍度

您可以为监控用户定义项目的组件分配容忍度，以使其能够移动到被污点的 worker 节点。不允许在控制平面或基础设施节点上进行调度。

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在于 openshift-user-workload-monitoring 命名空间中。此对象在集群创建时默认创建。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 编辑ConfigMap对象

    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 将一个污点添加到 node1，键为 key1，值为 value1。除非为该污点配置了容忍度，否则这将阻止监控组件在 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 会自动重新部署。

其他资源

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

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

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

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

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

  • Alertmanager（用于核心平台监控和用户定义的项目）

  • kube-state-metrics

  • monitoring-plugin

  • node-exporter

  • openshift-state-metrics

  • Prometheus（用于核心平台监控和用户定义的项目）

  • Metrics Server

  • Prometheus Operator及其准入webhook服务

  • Telemeter Client

  • Thanos Querier

  • Thanos Ruler

通过定义资源限制，您可以限制容器的资源使用，从而防止容器超过 CPU 和内存资源的指定最大值。

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

指定监控组件的限制和请求

要配置 CPU 和内存资源，请在监控组件所在的命名空间的相应ConfigMap对象中指定资源限制和请求的值。

  • openshift-monitoring命名空间中的cluster-monitoring-config配置映射，用于核心平台监控。

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

前提条件

  • 如果您正在配置核心平台监控组件：:

    • 您可以作为具有cluster-admin集群角色的用户访问集群。

    • 您已创建名为cluster-monitoring-config的ConfigMap对象。

  • 如果您正在配置监控用户定义项目的组件：:

    • 您可以作为具有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. 添加值以定义要配置的每个核心平台监控组件的资源限制和请求。

    确保为限制设置的值始终高于为请求设置的值。否则，将发生错误，并且容器将无法运行。
    示例
    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
    metricsServer:
      resources:
        requests:
          cpu: 10m
          memory: 50Mi
        limits:
          cpu: 50m
          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 会自动重新部署。

其他资源

配置持久性存储

使用持久性存储运行集群监控可以获得以下好处：

  • 通过将指标和告警数据存储在持久卷 (PV) 中来保护您的数据免受数据丢失。因此，它们可以在 Pod 重新启动或重新创建后继续存在。

  • 避免在 Alertmanager Pod 重新启动时出现重复通知和丢失警报静默。

对于生产环境，强烈建议配置持久性存储。

在多节点集群中，必须为 Prometheus、Alertmanager 和 Thanos Ruler 配置持久性存储以确保高可用性。

持久性存储先决条件

  • 使用块类型存储。

配置持久卷声明

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

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 编辑ConfigMap对象

    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:
          storageClassName: <storage_class> (2)
          resources:
            requests:
              storage: <amount_of_storage> (3)
      1 指定要为其配置 PVC 的用户定义监控组件。
      2 指定现有的存储类。如果未指定存储类，则使用默认存储类。
      3 指定所需的存储量。

      有关如何指定volumeClaimTemplate的信息，请参阅Kubernetes关于持久卷声明的文档。

      以下示例配置了一个 PVC，该 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 配置更新 ConfigMap 时，受影响的StatefulSet对象将被重新创建，从而导致服务暂时中断。

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

默认情况下，Prometheus 保留指标数据的持续时间如下：

  • 核心平台监控：15 天

  • 用户定义项目的监控：24 小时

您可以修改监控用户定义项目的 Prometheus 实例的保留时间，以更改数据被删除的时间。您还可以设置保留的指标数据使用的最大磁盘空间量。如果数据达到此大小限制，Prometheus 将首先删除最旧的数据，直到使用的磁盘空间再次低于限制。

请注意以下这些数据保留设置的行为：

  • 基于大小的保留策略应用于/prometheus目录中的所有数据块目录，包括持久块、预写日志 (WAL) 数据和 m 映射的块。

  • /wal和/head_chunks目录中的数据计入保留大小限制，但 Prometheus 从不会根据基于大小或时间的保留策略来清除这些目录中的数据。因此，如果您设置的保留大小限制低于为/wal和/head_chunks目录设置的最大大小，则表示您已配置系统不保留/prometheus数据目录中的任何数据块。

  • 基于大小的保留策略仅在 Prometheus 切割新的数据块时应用，这发生在 WAL 包含至少三个小时的数据后的每两个小时。

  • 如果您没有显式定义retention或retentionSize的值，则核心平台监控的保留时间默认为 15 天，用户定义项目监控的保留时间默认为 24 小时。保留大小未设置。

  • 如果您同时为retention和retentionSize定义值，则这两个值都适用。如果任何数据块超过定义的保留时间或定义的大小限制，Prometheus 将清除这些数据块。

  • 如果您定义了retentionSize的值但没有定义retention，则仅retentionSize值适用。

  • 如果您没有定义retentionSize的值，而只定义了retention的值，则仅retention值适用。

  • 如果您将retentionSize或retention的值设置为0，则应用默认设置。默认设置将核心平台监控的保留时间设置为 15 天，用户定义项目监控的保留时间设置为 24 小时。默认情况下，保留大小未设置。

数据压缩每两小时发生一次。因此，持久卷 (PV) 可能会在压缩之前填满，可能会超过retentionSize限制。在这种情况下，KubePersistentVolumeFillingUp警报将触发，直到 PV 上的空间低于retentionSize限制。
前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 编辑ConfigMap对象

    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（字节）、KB（千字节）、MB（兆字节）、GB（千兆字节）、TB（太字节）、PB（拍字节）或EB（艾字节）。

      以下示例将监控用户定义项目的 Prometheus 实例的保留时间设置为 24 小时，保留大小设置为 10 千兆字节。

      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 会自动重新部署。

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

默认情况下，对于用户定义的项目，Thanos Ruler 会自动保留 24 小时的指标数据。您可以修改保留时间以更改保留此数据的时间长度，方法是在openshift-user-workload-monitoring命名空间中的user-workload-monitoring-config ConfigMap 中指定时间值。

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 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 会自动重新部署。

其他资源

配置远程写入存储

您可以配置远程写入存储以使 Prometheus 能够将摄取的指标发送到远程系统以进行长期存储。这样做不会影响 Prometheus 如何或多长时间存储指标。

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

  • 您已设置了与远程写入兼容的端点（例如 Thanos），并且知道端点 URL。有关与远程写入功能兼容的端点的信息，请参阅Prometheus 远程端点和存储文档。

    Red Hat 仅提供有关配置远程写入发送者的信息，而不提供有关配置接收器端点的指导。客户负责设置他们自己的与远程写入兼容的端点。Red Hat 生产支持不包含端点接收器配置问题。

  • 您已在openshift-user-workload-monitoring命名空间中为远程写入端点设置了Secret对象中的身份验证凭据。您必须在openshift-user-workload-monitoring命名空间中创建密钥。

    为了降低安全风险，请使用 HTTPS 和身份验证将指标发送到端点。
步骤

  1. 编辑ConfigMap对象

    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:部分，如下例所示。

      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 Signature Version 4、使用 HTTP 和Authorization请求头的身份验证、基本身份验证、OAuth 2.0 和 TLS 客户端。有关支持的身份验证方法的示例配置，请参见下面的“支持的远程写入身份验证设置”。

    3. 在身份验证凭据之后添加写入重标记配置值。

      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:
        - <your_write_relabel_configs> (1)
      1 添加要发送到远程端点的指标的配置。
      转发名为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
      转发my_namespace命名空间中名为my_metric_1和my_metric_2的指标的示例。
      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__,namespace]
          regex: '(my_metric_1|my_metric_2);my_namespace'
          action: keep

  2. 保存文件以应用更改。新配置会自动应用。

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

您可以使用不同的方法来验证远程写入端点。目前支持的认证方法包括 AWS Signature Version 4、基本认证、授权、OAuth 2.0 和 TLS 客户端。下表详细介绍了支持的用于远程写入的认证方法。

认证方法 配置映射字段 描述

AWS Signature Version 4

sigv4

此方法使用 AWS Signature Version 4 认证来签名请求。您不能同时使用此方法和授权、OAuth 2.0 或基本认证。

基本认证

basicAuth

基本认证使用配置的用户名和密码在每个远程写入请求中设置授权头。

授权

授权

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

OAuth 2.0

oauth2

OAuth 2.0 配置使用客户端凭据授权类型。Prometheus 使用指定的客户端 ID 和客户端密钥从tokenUrl 获取访问令牌以访问远程写入端点。您不能同时使用此方法和授权、AWS Signature Version 4 或基本认证。

TLS 客户端

tlsConfig

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

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

以下示例显示了您可以用来连接到远程写入端点的不同身份验证设置。每个示例还显示了如何配置相应的Secret 对象，其中包含身份验证凭据和其他相关设置。每个示例都配置了在openshift-user-workload-monitoring命名空间中用于监控用户定义项目的身份验证。

AWS Signature Version 4 身份验证的 YAML 示例

以下显示了openshift-user-workload-monitoring命名空间中名为sigv4-credentials 的sigv4 密钥的设置。

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

以下显示了使用openshift-user-workload-monitoring命名空间中名为sigv4-credentials 的Secret 对象的 AWS Signature Version 4 远程写入身份验证设置示例。

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      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 (2)
            key: secretKey (4)
          profile: <AWS_profile_name> (5)
          roleArn: <AWS_role_arn> (6)
1 AWS 区域。
2 包含 AWS API 访问凭据的Secret 对象的名称。
3 在指定的Secret 对象中包含 AWS API 访问密钥的密钥。
4 在指定的Secret 对象中包含 AWS API 密钥的密钥。
5 正在用于身份验证的 AWS 配置文件的名称。
6 分配给您的角色的 Amazon 资源名称 (ARN) 的唯一标识符。

基本身份验证的 YAML 示例

以下显示了openshift-user-workload-monitoring命名空间中名为rw-basic-auth 的Secret 对象的基本身份验证设置示例。

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

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

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

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

以下显示了openshift-user-workload-monitoring命名空间中名为rw-bearer-auth 的Secret 对象的 bearer 令牌设置。

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

以下显示了使用openshift-user-workload-monitoring命名空间中名为rw-bearer-auth 的Secret 对象的 bearer 令牌配置映射设置示例。

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    enableUserWorkload: true
    prometheus:
      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 对象中包含身份验证令牌的密钥。

OAuth 2.0 身份验证的 YAML 示例

以下显示了openshift-user-workload-monitoring命名空间中名为oauth2-credentials 的Secret 对象的 OAuth 2.0 设置示例。

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

以下显示了一个oauth2 远程写入身份验证示例配置，该配置使用openshift-user-workload-monitoring命名空间中名为oauth2-credentials 的Secret 对象。

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

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

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

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

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

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"
        tlsConfig:
          ca:
            secret:
              name: mtls-bundle (1)
              key: ca.crt (2)
          cert:
            secret:
              name: mtls-bundle (1)
              key: client.crt (3)
          keySecret:
            name: mtls-bundle (1)
            key: client.key (4)
1 包含 TLS 身份验证凭据的相应Secret 对象的名称。请注意，ca 和cert 可以选择性地引用ConfigMap 对象，但keySecret 必须引用Secret 对象。
2 指定的Secret 对象中包含端点 CA 证书的密钥。
3 指定的Secret 对象中包含端点客户端证书的密钥。
4 指定的Secret 对象中包含客户端密钥密钥的密钥。

远程写入队列配置示例

您可以使用queueConfig 对象来微调远程写入的远程写入队列参数。以下示例显示了在openshift-user-workload-monitoring命名空间中监控用户定义项目的队列参数及其默认值。

远程写入参数的默认值配置示例
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>
        queueConfig:
          capacity: 10000 (1)
          minShards: 1 (2)
          maxShards: 50 (3)
          maxSamplesPerSend: 2000 (4)
          batchSendDeadline: 5s (5)
          minBackoff: 30ms (6)
          maxBackoff: 5s (7)
          retryOnRateLimit: false (8)
          sampleAgeLimit: 0s (9)
1 在从队列中删除之前，每个分片要缓冲的样本数量。
2 分片的最小数量。
3 分片的最大数量。
4 每次发送的最大样本数。
5 样本在缓冲区中等待的最大时间。
6 重试失败请求之前的初始等待时间。对于每次重试，时间都会加倍，直到达到maxbackoff 时间。
7 重试失败请求之前的最大等待时间。
8 从远程写入存储接收 429 状态代码后，将此参数设置为true 以重试请求。
9 旧于sampleAgeLimit 限制的样本将从队列中删除。如果值未定义或设置为0s，则忽略此参数。
其他资源

向指标添加集群 ID 标签

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

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

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

  • 配置远程写入存储的写入重标签设置。

  • 向指标添加集群 ID 标签。

  • 查询这些标签以识别指标的源集群或客户。

创建指标的集群 ID 标签

您可以通过编辑openshift-user-workload-monitoring命名空间中user-workload-monitoring-config配置映射中的设置来为指标创建集群 ID 标签。

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

  • 您已配置远程写入存储。

步骤

  1. 编辑ConfigMap对象

    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 替换发送到远程写入端点的指标的标签配置。

      以下示例显示如何在用户工作负载监控中转发带有集群 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写入重标签操作将临时标签替换为传出指标的目标标签。此操作是默认操作，如果未指定操作，则会应用此操作。

  2. 保存文件以应用更改。新配置会自动应用。

其他资源

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

开发人员可以创建标签以键值对的形式定义指标的属性。潜在的键值对的数量对应于属性的可能值的个数。具有无限数量潜在值的属性称为未绑定属性。例如，customer_id属性是未绑定的，因为它具有无限数量的可能值。

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

dedicated-admin可以使用以下措施来控制用户定义项目中未绑定指标属性的影响

  • 限制用户定义项目中每个目标抓取可以接受的样本数量

  • 限制抓取的标签数量、标签名称的长度和标签值的长度

  • 创建在达到抓取样本阈值或无法抓取目标时触发的警报

限制抓取样本可以帮助防止由于向标签添加许多未绑定属性而导致的问题。开发人员还可以通过限制为指标定义的未绑定属性的数量来防止根本原因。使用绑定到有限可能值集的属性可以减少潜在键值对组合的数量。

为用户定义的项目设置抓取样本和标签限制

您可以限制用户定义项目中每个目标抓取可以接受的样本数量。您还可以限制抓取的标签数量、标签名称的长度和标签值的长度。

如果设置了样本或标签限制，则达到限制后，不会再为该目标抓取摄取样本数据。
前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 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. 将enforcedSampleLimit配置添加到data/config.yaml以限制用户定义项目中每个目标抓取可以接受的样本数量。

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      enforcedSampleLimit: 50000 (1)
    1 如果指定此参数，则需要一个值。此enforcedSampleLimit示例将用户定义项目中每个目标抓取可以接受的样本数量限制为 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. 保存文件以应用更改。限制会自动应用。

配置外部 Alertmanager 实例

OpenShift Dedicated 监控堆栈包括一个本地 Alertmanager 实例，该实例路由来自 Prometheus 的警报。您可以添加外部 Alertmanager 实例来路由用户定义项目的警报。

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

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 编辑ConfigMap 对象。

    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 组件之一：prometheus或thanosRuler。

      对于<alertmanager_specification>，请替换其他 Alertmanager 实例的身份验证和其他配置详细信息。当前支持的身份验证方法是令牌 (bearerToken) 和客户端 TLS (tlsConfig)。以下示例配置映射使用带有令牌和客户端 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 会自动重新部署。

为 Alertmanager 配置密钥

OpenShift Dedicated 监控堆栈包括 Alertmanager，它将来自 Prometheus 的警报路由到端点接收器。如果您需要对接收器进行身份验证以便 Alertmanager 可以向其发送警报，则可以将 Alertmanager 配置为使用包含接收器身份验证凭据的密钥。

例如，您可以配置 Alertmanager 使用密钥来验证需要由私有证书颁发机构 (CA) 颁发的证书的端点接收器。您还可以配置 Alertmanager 使用密钥来验证需要 Basic HTTP 身份验证的密码文件的接收器。在这两种情况下，身份验证详细信息都包含在Secret对象中，而不是在ConfigMap对象中。

向 Alertmanager 配置添加密钥

您可以通过编辑openshift-user-workload-monitoring项目中的user-workload-monitoring-config配置映射，为用户定义的项目添加 Alertmanager 配置的密钥。

将密钥添加到配置映射后，该密钥将作为卷安装在 Alertmanager Pod 的alertmanager容器内的/etc/alertmanager/secrets/<secret_name>。

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已在openshift-user-workload-monitoring项目中创建了要在 Alertmanager 中配置的密钥。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 编辑ConfigMap 对象。

    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 的密钥。密钥必须位于与 Alertmanager 对象相同的命名空间中。
      2 包含接收器的身份验证凭据的Secret对象的名称。如果添加多个密钥，请将每个密钥放在新的一行。

      以下示例配置映射设置将 Alertmanager 配置为使用名为test-secret和test-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. 保存文件以应用更改。新配置会自动应用。

向时间序列和警报附加额外的标签

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

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 编辑ConfigMap对象

    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作为键名，因为它们是保留的，并将被覆盖。

      • 不要使用cluster或managed_cluster作为键名。使用它们可能会导致您无法在开发者仪表盘中查看数据的问题。

      在openshift-user-workload-monitoring项目中，Prometheus 处理指标，Thanos Ruler 处理警报和记录规则。在user-workload-monitoring-configConfigMap对象中为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 会自动重新部署。

使用 Pod 拓扑分布约束进行监控

当 OpenShift Dedicated Pod 部署在多个可用区时，您可以使用 Pod 拓扑分布约束来控制用户定义监控的 Pod 如何跨网络拓扑分布。

Pod 拓扑分布约束适用于控制分层拓扑中的 Pod 调度，在分层拓扑中，节点分布在不同的基础设施级别，例如这些区域内的区域和区域。此外，能够在不同的区域调度 Pod，可以在某些情况下提高网络延迟。

其他资源

配置 Pod 拓扑分布约束

您可以为用户定义监控的所有 Pod 配置 Pod 拓扑分布约束，以控制 Pod 副本如何调度到跨区域的节点。这确保了 Pod 的高可用性并更有效地运行，因为工作负载分布在不同数据中心或分层基础设施区域的节点上。

您可以使用user-workload-monitoring-config配置映射来配置监控 Pod 的 Pod 拓扑分布约束。

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

步骤

  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指定一个值。可用选项为DoNotSchedule和ScheduleAnyway。如果您希望maxSkew值定义目标拓扑中匹配 Pod 数量与全局最小值之间允许的最大差异，则指定DoNotSchedule。如果您希望调度程序仍然调度 Pod，但要优先考虑可能减少偏差的节点，则指定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 会自动重新部署。

设置监控组件的日志级别

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

以下日志级别可以应用于user-workload-monitoring-configConfigMap对象中的相关组件

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

  • info。记录信息、警告和错误消息。

  • warn。仅记录警告和错误消息。

  • error。仅记录错误消息。

默认日志级别为info。

前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 编辑ConfigMap对象

    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 您正在为其设置日志级别的监控堆栈组件。对于用户工作负载监控，可用的组件值为alertmanager、prometheus、prometheusOperator和thanosRuler。
      2 要应用于组件的日志级别。可用值为error、warn、info和debug。默认值为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 可能无法成功重启。

启用 Prometheus 的查询日志文件

您可以配置 Prometheus 将引擎运行的所有查询写入日志文件。

由于不支持日志轮转，因此仅在需要排查问题时临时启用此功能。排查问题完成后，请通过恢复对ConfigMap对象的更改（这些更改用于启用此功能）来禁用查询日志记录。
前提条件

  • 您具有作为具有dedicated-admin 角色的用户访问集群的权限。

  • user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。

  • 您已安装 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下的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>

    检查完已记录的查询信息后，恢复配置文件中的设置。