配置监控堆栈

监控的维护和支持
- 监控的支持注意事项
- 监控组件的支持版本矩阵
配置监控堆栈
可配置的监控组件
使用节点选择器移动监控组件
- 节点选择器如何与其他约束一起工作
- 将监控组件移动到不同的节点
为监控组件分配容忍度
管理监控组件的 CPU 和内存资源
- 关于为监控组件指定限制和请求
- 为监控组件指定限制和请求
配置持久性存储
配置远程写入存储
向指标添加集群 ID 标签
- 为指标创建集群 ID 标签
控制用户定义项目中未绑定指标属性的影响
- 为用户定义项目设置抓取样本和标签限制
配置外部 Alertmanager 实例
为 Alertmanager 配置密钥
- 向 Alertmanager 配置添加密钥
将附加标签附加到您的时间序列和警报
对监控使用 pod 拓扑传播约束
- 配置 pod 拓扑传播约束
设置监控组件的日志级别
为 Prometheus 启用查询日志文件

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

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

监控的维护和支持

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

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

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

编辑

监控的支持注意事项

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

以下修改明确不受支持

在 Red Hat OpenShift Service on AWS 上安装自定义 Prometheus 实例。自定义实例是由 Prometheus Operator 管理的自定义 Prometheus 资源 (CR)。
修改默认平台监控组件。您不应修改cluster-monitoring-config配置映射中定义的任何组件。Red Hat SRE 使用这些组件来监控核心集群组件和 Kubernetes 服务。

编辑

监控组件的支持版本矩阵

下表包含有关 Red Hat OpenShift Service on AWS 4.12 和更高版本中监控组件版本的信息

表 1. Red Hat OpenShift Service on AWS 和组件版本
Red Hat OpenShift Service on AWS	Prometheus Operator	Prometheus	Metrics Server	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 特定的组件。因此，它们的版本与 Red Hat OpenShift Service on AWS 的版本相对应。

编辑

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

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。

步骤

编辑ConfigMap对象。

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

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

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

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

Pod不会重新部署。因此，不会出现服务中断。
受影响的Pod将重新部署。
- 对于单节点集群，这会导致短暂的服务中断。
- 对于多节点集群，由于高可用性，受影响的Pod会逐渐推出，监控堆栈仍然可用。
- 配置和调整持久卷的大小总是会导致服务中断，无论是否具有高可用性。

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

其他资源

user-workload-monitoring-config配置映射的配置参考 user-workload-monitoring-config

编辑

可配置的监控组件

此表显示了您可以配置的监控组件以及用于在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)。

步骤

如果您尚未这样做，请向您要在其上运行监控组件的节点添加标签。
```
$ oc label nodes <node-name> <node-label>
```

编辑ConfigMap对象。

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

为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 事件中与污点和容忍度相关的错误。

保存文件以应用更改。新配置中指定的组件将自动移动到新节点，并且受新配置影响的 Pod 将重新部署。

其他资源

有关nodeSelector约束的详细信息，请参阅Kubernetes 文档

编辑

为监控组件分配容忍度

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

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap对象存在于openshift-user-workload-monitoring命名空间中。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。

步骤

编辑ConfigMap对象。

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

为组件指定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的污点。这会阻止监控组件部署 Pod 到node1，除非为此污点配置了容忍度。以下示例配置了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"

保存文件以应用更改。受新配置影响的 Pod 将自动重新部署。

其他资源

请参阅Kubernetes 文档，了解污点和容忍度。

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

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

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

编辑

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

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

Alertmanager（用于核心平台监控和用户定义的项目）
kube-state-metrics
监控插件
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` ConfigMap 中。

先决条件

如果您正在配置核心平台监控组件:
- 您需要以具有 `cluster-admin` 集群角色的用户身份访问集群。
- 您已创建名为 `cluster-monitoring-config` 的 `ConfigMap` 对象。
如果您正在配置监控用户定义项目的组件:
- 您需要以具有 `cluster-admin` 集群角色的用户身份访问集群，或者以在 `openshift-user-workload-monitoring` 项目中具有 `user-workload-monitoring-config-edit` 角色的用户身份访问集群。
您已安装 OpenShift CLI (oc)。

步骤

要配置核心平台监控组件，请编辑 `openshift-monitoring` 命名空间中的 `cluster-monitoring-config` ConfigMap 对象。
```
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
```

添加值以定义要配置的每个核心平台监控组件的资源限制和请求。

确保为限制设置的值始终高于为请求设置的值。否则，将会发生错误，并且容器将无法运行。

示例

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

保存文件以应用更改。受新配置影响的 Pod 将自动重新部署。

其他资源

Kubernetes 请求和限制文档

配置持久化存储

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

通过将指标和告警数据存储在持久卷 (PV) 中来保护您的数据免受数据丢失的影响。因此，它们可以在 Pod 重启或重新创建后继续存在。
避免在 Alertmanager Pod 重启时出现重复通知和丢失告警静默。

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

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

编辑

持久化存储先决条件

使用块类型存储。

编辑

配置持久卷声明

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

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。

步骤

编辑ConfigMap对象。

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

在 `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` 组件的存储需求取决于要评估的规则数量以及每个规则生成的样本数量。

保存文件以应用更改。受新配置影响的 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)。

步骤

编辑ConfigMap对象。

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

在 `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

保存文件以应用更改。受新配置影响的 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)。

步骤

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

在 `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

保存文件以应用更改。受新配置影响的 Pod 将自动重新部署。

其他资源

了解持久性存储

编辑

配置远程写入存储

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

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。

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

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

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

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

步骤

编辑ConfigMap对象。

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

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

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

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

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

编辑

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

您可以使用不同的方法来验证远程写入端点。当前支持的身份验证方法包括AWS Signature Version 4、基本身份验证、授权、OAuth 2.0和TLS客户端。下表提供了有关支持的远程写入身份验证方法的详细信息。

身份验证方法 ConfigMap字段描述

身份验证方法	ConfigMap字段	描述
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客户端配置指定CA证书、客户端证书和客户端密钥文件信息，用于使用TLS验证远程写入端点服务器。示例配置假设您已创建CA证书文件、客户端证书文件和客户端密钥文件。

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客户端配置指定CA证书、客户端证书和客户端密钥文件信息，用于使用TLS验证远程写入端点服务器。示例配置假设您已创建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	密码。

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

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

身份验证令牌。

以下显示了使用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密钥。

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

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

以下显示了名为mtls-bundle的tls Secret对象（位于openshift-user-workload-monitoring命名空间中）的示例 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	客户端密钥。

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

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`，则忽略该参数。

其他资源

设置与远程写入兼容的端点（Prometheus 文档）
调整远程写入设置（Prometheus 文档）

编辑

向指标添加集群 ID 标签

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

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

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

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

编辑

为指标创建集群 ID 标签

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

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。
您已配置远程写入存储。

步骤

编辑ConfigMap对象。

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

在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`写入重标记操作将临时标签替换为传出指标的目标标签。此操作是默认操作，如果未指定操作，则会应用此操作。

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

其他资源

配置远程写入存储

编辑

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

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

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

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

限制用户定义项目中每个目标抓取可以接受的样本数量
限制抓取的标签数量、标签名称的长度和标签值的长度
创建在达到抓取样本阈值或无法抓取目标时触发的警报。

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

编辑

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

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

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

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。

步骤

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```
将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。

将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`，表示没有限制。

保存文件以应用更改。限制会自动应用。

编辑

配置外部Alertmanager实例

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

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

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。

步骤

编辑ConfigMap对象。

编辑openshift-user-workload-monitoring项目中的user-workload-monitoring-config配置映射。
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```
在data/config.yaml/下添加一个<component>/additionalAlertmanagerConfigs:部分。

在此部分中添加其他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)。以下示例配置映射使用带有Bearer令牌和客户端TLS身份验证的Thanos Ruler配置其他Alertmanager。

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    thanosRuler:
      additionalAlertmanagerConfigs:
      - scheme: https
        pathPrefix: /
        timeout: "30s"
        apiVersion: v1
        bearerToken:
          name: alertmanager-bearer-token
          key: token
        tlsConfig:
          key:
            name: alertmanager-tls
            key: tls.key
          cert:
            name: alertmanager-tls
            key: tls.crt
          ca:
            name: alertmanager-tls
            key: tls.ca
        staticConfigs:
        - external-alertmanager1-remote.com
        - external-alertmanager1-remote2.com

保存文件以应用更改。受新配置影响的 Pod 将自动重新部署。

编辑

配置Alertmanager的密钥

AWS上的Red Hat OpenShift服务监控堆栈包含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)。

步骤

编辑ConfigMap对象。

编辑openshift-user-workload-monitoring项目中的user-workload-monitoring-config配置映射。
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

在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

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

编辑

将附加标签附加到您的时间序列和警报

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

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。

步骤

编辑ConfigMap对象。

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

在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

保存文件以应用更改。受新配置影响的 Pod 将自动重新部署。

编辑

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

当AWS上的Red Hat OpenShift服务Pod部署在多个可用区时，您可以使用Pod拓扑分布约束来控制用户定义监控的Pod如何在网络拓扑中分布。

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

其他资源

Kubernetes Pod拓扑分布约束文档

编辑

配置Pod拓扑分布约束

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

您可以使用user-workload-monitoring-config 配置映射来为监控 Pod 配置 Pod topology spread 约束。

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。

步骤

编辑openshift-user-workload-monitoring项目中的user-workload-monitoring-config配置映射。
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

在data/config.yaml字段下添加以下设置以配置 Pod topology spread 约束

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 topology spread 约束的组件名称。
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

保存文件以应用更改。受新配置影响的 Pod 将自动重新部署。

编辑

设置监控组件的日志级别

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

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

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

默认日志级别为info。

先决条件

您可以作为具有dedicated-admin角色的用户访问集群。
user-workload-monitoring-config ConfigMap 对象存在。此对象在创建集群时默认创建。
您已安装 OpenShift CLI (oc)。

步骤

编辑ConfigMap对象。

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

为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`。

保存文件以应用更改。受新配置影响的 Pod 将自动重新部署。
通过查看相关项目中的部署或 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
```
检查组件的 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)。

步骤

在openshift-user-workload-monitoring项目中编辑user-workload-monitoring-config ConfigMap对象
```
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
```

为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	将查询记录到的文件的完整路径。

保存文件以应用更改。受新配置影响的 Pod 将自动重新部署。
验证组件的 Pod 是否正在运行。以下示例命令列出了openshift-user-workload-monitoring项目中 Pod 的状态
```
$ oc -n openshift-user-workload-monitoring get pods
```

读取查询日志

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

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

配置监控堆栈

监控的维护和支持

监控的支持注意事项

监控组件的支持版本矩阵