流程

1. 编辑 ConfigMap 对象。

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

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

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. 将您的配置以键值对 <component_name>: <component_configuration> 的形式添加到 data/config.yaml 下：

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

        相应地替换 <component> 和 <configuration_for_the_component>。

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

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: fast
                  volumeMode: Filesystem
                  resources:
                    requests:
                      storage: 40Gi

        1

        定义 Prometheus 组件，后面几行则定义其配置。

   • 要配置用于监控用户定义的项目的组件：

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

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. 将您的配置以键值对 <component_name>: <component_configuration> 的形式添加到 data/config.yaml 下：

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

        相应地替换 <component> 和 <configuration_for_the_component>。

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

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus: 1
              retention: 24h 2
              resources:
                requests:
                  cpu: 200m 3
                  memory: 2Gi 4

        1

        定义 Prometheus 组件，后面几行则定义其配置。

        2

        为监控用户定义的项目的 Prometheus 实例配置 24 小时的数据保留周期。

        3

        为 Prometheus 容器定义最低 200 毫秒的资源请求。

        4

        为 Prometheus 容器定义最低 2 GiB 内存的 Pod 资源请求。

        注意

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

2. 保存文件以将更改应用到 ConfigMap 对象。受新配置影响的 Pod 会自动重启。

   注意

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

   警告

   一旦将更改保存到监控配置映射，可能会重新部署相关项目中的 Pod 和其他资源。该项目中正在运行的监控进程也可能被重启。

流程

1. 编辑 ConfigMap 对象：

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

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

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. 为组件指定 tolerations：

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

        相应地替换 <component> 和 <toleration_specification>。

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

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              tolerations:
              - key: "key1"
                operator: "Equal"
                value: "value1"
                effect: "NoSchedule"

   • 要将容限分配给监控用户定义的项目的组件：

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

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. 为组件指定 tolerations：

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

        相应地替换 <component> 和 <toleration_specification>。

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

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              tolerations:
              - key: "key1"
                operator: "Equal"
                value: "value1"
                effect: "NoSchedule"

2. 保存文件以使改变生效。这样就会自动应用新组件放置配置。

   注意

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

   警告

   一旦将更改保存到监控配置映射，可能会重新部署相关项目中的 Pod 和其他资源。该项目中正在运行的监控进程也可能被重启。

步骤

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

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. 将 enforcedBodySizeLimit 的值添加到 data/config.yaml/prometheusK8s 中，以限制每个目标提取可接受的正文大小：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |-
       prometheusK8s:
         enforcedBodySizeLimit: 40MB 1

   1

   指定提取指标目标的最大正文大小。这个 enforceBodySizeLimit 示例将每个目标提取的未压缩大小限制为 40MB。有效数字值使用 Prometheus 数据大小格式：B (bytes), KB (kilobytes), MB (megabytes), GB (gigabytes), TB (terabytes), PB (petabytes), and EB (exabytes)。默认值为 0，代表没有指定限制。您还可以将值设为 automatic，以根据集群容量自动计算限制。

3. 保存文件以自动应用更改。

   警告

   当您保存对 cluster-monitoring-config 配置映射的更改时，可能会重新部署 openshift-monitoring 项目中的 Pod 和其他资源。该项目中正在运行的监控进程可能会重启。

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

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. 在 data/config.yaml/prometheusK8s 下添加一个 remoteWrite: 部分。

3. 在本节中添加端点 URL 和身份验证凭证：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       prometheusK8s:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com" 1
           <endpoint_authentication_credentials> 2

   1

   远程写入端点的 URL。

   2

   端点的身份验证方法和凭据。目前支持的身份验证方法有 AWS 签名版本 4，使用 HTTP Authorization 请求标头、基本身份验证、OAuth 2.0 和 TLS 客户端进行身份验证。有关支持的身份验证方法示例配置，请参阅支持的远程写入身份验证设置。

4. 在身份验证凭证后添加 write relabel 配置值：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       prometheusK8s:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com"
           <endpoint_authentication_credentials>
           <your_write_relabel_configs> 1

   1

   写入重新标记配置设置。

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

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

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

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

5. 保存文件以将更改应用到 ConfigMap 对象。受新配置重启影响的 Pod 会自动重启。

   注意

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

   警告

   保存对监控 ConfigMap 对象的更改可能会重新部署相关项目中的 pod 和其他资源。保存更改还可能在该项目中重新启动正在运行的监控进程。

流程

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

   • 对于监控用户定义的项目的 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

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

   注意

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

   警告

   一旦将更改保存到监控配置映射，可能会重新部署相关项目中的 Pod 和其他资源。该项目中正在运行的监控进程也可能被重启。

流程

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

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. 在 data/config.yaml/prometheusK8s 下添加以下设置的值来配置 pod 拓扑分布限制：

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

   1

   为 maxSkew 指定数字值，它定义了允许不均匀分布 pod 的程度。此字段是必需的，值必须大于零。指定的值会根据您为 whenUnsatisfiable 指定的值的不同而有所不同。

   2

   为 topologyKey 指定节点标签键。此字段是必需的。带有具有此键和相同值标签的节点被视为在同一拓扑中。调度程序会尝试将大量 pod 放置到每个域中。

   3

   为 whenUnsatisfiable 指定一个值。此字段是必需的。可用选项包括 DoNotSchedule 和 ScheduleAnyway。如果您希望 maxSkew 值定义目标拓扑和全局最小值中匹配 pod 数量之间允许的最大值，则指定 DoNotSchedule。如果您希望调度程序仍然调度 pod，但为可能降低 skew 的节点赋予更高的优先级，请指定 ScheduleAnyway。

   4

   为 matchLabels 指定一个值。这个值用于标识要应用约束的匹配 pod 的集合。

3. 保存文件以自动应用更改。

   警告

   当您保存对 cluster-monitoring-config 配置映射的更改时，可能会重新部署 openshift-monitoring 项目中的 Pod 和其他资源。该项目中正在运行的监控进程可能会重启。

流程

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

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. 在 data/config.yaml/alertmanagermain 下添加以下设置的值来配置 pod 拓扑分布限制：

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

   1

   为 maxSkew 指定数字值，它定义了允许不均匀分布 pod 的程度。此字段是必需的，值必须大于零。指定的值会根据您为 whenUnsatisfiable 指定的值的不同而有所不同。

   2

   为 topologyKey 指定节点标签键。此字段是必需的。带有具有此键和相同值标签的节点被视为在同一拓扑中。调度程序会尝试将大量 pod 放置到每个域中。

   3

   为 whenUnsatisfiable 指定一个值。此字段是必需的。可用选项包括 DoNotSchedule 和 ScheduleAnyway。如果您希望 maxSkew 值定义目标拓扑和全局最小值中匹配 pod 数量之间允许的最大值，则指定 DoNotSchedule。如果您希望调度程序仍然调度 pod，但为可能降低 skew 的节点赋予更高的优先级，请指定 ScheduleAnyway。

   4

   为 matchLabels 指定一个值。这个值用于标识要应用约束的匹配 pod 的集合。

3. 保存文件以自动应用更改。

   警告

   当您保存对 cluster-monitoring-config 配置映射的更改时，可能会重新部署 openshift-monitoring 项目中的 Pod 和其他资源。该项目中正在运行的监控进程可能会重启。

步骤

1. 编辑 openshift-user-workload-monitoring 命名空间中的 user-workload-monitoring-config 配置映射：

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. 在 data/config.yaml/thanosRuler 下添加以下设置的值来配置 pod 拓扑分布限制：

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

   1

   为 maxSkew 指定数字值，它定义了允许不均匀分布 pod 的程度。此字段是必需的，值必须大于零。指定的值会根据您为 whenUnsatisfiable 指定的值的不同而有所不同。

   2

   为 topologyKey 指定节点标签键。此字段是必需的。带有具有此键和相同值标签的节点被视为在同一拓扑中。调度程序会尝试将大量 pod 放置到每个域中。

   3

   为 whenUnsatisfiable 指定一个值。此字段是必需的。可用选项包括 DoNotSchedule 和 ScheduleAnyway。如果您希望 maxSkew 值定义目标拓扑和全局最小值中匹配 pod 数量之间允许的最大值，则指定 DoNotSchedule。如果您希望调度程序仍然调度 pod，但为可能降低 skew 的节点赋予更高的优先级，请指定 ScheduleAnyway。

   4

   为 matchLabels 指定一个值。这个值用于标识要应用约束的匹配 pod 的集合。

3. 保存文件以自动应用更改。

   警告

   当您将更改保存到 user-workload-monitoring-config 配置映射时，可能会重新部署 openshift-user-workload-monitoring 项目中的 Pod 和其他资源。该项目中正在运行的监控进程可能会重启。

流程

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

        您要为其设置日志级别的监控堆栈组件。对于用户工作负载监控，可用组件值包括 prometheus、prometheusOperator 和 thanosRuler。

        2

        为组件设置的日志级别。可用值为 error、warn、info 和 debug。默认值为 info。

2. 保存文件以使改变生效。应用日志级别更改时，组件的 Pod 会自动重启。

   注意

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

   警告

   一旦将更改保存到监控配置映射，可能会重新部署相关项目中的 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 可能无法成功重启。

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

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. 在 data/config.yaml 中添加 thanosQuerier 部分并添加值，如下例所示：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       thanosQuerier:
         enableRequestLogging: <value> 1
         logLevel: <value> 2

   1

   将值设为 true 以启用日志记录，并将 false 设置为 disable logging。默认值为 false。

   2

   将值设为 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 来禁用查询日志记录。

流程

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 实例会自动禁用。

流程

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

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. 将 enableUserWorkload: true 添加到 data/config.yaml 下：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       enableUserWorkload: true 1

   1

   当设置为 true 时，enableUserWorkload 参数为集群中用户定义的项目启用监控。

3. 保存文件以使改变生效。然后会自动启用对用户定义的项目的监控。

   警告

   将更改保存到 cluster-monitoring-config ConfigMap 对象时，可能会重新部署 openshift-monitoring 项目中的 Pod 和其他资源。该项目中正在运行的监控进程也可能被重启。

4. 检查 prometheus-operator、prometheus-user-workload 和 thanos-ruler-user-workload Pod 是否在 openshift-user-workload-monitoring 项目中运行。Pod 启动可能需要片刻时间：

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

   输出示例

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

流程

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

   $ oc -n openshift-user-workload-monitoring adm policy add-role-to-user \
     user-workload-monitoring-config-edit <user> \
     --role-namespace openshift-user-workload-monitoring

2. 通过显示相关角色绑定来验证用户是否已正确分配给 user-workload-monitoring-config-edit 角色：

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

   示例命令

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

   输出示例

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

   1

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

步骤

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

   $ TOKEN=$(oc whoami -t)

2. 运行以下命令，提取 thanos-querier API 路由 URL：

   $ HOST=$(oc -n openshift-monitoring get route thanos-querier -ojsonpath={.spec.host})

3. 使用以下命令，将命名空间设置为运行服务的命名空间：

   $ NAMESPACE=ns1

4. 运行以下命令，在命令行中查询您自己的服务的指标：

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

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

   输出示例

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

流程

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

   $ oc label namespace my-project 'openshift.io/user-monitoring=false'

2. 要重新启用监控，请从命名空间中删除该标签：

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

   注意

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

流程

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

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

   1. 在 data/config.yaml 下将 enableUserWorkload: 设置为 false：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          enableUserWorkload: false

2. 保存文件以使改变生效。然后会自动禁用对用户定义的项目的监控。

3. 检查 prometheus-operator、prometheus-user-workload 和 thanos-ruler-user-workload Pod 是否已在 openshift-user-workload-monitoring 项目中终止。这可能需要片刻时间：

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

   输出示例

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

流程

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

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. 在 data/config.yaml 下添加 alertmanagerMain 部分中的 enableUserAlertmanagerConfig: true ：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       alertmanagerMain:
         enableUserAlertmanagerConfig: true 1

   1

   将 enableUserAlertmanagerConfig 值设置为 true，以便用户创建使用 Alertmanager 主平台实例的用户定义警报路由配置。

3. 保存文件以使改变生效。

流程

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

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. 在 data/config.yaml 下，添加 alertmanager 部分的 enabled: true 和 enableAlertmanagerConfig: true ：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       alertmanager:
         enabled: true 1
         enableAlertmanagerConfig: true 2

   1

   将 enabled 值设为 true，为集群中的用户定义的项目启用 Alertmanager 专用实例。将值设为 false 或省略键可完全为用户定义的项目禁用 Alertmanager。如果将此值设置为 false，或者如果省略了密钥，则用户定义的警报会路由到默认平台 Alertmanager 实例。

   2

   将 enableAlertmanagerConfig 值设置为 true，以便用户使用 AlertmanagerConfig 对象定义自己的警报路由配置。

3. 保存文件以使改变生效。用于用户定义的项目的 Alertmanager 专用实例会自动启动。

步骤

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

   $ oc get routes -n openshift-monitoring thanos-querier -o jsonpath='{.status.ingress[0].host}'

2. 运行以下命令，以 JSON 格式从 Thanos Querier API 路由检索指标列表。此命令使用 oc 通过 bearer 令牌进行身份验证。

   $ curl -k -H "Authorization: Bearer $(oc whoami -t)" https://<thanos_querier_route>/api/v1/metadata 1

   1

   将 <thanos_querier_route> 替换为 Thanos Querier 的 OpenShift Container Platform API 路由。

1. 打开 OpenShift Container Platform web 控制台并导航到 Observe → Targets。
2. 可选：通过选择 Filter 列表中的过滤器来根据状态和源过滤目标。
3. 可选：使用搜索框旁的 Text 或 Label 字段按名称或标签搜索目标。
4. 可选：点 Endpoint, Status, Namespace, Last Scrape, 和 Scrape Duration 列标题对目标进行排序。

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

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

1. 打开 OpenShift Container Platform Web 控制台，并导航至 Observe → Alerting → Alerts 页面。
2. 可选：使用搜索列表中的 Name 字段按名称搜索警报。
3. 可选：通过选择 Filter 列表中的过滤器来按状态、严重性和来源过滤警报。
4. 可选：点击 Name、Severity、State 和 Source 列标题中的一个或多个标题对警报进行排序。

5. 点警报的名称查看其 Alert details 页面。该页面包含一个说明警报时间序列数据的图形。它还提供有关警报的以下信息：

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

1. 进入 Observe → Alerting → Silences 页面。
2. 可选：使用 Search by name 字段按名称过滤静默。
3. 可选：通过选择 Filter 列表中的过滤器来按状态过滤静默。默认情况下会应用 Active 和 Pending 过滤器。
4. 可选：点一个或多个 Name、Firing Alerts、State 和 Creator 栏上面的标头来对静默进行排序。

5. 选择静默的名称来查看其 Silence 详情页面。该页面包括以下详情：

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

1. 进入 Observe → Alerting → Alerting rules 页面。
2. 可选：通过选择 Filter 列表中的过滤器来按状态、严重性和来源过滤警报规则。
3. 可选：点 Name,Severity,Alert state, 和 Source 列标题中的一个或多个标题对警报规则进行排序。

4. 选择警报规则的名称来查看其 Alerting 规则详情页面。该页面提供有关警报规则的以下详情：

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

1. 进入 Observe → < project_name> → Alerts 页面。

2. 查看警报、静默或警报规则的详情：

   • 可以通过在警报名称旁边点大于符号(>)来查看警报详情，然后从列表中选择警报。

   • 可以通过在 Alert details 页面的 Silenced by 部分点静默详情来查看静默详情。Silence details 页面包括以下信息：

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

1. 将当前活跃的 Alertmanager 配置输出到 alertmanager.yaml 文件：

   $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml

2. 编辑 alertmanager.yaml 中的配置：

   global:
     resolve_timeout: 5m
   route:
     group_wait: 30s 1
     group_interval: 5m 2
     repeat_interval: 12h 3
     receiver: default
     routes:
     - matchers:
       - "alertname=Watchdog"
       repeat_interval: 2m
       receiver: watchdog
     - matchers:
       - "service=<your_service>" 4
       routes:
       - matchers:
         - <your_matching_rules> 5
         receiver: <receiver> 6
   receivers:
   - name: default
   - name: watchdog
   - name: <receiver>
   #  <receiver_configuration>

   1

   group_wait 值指定，Alertmanager 在为一组警报发送初始通知前要等待的时间。这个值控制 Alertmanager 在发送通知前为同一组收集初始警报时等待的时间。

   2

   group_interval 值指定 Alertmanager 发送通知添加到已经发送初始通知的一组警报前必须经过的时间。

   3

   repeat_interval 值指定重复警报通知前必须经过的最小时间。如果您希望通知在每个组间隔重复，请将 repeat_interval 值设置为小于 group_interval 的值。但是，重复的通知仍然可能延迟，例如，当某些 Alertmanager pod 重启或重新调度时。

   4

   service 值指定触发警报的服务。

   5

   <your_matching_rules> 值指定目标警报。

   6

   receiver 值指定用于警报的接收器。

   注意

   使用 matchers 键名称来指示警报要与节点匹配的匹配者。不要使用 match 或 match_re 键名称，它们都已弃用，并计划在以后的发行版本中删除。

   另外，如果您定义了禁止规则，请使用 target_matchers 键名称来指示目标匹配者和 source_matchers 键名称来指示源匹配器。不要使用 target_match,target_match_re,source_match, 或 source_match_re 键名称，这些名称已弃用，并计划在以后的发行版本中删除。

   以下 Alertmanager 配置示例将 PagerDuty 配置为警报接收器：

   global:
     resolve_timeout: 5m
   route:
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 12h
     receiver: default
     routes:
     - matchers:
       - "alertname=Watchdog"
       repeat_interval: 2m
       receiver: watchdog
     - matchers:
       - "service=example-app"
       routes:
       - matchers:
         - "severity=critical"
         receiver: team-frontend-page*
   receivers:
   - name: default
   - name: watchdog
   - name: team-frontend-page
     pagerduty_configs:
     - service_key: "_your-key_"

   采用此配置时，由 example-app 服务触发的、严重性为 critical 的警报将使用 team-frontend-page 接收器发送。通常情况下，这些类型的警报会传给个人或关键响应团队。

3. 应用文件中的新配置：

   $ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-monitoring replace secret --filename=-

1. 进入 web 控制台的 Administration → Cluster Settings → Configuration → Alertmanager → YAML 页面。
2. 修改 YAML 配置文件。
3. 点击 Save。

步骤

1. 将当前活跃的 Alertmanager 配置输出到 alertmanager.yaml 文件：

   $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml

2. 编辑 alertmanager.yaml 中的配置：

   route:
     receiver: Default
     group_by:
     - name: Default
     routes:
     - matchers:
       - "service = prometheus-example-monitor" 1
       receiver: <receiver> 2
   receivers:
   - name: Default
   - name: <receiver>
   #  <receiver_configuration>

   1

   指定与路由匹配的警报。本例显示具有 service="prometheus-example-monitor" 标签的所有警报。

   2

   指定用于警报组的接收器。

3. 应用文件中的新配置：

   $ oc -n openshift-user-workload-monitoring create secret generic alertmanager-user-workload --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-user-workload-monitoring replace secret --filename=-

步骤

1. 在 OpenShift Container Platform web 控制台的 Administrator 视角中，进入到 Observe → Dashboards。
2. 在 Dashboard 列表中选择一个仪表板。有些仪表板（如 etcd 和 Prometheus 仪表板）在被选中时会生成额外的子菜单。

3. 可选：在 Time Range 列表中为图形选择一个时间范围。

   • 选择预定义的时间段。

   • 通过选择 Time Range 列表中的 Custom 时间范围 来设置自定义时间范围。

     1. 输入或选择 From 和 To date and time。
     2. 单击 Save 以保存自定义时间范围。
4. 可选：选择一个 Refresh Interval。
5. 将鼠标悬停在仪表板中的每个图形上，以显示具体项目的详细信息。

步骤

1. 在 OpenShift Container Platform web 控制台的 Developer 视角中，导航到 Observe → Dashboard。
2. 从 Project: 下拉列表中选择一个项目。

3. 从 Dashboard 下拉列表中选择一个仪表板，以查看过滤的指标。

   注意

   选择时，所有仪表板会生成额外的子菜单，但 Kubernetes / Compute Resources / Namespace(Pods) 除外。

4. 可选：在 Time Range 列表中为图形选择一个时间范围。

   • 选择预定义的时间段。

   • 通过选择 Time Range 列表中的 Custom 时间范围 来设置自定义时间范围。

     1. 输入或选择 From 和 To date and time。
     2. 单击 Save 以保存自定义时间范围。
5. 可选：选择一个 Refresh Interval。
6. 将鼠标悬停在仪表板中的每个图形上，以显示特定项目的详细信息。

1. 添加 Helm 仓库：

   $ helm repo add rh-ecosystem-edge https://rh-ecosystem-edge.github.io/console-plugin-nvidia-gpu

   $ helm repo update

2. 在默认的 NVIDIA GPU Operator 命名空间中安装 Helm Chart:

   $ helm install -n nvidia-gpu-operator console-plugin-nvidia-gpu rh-ecosystem-edge/console-plugin-nvidia-gpu

   输出示例

   NAME: console-plugin-nvidia-gpu
   LAST DEPLOYED: Tue Aug 23 15:37:35 2022
   NAMESPACE: nvidia-gpu-operator
   STATUS: deployed
   REVISION: 1
   NOTES:
   View the Console Plugin NVIDIA GPU deployed resources by running the following command:
   
   $ oc -n {{ .Release.Namespace }} get all -l app.kubernetes.io/name=console-plugin-nvidia-gpu
   
   Enable the plugin by running the following command:
   
   # Check if a plugins field is specified
   $ oc get consoles.operator.openshift.io cluster --output=jsonpath="{.spec.plugins}"
   
   # if not, then run the following command to enable the plugin
   $ oc patch consoles.operator.openshift.io cluster --patch '{ "spec": { "plugins": ["console-plugin-nvidia-gpu"] } }' --type=merge
   
   # if yes, then run the following command to enable the plugin
   $ oc patch consoles.operator.openshift.io cluster --patch '[{"op": "add", "path": "/spec/plugins/-", "value": "console-plugin-nvidia-gpu" }]' --type=json
   
   # add the required DCGM Exporter metrics ConfigMap to the existing NVIDIA operator ClusterPolicy CR:
   oc patch clusterpolicies.nvidia.com gpu-cluster-policy --patch '{ "spec": { "dcgmExporter": { "config": { "name": "console-plugin-nvidia-gpu" } } } }' --type=merge

   仪表板主要依赖于 NVIDIA DCGM Exporter 公开的 Prometheus 指标，但默认公开的指标不足以便仪表板显示所需的量表。因此，DGCM 导出器配置为公开一组自定义指标，如下所示。

   apiVersion: v1
   data:
     dcgm-metrics.csv: |
       DCGM_FI_PROF_GR_ENGINE_ACTIVE, gauge, gpu utilization.
       DCGM_FI_DEV_MEM_COPY_UTIL, gauge, mem utilization.
       DCGM_FI_DEV_ENC_UTIL, gauge, enc utilization.
       DCGM_FI_DEV_DEC_UTIL, gauge, dec utilization.
       DCGM_FI_DEV_POWER_USAGE, gauge, power usage.
       DCGM_FI_DEV_POWER_MGMT_LIMIT_MAX, gauge, power mgmt limit.
       DCGM_FI_DEV_GPU_TEMP, gauge, gpu temp.
       DCGM_FI_DEV_SM_CLOCK, gauge, sm clock.
       DCGM_FI_DEV_MAX_SM_CLOCK, gauge, max sm clock.
       DCGM_FI_DEV_MEM_CLOCK, gauge, mem clock.
       DCGM_FI_DEV_MAX_MEM_CLOCK, gauge, max mem clock.
   kind: ConfigMap
   metadata:
     annotations:
       meta.helm.sh/release-name: console-plugin-nvidia-gpu
       meta.helm.sh/release-namespace: nvidia-gpu-operator
     creationTimestamp: "2022-10-26T19:46:41Z"
     labels:
       app.kubernetes.io/component: console-plugin-nvidia-gpu
       app.kubernetes.io/instance: console-plugin-nvidia-gpu
       app.kubernetes.io/managed-by: Helm
       app.kubernetes.io/name: console-plugin-nvidia-gpu
       app.kubernetes.io/part-of: console-plugin-nvidia-gpu
       app.kubernetes.io/version: latest
       helm.sh/chart: console-plugin-nvidia-gpu-0.2.3
     name: console-plugin-nvidia-gpu
     namespace: nvidia-gpu-operator
     resourceVersion: "19096623"
     uid: 96cdf700-dd27-437b-897d-5cbb1c255068

   安装 ConfigMap 并编辑 NVIDIA Operator ClusterPolicy CR，以在 DCGM 导出器配置中添加该 ConfigMap。ConfigMap 的安装由 Console Plugin NVIDIA GPU Helm Chart 的新版本完成，但 ClusterPolicy CR 编辑由用户执行。

3. 查看部署的资源：

   $ oc -n nvidia-gpu-operator get all -l app.kubernetes.io/name=console-plugin-nvidia-gpu

   输出示例

   NAME                                             READY   STATUS    RESTARTS   AGE
   pod/console-plugin-nvidia-gpu-7dc9cfb5df-ztksx   1/1     Running   0          2m6s
   
   NAME                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/console-plugin-nvidia-gpu   ClusterIP   172.30.240.138   <none>        9443/TCP   2m6s
   
   NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/console-plugin-nvidia-gpu   1/1     1            1           2m6s
   
   NAME                                                   DESIRED   CURRENT   READY   AGE
   replicaset.apps/console-plugin-nvidia-gpu-7dc9cfb5df   1         1         1       2m6s

步骤

1. 运行以下命令来提取身份验证令牌：

   $ TOKEN=$(oc whoami -t)

2. 运行以下命令提取 alertmanager-main API 路由 URL：

   $ HOST=$(oc -n openshift-monitoring get route alertmanager-main -ojsonpath={.spec.host})

3. 运行以下命令，查询 Alertmanager 的服务 API 接收器：

   $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v2/receivers"

步骤

1. 运行以下命令来检索 bearer 令牌：

   $ TOKEN=$(oc whoami -t)

2. 运行以下命令来获取 Prometheus 联邦路由 URL：

   $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s-federate -ojsonpath={.spec.host})

3. 查询 /federate 路由的指标。以下示例命令 up 指标 ：

   $ curl -G -k -H "Authorization: Bearer $TOKEN" https://$HOST/federate --data-urlencode 'match[]=up'

   输出示例

   # TYPE up untyped
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.143.148:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035322214
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.148.166:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035338597
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.173.16:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035343834
   ...

步骤

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

   $ TOKEN=$(oc whoami -t)

2. 运行以下命令，提取 thanos-querier API 路由 URL：

   $ HOST=$(oc -n openshift-monitoring get route thanos-querier -ojsonpath={.spec.host})

3. 使用以下命令，将命名空间设置为运行服务的命名空间：

   $ NAMESPACE=ns1

4. 运行以下命令，在命令行中查询您自己的服务的指标：

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

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

   输出示例

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

流程

1. 在服务和 ServiceMonitor 资源配置中检查对应的标签是否匹配。

   1. 获取服务中定义的标签。以下示例在 ns1 项目中查询 prometheus-example-app 服务：

      $ oc -n ns1 get service prometheus-example-app -o yaml

      输出示例

        labels:
          app: prometheus-example-app

   2. 检查 ServiceMonitor 资源配置中的 matchLabels 定义是否与上一步中的标签输出匹配。以下示例在 ns1 项目中查询 prometheus-example-monitor 服务监控器：

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      输出示例

      apiVersion: v1
      kind: ServiceMonitor
      metadata:
        name: prometheus-example-monitor
        namespace: ns1
      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app

      注意

      您可以作为具有项目查看权限的开发者检查服务和 ServiceMonitor 资源标签。

2. 在 openshift-user-workload-monitoring 项目中检查 Prometheus Operator 的日志。

   1. 列出 openshift-user-workload-monitoring 项目中的 Pod：

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

      输出示例

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

   2. 从 prometheus-operator Pod 中的 prometheus-operator 容器获取日志。在以下示例中，Pod 名为 prometheus-operator-776fcbbd56-2nbfm：

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      如果服务监控器出现问题，日志可能包含类似本例的错误：

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload

3. 在 OpenShift Container Platform Web 控制台 UI 中的 Metrics 目标 页面中查看您的端点的目标状态。

   1. 登录到 OpenShift Container Platform web 控制台，进入 Administrator 视角中的 Observe → Targets。
   2. 在列表中找到指标端点，并在 Status 列中查看目标的状态。
   3. 如果 Status 为 Down，点端点的 URL 查看该指标目标的 Target Details 页面的更多信息。

4. 在 openshift-user-workload-monitoring 项目中为 Prometheus Operator 配置 debug 级别的日志记录。

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

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. 在 data/config.yaml 下为 prometheusOperator 添加 logLevel: debug，将日志级别设置为 debug：

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug
      # ...

   3. 保存文件以使改变生效。

      注意

      在应用日志级别更改时，openshift-user-workload-monitoring 项目中的 prometheus-operator 会自动重启。

   4. 确认 debug 日志级别已应用到 openshift-user-workload-monitoring 项目中的 prometheus-operator 部署：

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

      输出示例

              - --log-level=debug

      Debug 级别日志记录将显示 Prometheus Operator 发出的所有调用。

   5. 检查 prometheus-operator Pod 是否正在运行：

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

      注意

      如果配置映射中包含了一个未识别的 Prometheus Operator loglevel 值，则 prometheus-operator Pod 可能无法成功重启。

   6. 查看 debug 日志，以了解 Prometheus Operator 是否在使用 ServiceMonitor 资源。查看日志中的其他相关错误。

流程

1. 在 Administrator 视角中，进入到 Observe → Metrics。

2. 在 Expression 字段中输入 Prometheus Query Language (PromQL) 查询。以下示例查询有助于识别可能导致高磁盘空间消耗的高卡性指标：

   • 通过运行以下查询，您可以识别具有最高提取示例数的十个作业：

     topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))

   • 通过运行以下查询，您可以通过识别在上一小时内创建了最多时间序列数据的十个作业，从而找出相关的时间序列：

     topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))

3. 如果指标的提取示例数大于预期，请检查分配给指标的未绑定标签值数量：

   • 如果指标与用户定义的项目相关，请查看分配给您的工作负载的指标键-值对。它们通过应用程序级别的 Prometheus 客户端库实施。尝试限制标签中引用的未绑定属性数量。
   • 如果指标与 OpenShift Container Platform 核心项目相关，请在红帽客户门户网站上创建一个红帽支持问题单。

4. 以集群管理员身份登录，运行以下命令，使用 Prometheus HTTP API 查看 TSDB 状态：

   1. 运行以下命令来获取 Prometheus API 路由 URL：

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.spec.host})

   2. 运行以下命令来提取身份验证令牌：

      $ TOKEN=$(oc whoami -t)

   3. 运行以下命令，查询 Prometheus 的 TSDB 状态：

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"

      输出示例

      "status": "success","data":{"headStats":{"numSeries":507473,
      "numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
      "maxTime":1712257935346},"seriesCountByMetricName":
      [{"name":"etcd_request_duration_seconds_bucket","value":51840},
      {"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
      ...