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

配置监控堆栈

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

本节解释了支持哪些配置，展示了如何配置监控堆栈，并演示了一些常见的配置场景。

并非所有监控堆栈的配置参数都已公开。仅支持集群监控操作员配置参考中列出的参数和字段进行配置。

先决条件

  • 监控堆栈会带来额外的资源需求。请查阅集群监控操作员的扩展中的计算资源建议，并验证您是否拥有足够的资源。

监控的维护和支持

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

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

监控的支持注意事项

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

明确不支持以下修改

  • 在openshift-*和kube-*项目中创建额外的ServiceMonitor、PodMonitor和PrometheusRule对象。

  • 修改openshift-monitoring或openshift-user-workload-monitoring项目中部署的任何资源或对象。OpenShift Container Platform 监控堆栈创建的资源并非旨在被任何其他资源使用，因为它们的向后兼容性没有保证。

    Alertmanager 配置作为openshift-monitoring命名空间中的alertmanager-main密钥资源部署。如果您已为用户定义的告警路由启用单独的 Alertmanager 实例，则 Alertmanager 配置也会作为openshift-user-workload-monitoring命名空间中的alertmanager-user-workload密钥资源部署。要为任何 Alertmanager 实例配置其他路由，您需要解码、修改，然后编码该密钥。此过程是前面声明的支持例外。

  • 修改堆栈的资源。OpenShift Container Platform 监控堆栈确保其资源始终处于其期望的状态。如果修改了资源，堆栈将重置它们。

  • 将用户定义的工作负载部署到openshift-*和kube-*项目。这些项目保留给 Red Hat 提供的组件，不应用于用户定义的工作负载。

  • 通过在 Prometheus Operator 中使用Probe自定义资源定义 (CRD) 来启用基于症状的监控。

  • 手动将监控资源部署到具有openshift.io/cluster-monitoring: "true"标签的命名空间。

  • 向命名空间添加openshift.io/cluster-monitoring: "true"标签。此标签仅保留给具有核心 OpenShift Container Platform 组件和 Red Hat 认证组件的命名空间。

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

监控操作员的支持策略

监控操作员确保 OpenShift Container Platform 监控资源按设计和测试运行。如果覆盖了集群版本操作员 (CVO) 对操作员的控制，则操作员不会响应配置更改、协调集群对象的预期状态或接收更新。

虽然在调试期间覆盖 CVO 对操作员的控制可能很有帮助，但这不受支持，集群管理员承担单个组件配置和升级的全部控制。

覆盖集群版本操作员

可以将spec.overrides参数添加到 CVO 的配置中，以允许管理员为组件提供 CVO 行为的覆盖列表。将组件的spec.overrides[].unmanaged参数设置为true会阻止集群升级，并在设置 CVO 覆盖后提醒管理员。

Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.

设置 CVO 覆盖会使整个集群处于不受支持的状态，并阻止监控堆栈协调到其预期状态。这会影响内置于操作员中的可靠性功能，并阻止接收更新。必须在删除任何覆盖后重现报告的问题，才能继续进行支持。

监控组件的支持版本矩阵

以下矩阵包含有关 OpenShift Container Platform 4.12 及更高版本中监控组件版本的信息

表 1. OpenShift Container Platform 和组件版本
OpenShift Container Platform Prometheus 操作员 Prometheus 指标服务器 Alertmanager kube-state-metrics 代理 监控插件 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 客户端是 OpenShift 特定的组件。因此，它们的版本与 OpenShift Container Platform 的版本相对应。

准备配置监控堆栈

您可以通过创建和更新监控配置映射来配置监控堆栈。这些配置映射配置集群监控操作员 (CMO)，后者反过来配置监控堆栈的组件。

创建集群监控配置映射

您可以通过在openshift-monitoring项目中创建cluster-monitoring-config ConfigMap对象来配置核心 OpenShift Container Platform 监控组件。然后，集群监控操作员 (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

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

您可以使用openshift-user-workload-monitoring项目中的user-workload-monitoring-config ConfigMap对象配置用户工作负载监控组件。然后，集群监控操作员 (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对象的配置，除非集群管理员已启用对用户定义项目的监控，否则不会激活。
更多资源

授予用户核心平台监控权限

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

您还可以为核心平台监控授予开发人员和其他用户不同的权限。您可以通过分配以下监控角色或集群角色之一来授予权限

名称 描述 项目

cluster-monitoring-metrics-api

拥有此角色的用户可以访问 Thanos Querier API 端点。此外，它还允许访问核心平台 Prometheus API 和用户定义的 Thanos Ruler API 端点。

openshift-monitoring

cluster-monitoring-operator-alert-customization

拥有此角色的用户可以管理核心平台监控的AlertingRule和AlertRelabelConfig资源。这些权限对于警报自定义功能是必需的。

openshift-monitoring

monitoring-alertmanager-edit

拥有此角色的用户可以管理核心平台监控的 Alertmanager API。他们还可以在 OpenShift Container Platform Web 控制台的**管理员**视角中管理警报静默。

openshift-monitoring

monitoring-alertmanager-view

拥有此角色的用户可以监控核心平台监控的 Alertmanager API。他们还可以在 OpenShift Container Platform Web 控制台的**管理员**视角中查看警报静默。

openshift-monitoring

cluster-monitoring-view

拥有此集群角色的用户具有与cluster-monitoring-metrics-api角色相同的访问权限，并具有其他权限，可以访问用户定义的 Prometheus 的/federate端点。

必须与ClusterRoleBinding绑定才能访问用户定义的 Prometheus 的/federate端点。
更多资源

配置监控堆栈

在 OpenShift Container Platform 4.17 中，您可以使用cluster-monitoring-config或user-workload-monitoring-config ConfigMap对象配置监控堆栈。ConfigMap 配置集群监控操作员 (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. 在data/config.yaml下添加您的配置，作为键值对<component_name>: <component_configuration>

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

        在cluster-monitoring-config ConfigMap对象中，Prometheus config map 组件称为prometheusK8s，在user-workload-monitoring-config ConfigMap对象中称为prometheus。

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

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

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

    • 受影响的 Pod 将重新部署

      • 对于单节点集群，这会导致短暂的服务中断。

      • 对于多节点集群，由于高可用性，受影响的 Pod 会逐渐推出，监控堆栈仍然可用。

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

    每个需要更改 config map 的过程都包含其预期结果。
更多资源

可配置的监控组件

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

表 2. 可配置的监控组件
组件 cluster-monitoring-config config map 键 user-workload-monitoring-config config map 键

Prometheus 操作员

prometheusOperator

prometheusOperator

Prometheus

prometheusK8s

prometheus

Alertmanager

alertmanagerMain

alertmanager

kube-state-metrics

kubeStateMetrics

监控插件

monitoringPlugin

openshift-state-metrics

openshiftStateMetrics

Telemeter 客户端

telemeterClient

指标服务器

metricsServer

Thanos Querier

thanosQuerier

Thanos Ruler

thanosRuler

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

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

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

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

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

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

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

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

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

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

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

更多资源

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

要指定集群中监控堆栈组件将运行的节点，请在组件的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 将重新部署。

更多资源

为监控组件分配容忍度

您可以为任何监控堆栈组件分配容忍度，以使其能够移动到被污染的节点。

先决条件

  • 如果您正在配置核心 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向node1添加一个具有键key1和值value1的污点。除非为该污点配置了容忍度，否则这将阻止监控组件在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向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 将自动重新部署。

更多资源

设置指标抓取的正文大小限制

默认情况下，从已抓取的指标目标返回的数据的未压缩正文大小没有限制。您可以设置正文大小限制，以帮助避免在已抓取的目标返回包含大量数据的响应时 Prometheus 消耗过多内存的情况。此外，通过设置正文大小限制，您可以减少恶意目标可能对 Prometheus 和整个集群的影响。

设置enforcedBodySizeLimit的值后，当至少一个 Prometheus 抓取目标回复的响应正文大于配置的值时，警报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. 向data/config.yaml/prometheusK8s添加enforcedBodySizeLimit的值，以限制每个目标抓取可以接受的正文大小

    apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |-
    prometheusK8s:
      enforcedBodySizeLimit: 40MB (1)
    1 指定已抓取指标目标的最大正文大小。此enforcedBodySizeLimit示例将每个目标抓取的未压缩大小限制为 40 MB。有效数值使用 Prometheus 数据大小格式：B（字节）、KB（千字节）、MB（兆字节）、GB（千兆字节）、TB（太字节）、PB（拍字节）和 EB（艾字节）。默认值为0，表示没有限制。您也可以将值设置为automatic，以根据集群容量自动计算限制。

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

更多资源

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

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

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

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

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

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

  • kube-state-metrics

  • 监控插件

  • node-exporter

  • openshift-state-metrics

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

  • 指标服务器

  • Prometheus Operator 及其准入 Webhook 服务

  • Telemeter 客户端

  • 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 配置持久存储，以确保高可用性。

持久存储先决条件

  • 分配足够的持久存储，以确保磁盘不会充满。

  • 在配置持久卷时，将Filesystem用作volumeMode参数的存储类型值。

    • 不要使用原始块卷，在PersistentVolume资源中将其描述为volumeMode: Block。Prometheus 无法使用原始块卷。

    • Prometheus 不支持不符合 POSIX 标准的文件系统。例如，某些 NFS 文件系统实现不符合 POSIX 标准。如果您想使用 NFS 文件系统进行存储，请与供应商确认其 NFS 实现是否完全符合 POSIX 标准。

配置持久卷声明

要将持久卷 (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. 在data/config.yaml下添加组件的 PVC 配置。

        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 有关 PersistentVolumeClaims 的文档。

        以下示例配置了一个 PVC，该 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. 在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 有关 PersistentVolumeClaims 的文档。

        以下示例配置了一个 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、Thanos Ruler 或 Alertmanager）的持久卷 (PV) 大小。您需要手动扩展持久卷声明 (PVC)，然后更新配置组件的 ConfigMap。

您只能扩展 PVC 的大小。无法缩小存储大小。
先决条件

  • 您已安装 OpenShift CLI (oc)。

  • 如果您正在配置核心 OpenShift Container Platform 监控组件:

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

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

    • 您已为核心 OpenShift Container Platform 监控组件配置了至少一个 PVC。

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

    • 您可以作为具有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下添加组件的 PVC 配置的新存储大小。

        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 请求设置为 100 GB。

        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 请求设置为 20 GB。

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

    当您使用新的存储大小更新 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限制。
先决条件

  • 如果您正在配置核心 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（字节）、KB（千字节）、MB（兆字节）、GB（千兆字节）、TB（太字节）、PB（拍字节）和EB（艾字节）。

        以下示例将监控核心 OpenShift Container Platform 组件的 Prometheus 实例的保留时间设置为 24 小时，保留大小设置为 10 千兆字节

        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（字节）、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配置映射中指定时间值。

先决条件

  • 您可以作为具有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 将自动重新部署。

更多资源

配置远程写入存储

您可以配置远程写入存储，以使 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 远程端点和存储文档。

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

  • 您已在Secret对象中为远程写入端点设置了身份验证凭据。您必须在与配置远程写入的 Prometheus 对象相同的命名空间中创建密钥：默认平台监控的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:部分，如下例所示

        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、使用Authorization请求标头中的 HTTP 进行身份验证、基本身份验证、OAuth 2.0 和 TLS 客户端。有关支持的身份验证方法的示例配置，请参阅支持的远程写入身份验证设置。

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

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

    • 要为监控用户定义项目的 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:部分，如下例所示

        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 客户端。有关支持的身份验证方法的示例配置，请参阅下面的支持的远程写入身份验证设置。

      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 签名版本 4、基本身份验证、授权、OAuth 2.0 和 TLS 客户端。下表提供了有关支持的用于远程写入的身份验证方法的详细信息。

身份验证方法 Config map 字段 描述

AWS 签名版本 4

sigv4

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

基本身份验证

basicAuth

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

授权

授权

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

OAuth 2.0

oauth2

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

TLS 客户端

tlsConfig

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

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

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

AWS 签名版本 4 身份验证的 YAML 示例

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

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 密钥。

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

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 (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-monitoring命名空间中名为rw-basic-auth的Secret对象的示例基本身份验证设置。

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 密码。

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

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 (1)
            key: password (3)
1 包含身份验证凭据的Secret对象的名称。
2 在指定的Secret对象中包含用户名的密钥。
3 在指定的Secret对象中包含密码的密钥。

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

以下显示了openshift-monitoring命名空间中名为rw-bearer-auth的Secret对象的 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-auth的Secret对象的 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对象中包含身份验证令牌的密钥。

OAuth 2.0 身份验证的 YAML 示例

以下显示了openshift-monitoring命名空间中名为oauth2-credentials的Secret对象的 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 密钥。

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

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 (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-monitoring命名空间中名为mtls-bundle的tls 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 客户端密钥。

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

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 (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-monitoring命名空间中默认平台监控的默认值的队列参数。

远程写入参数的默认值配置示例
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>
        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 Container Platform 集群并使用远程写入功能将这些集群的指标数据发送到外部存储位置，则可以添加集群 ID 标签来标识来自不同集群的指标数据。然后，您可以查询这些标签以识别指标的源集群，并将该数据与其他集群发送的类似指标数据区分开来。

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

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

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

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

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

为指标创建集群 ID 标签

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

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

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

当 Prometheus 抓取公开namespace标签的用户工作负载目标时，系统会将此标签存储为exported_namespace。此行为确保最终的命名空间标签值等于目标 Pod 的命名空间。您不能通过将PodMonitor或ServiceMonitor对象的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写入重标签操作将临时标签替换为传出指标的目标标签。此操作为默认操作，如果未指定操作，则会应用此操作。

    • 要为用户定义的项目指标创建集群 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 替换发送到远程写入端点的指标的标签配置。

        以下示例显示如何在用户工作负载监控中使用集群 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. 保存文件以应用更改。新配置将自动应用。

更多资源

配置 Metrics Server 的审计日志

您可以配置 Metrics Server 的审计日志来帮助您排查服务器问题。审计日志记录集群中的一系列操作。它可以记录用户、应用程序或控制平面活动。

您可以设置审计日志规则，这些规则决定记录哪些事件以及它们应包含哪些数据。这可以通过以下审计配置文件实现：

  • 元数据（默认）：此配置文件启用事件元数据的日志记录，包括用户、时间戳、资源和动词。它不记录请求和响应正文。

  • 请求：这将启用事件元数据和请求正文的日志记录，但它不记录响应正文。此配置不适用于非资源请求。

  • 请求响应：这将启用事件元数据以及请求和响应正文的日志记录。此配置不适用于非资源请求。

  • 无：不记录前面描述的任何事件。

您可以通过修改cluster-monitoring-config配置映射来配置审计配置文件。以下示例将配置文件设置为Request，允许为 Metrics Server 记录事件元数据和请求正文

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    metricsServer:
      audit:
        profile: Request

配置指标收集配置文件

使用指标收集配置文件仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持，并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您提前访问即将推出的产品功能，使客户能够在开发过程中测试功能并提供反馈。

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

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

  • 如果集群管理员只需要警报、遥测和控制台指标，而不需要其他指标可用。

  • 如果集群规模扩大，并且现在收集的默认指标数据的规模增大需要显着增加 CPU 和内存资源。

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

关于指标收集配置文件

您可以启用以下两个指标收集配置文件之一：

  • full：Prometheus 收集所有平台组件公开的指标数据。此设置是默认设置。

  • minimal：Prometheus 仅收集平台警报、记录规则、遥测和控制台仪表板所需的指标数据。

选择指标收集配置文件

要为核心 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下添加指标收集配置文件设置。

    apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      collectionProfile: <metrics_collection_profile_name> (1)
    1 指标收集配置文件的名称。可用值为full或minimal。如果您未指定值，或者配置映射中不存在collectionProfile键名，则使用默认设置full。

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

    apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      collectionProfile: minimal

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

更多资源

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

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

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

集群管理员可以使用以下措施来控制用户定义项目中未绑定度量属性的影响：

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

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

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

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

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

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

如果设置了样本或标签限制，则达到限制后，将不会为该目标抓取摄取更多样本数据。
先决条件

  • 您可以作为具有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. 将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. 保存文件以应用更改。限制将自动应用。

创建抓取样本警报

您可以创建警报，在以下情况下通知您：

  • 目标无法抓取或在指定的 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_post_metric_relabeling / (scrape_sample_limit > 0)) > 0.9 (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 警报的阈值。在此示例中，当摄取的样本数量超过配置限制的 90% 时，警报将触发。
    10 ApproachingEnforcedSamplesLimit 警报的条件必须在此时长内为真，警报才会触发。
    11 定义 ApproachingEnforcedSamplesLimit 警报的严重性。

  2. 将配置应用于用户定义的项目。

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

  3. 此外，您可以检查目标是否已达到配置的限制。

    1. 在 Web 控制台的**管理员**视角中，转到**监控**→**目标**，然后选择要检查的具有已关闭状态的端点。

      如果端点由于超过样本限制而失败，则会显示**抓取失败：样本限制已超过**消息。

更多资源

配置外部 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 实例的身份验证和其他配置详细信息。当前支持的身份验证方法是令牌（bearerToken）和客户端 TLS（tlsConfig）。以下示例配置映射使用带有客户端 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 ConfigMap。

        $ 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实例的身份验证和其他配置详细信息。当前支持的身份验证方法是Bearer令牌 (bearerToken) 和客户端TLS (tlsConfig)。以下示例ConfigMap使用Thanos Ruler配置附加Alertmanager，并使用Bearer令牌和客户端TLS身份验证。

        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 Container Platform监控堆栈包括Alertmanager，它将来自Prometheus的警报路由到端点接收器。如果需要对接收器进行身份验证才能让Alertmanager向其发送警报，则可以将Alertmanager配置为使用包含接收器身份验证凭据的密钥。

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

向Alertmanager配置添加密钥

可以通过编辑openshift-monitoring项目中的cluster-monitoring-config ConfigMap，向核心平台监控组件的Alertmanager配置添加密钥。

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

先决条件

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

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

    • 您已创建cluster-monitoring-config配置映射。

    • 您已创建要在Alertmanager中配置的密钥，位于openshift-monitoring项目中。

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

    • 您可以作为具有cluster-admin集群角色的用户，或作为openshift-user-workload-monitoring项目中具有user-workload-monitoring-config-edit角色的用户访问集群。

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

    • 集群管理员已启用对用户定义项目的监控。

  • 您已安装 OpenShift CLI (oc)。

步骤

  1. 编辑ConfigMap对象。

    • 要向核心平台监控的Alertmanager添加密钥配置：:

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

        以下示例ConfigMap设置将Alertmanager配置为使用两个名为test-secret-basic-auth和test-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

    • 要向用户定义的项目监控的Alertmanager添加密钥配置：:

      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/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对象的名称。如果添加多个密钥，请将每个密钥放在新的一行。

        以下示例ConfigMap设置将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的所有时间序列和警报。

先决条件

  • 如果您正在配置核心 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作为键名，因为它们是保留的，并将被覆盖。

        • 不要使用cluster或managed_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作为键名，因为它们是保留的，并将被覆盖。

        • 不要使用cluster或managed_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 将自动重新部署。

更多资源

使用Pod拓扑扩散约束进行监控

当OpenShift Container Platform Pod部署在多个可用区时，可以使用Pod拓扑扩散约束来控制监控Pod如何在网络拓扑中分布。

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

更多资源

配置Pod拓扑扩散约束

可以为集群监控操作员部署的所有Pod配置Pod拓扑扩散约束，以控制Pod副本如何在区域内的节点上进行调度。这确保了Pod具有高可用性并运行效率更高，因为工作负载分布在不同数据中心或分层基础设施区域中的节点上。

可以使用cluster-monitoring-config或user-workload-monitoring-config ConfigMap为监控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的值。可用选项为DoNotSchedule和ScheduleAnyway。如果希望maxSkew值定义目标拓扑中匹配 Pod 数量与全局最小值之间允许的最大差异，则指定DoNotSchedule。如果希望调度程序仍然调度 Pod，但要优先考虑可能减少偏差的节点，则指定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 ConfigMap。

      $ 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 Querier 和 Thanos Ruler 的日志级别。

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

  • 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 您正在设置日志级别的监控堆栈组件。对于默认平台监控，可用的组件值为prometheusK8s、alertmanagerMain、prometheusOperator和thanosQuerier。
        2 要为组件设置的日志级别。可用值为error、warn、info和debug。默认值为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 您正在设置日志级别的监控堆栈组件。对于用户工作负载监控，可用的组件值为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对象所做的更改来禁用查询日志记录以启用此功能。
先决条件

  • 如果您正在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>

      检查完已记录的查询信息后，恢复配置映射中的设置。
更多资源

启用 Thanos Querier 的查询日志记录

对于openshift-monitoring项目中的默认平台监控，您可以启用集群监控操作符 (CMO) 来记录 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以禁用日志记录。默认值为false。
    2 将值设置为debug、info、warn或error。如果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以禁用查询日志记录。

更多资源
更多资源

禁用本地 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实例将自动禁用。

更多资源