监控

流程

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. 在 data/config.yaml 下为组件指定 nodeSelector 约束：

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

        相应地替换 <component>，并将 <node_key>: <node_value> 替换为用于指定目标节点组的键值对映射。通常只使用一个键值对。

        组件只能在以各个指定键值对作为标签的节点上运行。节点也可以有附加标签。

        重要

        许多监控组件都通过在集群中的不同节点间使用多个 Pod 来部署，以维持高可用性。将监控组件移到带标签的节点时，确保有足够的匹配节点来保持组件的弹性。如果只指定了一个标签，请确保有足够的节点包含该标签，以便将该组件的所有 Pod 分布到不同的节点。另外，您还可以指定多个标签，每个都与单个节点相关。

        注意

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

        例如，要将 OpenShift Container Platform 核心项目的监控组件移到带有 nodename: controlplane1、nodename: worker1、nodename: worker2 和 nodename: worker2 标签的特定节点中，请使用：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusOperator:
              nodeSelector:
                nodename: controlplane1
            prometheusK8s:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            alertmanagerMain:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            kubeStateMetrics:
              nodeSelector:
                nodename: worker1
            grafana:
              nodeSelector:
                nodename: worker1
            telemeterClient:
              nodeSelector:
                nodename: worker1
            k8sPrometheusAdapter:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            openshiftStateMetrics:
              nodeSelector:
                nodename: worker1
            thanosQuerier:
              nodeSelector:
                nodename: worker1
                nodename: worker2

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

     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>:
              nodeSelector:
                <node_key>: <node_value>
                <node_key>: <node_value>
                <...>

        相应地替换 <component>，并将 <node_key>: <node_value> 替换为用于指定目标节点的键值对映射。通常只使用一个键值对。

        组件只能在以各个指定键值对作为标签的节点上运行。节点也可以有附加标签。

        重要

        许多监控组件都通过在集群中的不同节点间使用多个 Pod 来部署，以维持高可用性。将监控组件移到带标签的节点时，确保有足够的匹配节点来保持组件的弹性。如果只指定了一个标签，请确保有足够的节点包含该标签，以便将该组件的所有 Pod 分布到不同的节点。另外，您还可以指定多个标签，每个都与单个节点相关。

        注意

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

        例如，要将监控用户定义的项目的组件移到带有 nodename: worker1、nodename: worker2 和 nodename: worker2 标签的特定 worker 节点，请使用：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheusOperator:
              nodeSelector:
                nodename: worker1
            prometheus:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            thanosRuler:
              nodeSelector:
                nodename: worker1
                nodename: worker2

2. 保存文件以使改变生效。受新配置影响的组件会自动移到新节点上。

   注意

   除非集群管理员为用户定义的项目启用了监控，否则应用到 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. 在 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"
           <endpoint_authentication_credentials>

   对于 endpoint_authentication_credentials，请替换端点的凭据。目前支持的身份验证方法是基本身份验证 (basicAuth) 和客户端 TLS (tlsConfig) 身份验证。

   • 以下示例配置基本身份验证：

     basicAuth:
       username:
         <usernameSecret>
       password:
         <passwordSecret>

     相应地替换 <usernameSecret> 和 <passwordSecret>。

     以下示例显示了基本的身份验证配置，remoteWriteAuth 是 name 值，user 和 password 是 key 值。这些值包含端点身份验证凭证：

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: cluster-monitoring-config
       namespace: openshift-monitoring
     data:
       config.yaml: |
         prometheusK8s:
           remoteWrite:
           - url: "https://remote-write.endpoint"
             basicAuth:
               username:
                 name: remoteWriteAuth
                 key: user
               password:
                 name: remoteWriteAuth
                 key: password

   • 以下示例配置客户端 TLS 身份验证：

     tlsConfig:
       ca:
         <caSecret>
       cert:
         <certSecret>
       keySecret:
         <keySecret>

     相应地替换 <caSecret>、<certSecret> 和 <keySecret>。

     以下示例显示了一个 TLS 验证配合，使用 selfsigned-mtls-bundle 作为 name 值，ca.crt 为 ca key 值，client.crt 为 cert key 值，client.key 为 keySecret key 值：

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: cluster-monitoring-config
       namespace: openshift-monitoring
     data:
       config.yaml: |
         prometheusK8s:
           remoteWrite:
           - url: "https://remote-write.endpoint"
             tlsConfig:
               ca:
                 secret:
                   name: selfsigned-mtls-bundle
                   key: ca.crt
               cert:
                 secret:
                   name: selfsigned-mtls-bundle
                   key: client.crt
               keySecret:
                 name: selfsigned-mtls-bundle
                 key: client.key

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"
           <endpoint_authentication_credentials>
           <write_relabel_configs>

   对于 <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"
           writeRelabelConfigs:
           - sourceLabels: [__name__]
             regex: 'my_metric'
             action: keep

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

5. 如果需要，通过更改 name and namespace metadata 值，为监控用户定义的项目的 Prometheus 实例配置远程写入，如下所示：

   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"
           <endpoint_authentication_credentials>
           <write_relabel_configs>

   注意

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

6. 保存文件以将更改应用到 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 作为键的名称，因为它们是保留的并会被覆盖。

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

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

        注意

        在 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. 编辑 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 下为 grafana 组件添加 enabled: false ：

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

3. 保存文件以使改变生效。应用更改时，资源将开始自动删除。

   警告

   此更改会导致一些组件，包括 Prometheus 和 Thanos Querier，正在重启。如果您还没有遵循"配置持久性存储"部分中的步骤，这可能会导致之前收集的指标丢失。

4. 检查 Grafana pod 是否不再运行。以下示例列出了 openshift-monitoring 项目中的 pod 状态：

   $ oc -n openshift-monitoring get pods

   注意

   应用更改后可能需要几分钟时间来终止这些 pod。

流程

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. 提取令牌以连接到 Prometheus：

   $ SECRET=`oc get secret -n openshift-user-workload-monitoring | grep  prometheus-user-workload-token | head -n 1 | awk '{print $1 }'`

   $ TOKEN=`echo $(oc get secret $SECRET -n openshift-user-workload-monitoring -o json | jq -r '.data.token') | base64 -d`

2. 提取路由主机：

   $ THANOS_QUERIER_HOST=`oc get route thanos-querier -n openshift-monitoring -o json | jq -r '.spec.host'`

3. 在命令行中查询您自己的服务的指标。例如：

   $ NAMESPACE=ns1

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

   输出将显示应用容器集已启动的时间。

   输出示例

   {"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. 打开 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 列标题中的一个或多个标题对静默进行排序。

5. 选择静默的名称以导航到其 Silence Details 页面。该页面包括以下详情：

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

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

4. 选择警报规则的名称以导航到其 Alerting Rule Details 页面。该页面提供有关警报规则的以下详情：

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

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

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

   • 要查看 Alert Details，可选择警报名称左侧的 >，然后在列表中选择警报。

   • 要查看 Silence Details，可在 Alert Details 页面的 Silenced By 部分中选择静默。Silence Details 页面包括以下信息：

     • 警报指定条件
     • 开始时间
     • 结束时间
     • 静默状态
     • 触发警报的数目和列表
   • 要查看 Alerting Rule 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
     group_interval: 5m
     repeat_interval: 12h
     receiver: default
     routes:
     - matchers:
       - "alertname=Watchdog"
       repeat_interval: 5m
       receiver: watchdog
     - matchers:
       - "service=<your_service>" 1
       routes:
       - matchers:
         - <your_matching_rules> 2
         receiver: <receiver> 3
   receivers:
   - name: default
   - name: watchdog
   - name: <receiver>
   #  <receiver_configuration>

   1

   service 指定触发警报的服务。

   2

   <your_matching_rules> 指定目标警报。

   3

   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: 5m
       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. 在 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. 在 Administrator 视角中，导航至 Networking → Routes。

   注意

   从 Developer 视角无法访问第三方 Alertmanager、Grafana、Prometheus 和 Thanos Querier UI。取而代之，使用 Developer 视角中的 Metrics UI 链接，其中包含所选项目的一些预定义 CPU、内存、带宽和网络数据包查询。

2. 选择 Project 列表中的 openshift-monitoring 项目。

3. 访问第三方监控 UI：

   • 选择 alertmanager-main 行中的 URL 来打开 Alertmanager UI 的登录页面。
   • 选择 grafana 行中的 URL 来打开 Grafana UI 的登录页面。
   • 选择 prometheus-k8s 行中的 URL 来打开 Prometheus UI 的登录页面。
   • 选择 thanos-querier 行中的 URL 来打开 Thanos Querier UI 的登录页面。
4. 选择 Log in with OpenShift 来使用您的 OpenShift Container Platform 凭证进行登录。

流程

1. 运行以下命令来列出 openshift-monitoring 项目的路由：

   $ oc -n openshift-monitoring get routes

   输出示例

   NAME                HOST/PORT                                                     ...
   alertmanager-main   alertmanager-main-openshift-monitoring.apps._url_.openshift.com ...
   grafana             grafana-openshift-monitoring.apps._url_.openshift.com           ...
   prometheus-k8s      prometheus-k8s-openshift-monitoring.apps._url_.openshift.com    ...
   thanos-querier      thanos-querier-openshift-monitoring.apps._url_.openshift.com    ...

2. 使用 Web 浏览器导航到 HOST/PORT 路由。
3. 选择 Log in with OpenShift 来使用您的 OpenShift Container Platform 凭证进行登录。

流程

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 app 标签是否与上一步中的标签输出匹配：

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

      输出示例

      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. 直接在 Prometheus UI 中查看项目的目标状态。

   1. 建立端口转发到 openshift-user-workload-monitoring 项目中的 Prometheus 实例：

      $ oc port-forward -n openshift-user-workload-monitoring pod/prometheus-user-workload-0 9090

   2. 在 Web 浏览器中打开 http://localhost:9090/targets，并在 Prometheus UI 中直接查看项目的目标状态。检查与目标相关的错误消息。

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,count by (job)({__name__=~".+"}))

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

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

4. 检查 Prometheus UI 中的 TSDB 状态。

   1. 在 Administrator 视角中，导航至 Networking → Routes。
   2. 选择 Project 列表中的 openshift-monitoring 项目。
   3. 选择 prometheus-k8s 行中的 URL 来打开 Prometheus UI 的登录页面。
   4. 选择 Log in with OpenShift 来使用您的 OpenShift Container Platform 凭证进行登录。
   5. 在 Prometheus UI 中，进入到 Status → TSDB Status。