监控

流程

1. 检查 cluster-monitoring-config ConfigMap 对象是否存在：

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

2. 如果 ConfigMap 对象不存在：

   1. 创建以下 YAML 清单。在本例中，该文件名为 cluster-monitoring-config.yaml：

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

   2. 应用配置以创建 ConfigMap 对象：

      $ oc apply -f cluster-monitoring-config.yaml

流程

1. 检查 user-workload-monitoring-config ConfigMap 对象是否存在：

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

2. 如果 user-workload-monitoring-config ConfigMap 对象不存在：

   1. 创建以下 YAML 清单。在本例中，该文件名为 user-workload-monitoring-config.yaml：

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

   2. 应用配置以创建 ConfigMap 对象：

      $ oc apply -f user-workload-monitoring-config.yaml

      注意

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

流程

1. 如果您还没有这样做，请在要运行监控组件的节点中添加标签：

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

2. 编辑 ConfigMap 对象：

   • 要移动用于监控 OpenShift Container Platform 核心项目的组件：

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

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

     2. 在 data/config.yaml 下为组件指定 nodeSelector 约束的节点标签：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              nodeSelector:
                <node-label-1> 2
                <node-label-2> 3
                <...>

        1

        将 <component> 替换为适当的监控堆栈组件名称。

        2

        将 <node-label-1> 替换为添加到节点的标签。

        3

        可选：指定附加标签。如果您指定了额外的标签，则组件的 pod 仅调度到包含所有指定标签的节点上。

        注意

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

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

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

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

     2. 在 data/config.yaml 下为组件指定 nodeSelector 约束的节点标签：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              nodeSelector:
                <node-label-1> 2
                <node-label-2> 3
                <...>

        1

        将 <component> 替换为适当的监控堆栈组件名称。

        2

        将 <node-label-1> 替换为添加到节点的标签。

        3

        可选：指定附加标签。如果您指定了额外的标签，则组件的 pod 仅调度到包含所有指定标签的节点上。

        注意

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

3. 保存文件以使改变生效。新配置中指定的组件会自动移到新节点上，受新配置影响的 pod 会被重新部署。

流程

1. 要配置核心平台监控组件，请编辑 openshift-monitoring 命名空间中的 cluster-monitoring-config 配置映射对象：

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

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

   重要

   确保为限制设置的值始终高于为请求设置的值。否则，会出现错误，容器将不会运行。

   Example

   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
       k8sPrometheusAdapter:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       kubeStateMetrics:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       telemeterClient:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       openshiftStateMetrics:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       thanosQuerier:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       nodeExporter:
         resources:
           limits:
             cpu: 50m
             memory: 150Mi
           requests:
             cpu: 20m
             memory: 50Mi
       monitoringPlugin:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       prometheusOperatorAdmissionWebhook:
         resources:
           limits:
             cpu: 50m
             memory: 100Mi
           requests:
             cpu: 20m
             memory: 50Mi

3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

流程

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

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

2. 如以下示例所示，添加一个 enabled: true 键-值对：

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

   1

   将 enabled 字段的值设置为 true 以部署一个专用服务监控器，该监控器公开 kubelet /metrics/resource 端点。

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

   警告

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

流程

1. 编辑 ConfigMap 对象：

   • 为监控 OpenShift Container Platform 核心项目的组件配置 PVC：

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

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

     2. 将组件的 PVC 配置添加到 data/config.yaml 下：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class> 2
                  resources:
                    requests:
                      storage: <amount_of_storage> 3

        1

        指定您要为其配置 PVC 的核心监控组件。

        2

        指定现有存储类。如果没有指定存储类，则使用默认存储类。

        3

        指定所需的存储量。

        如需有关如何指定 volumeClaimTemplate 的信息，请参阅 Kubernetes 文档中与 PersistentVolumeClaim 相关的内容。

        以下示例配置了一个 PVC，它声明用于监控 OpenShift Container Platform 核心组件的 Prometheus 实例的持久性存储：

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

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

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

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

     2. 将组件的 PVC 配置添加到 data/config.yaml 下：

        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 文档中与 PersistentVolumeClaim 相关的内容。

        以下示例配置了一个 PVC 来声明用于 Thanos Ruler 的持久性存储：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              volumeClaimTemplate:
                spec:
                  storageClassName: my-storage-class
                  resources:
                    requests:
                      storage: 10Gi

        注意

        thanosRuler 组件的存储要求取决于要评估的规则数量以及每个规则生成的样本数量。

2. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署并应用新的存储配置。

   警告

   当您使用 PVC 配置更新配置映射时，受影响的 StatefulSet 对象会被重新创建，从而导致临时服务中断。

流程

1. 使用更新的存储请求手动扩展 PVC。如需更多信息，请参阅 扩展持久性卷 中的"使用文件系统扩展持久性卷声明 (PVC) "。

2. 编辑 ConfigMap 对象：

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

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

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

     2. 在 data/config.yaml 下为组件添加新存储大小：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  resources:
                    requests:
                      storage: <amount_of_storage> 2

        1

        要更改存储大小的组件。

        2

        指定存储卷的新大小。它必须大于上一个值。

        以下示例将监控 OpenShift Container Platform 核心组件的 Prometheus 实例的新 PVC 请求设置为 100GB：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              volumeClaimTemplate:
                spec:
                  resources:
                    requests:
                      storage: 100Gi

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

     注意

     您可以调整 Thanos Ruler 的大小，以及监控用户定义的项目的 Alertmanager 和 Prometheus 实例。

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

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

     2. 在 data/config.yaml 下更新监控组件的 PVC 配置：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  resources:
                    requests:
                      storage: <amount_of_storage> 2

        1

        要更改存储大小的组件。

        2

        指定存储卷的新大小。它必须大于上一个值。

        以下示例将 Thanos Ruler 的新 PVC 请求设置为 20GB：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              volumeClaimTemplate:
                spec:
                  resources:
                    requests:
                      storage: 20Gi

        注意

        thanosRuler 组件的存储要求取决于要评估的规则数量以及每个规则生成的样本数量。

3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

   警告

   当您使用新存储大小更新配置映射时，受影响的 StatefulSet 对象会被重新创建，从而导致临时服务中断。

流程

1. 编辑 ConfigMap 对象：

   • 要修改用于监控 OpenShift Container Platform 核心项目的 Prometheus 实例的保留时间和大小：

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

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

     2. 在 data/config.yaml 下添加保留时间和大小配置：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              retention: <time_specification> 1
              retentionSize: <size_specification> 2

        1

        保留时间：数字直接加上 ms （毫秒）、s （秒）、m （分钟）、h （小时）、d （天）、w （周）或 y （年）。您还可以组合指定时间值，如 1h30m15s。

        2

        保留大小：数字直接加上 B (bytes), KB (kilobytes), MB (megabytes), GB (gigabytes), TB (terabytes), PB (petabytes), 和 EB (exabytes).。

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

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              retention: 24h
              retentionSize: 10GB

   • 要修改监控用户定义的项目的 Prometheus 实例的保留时间和大小 ：

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

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

     2. 在 data/config.yaml 下添加保留时间和大小配置：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              retention: <time_specification> 1
              retentionSize: <size_specification> 2

        1

        保留时间：数字直接加上 ms （毫秒）、s （秒）、m （分钟）、h （小时）、d （天）、w （周）或 y （年）。您还可以组合指定时间值，如 1h30m15s。

        2

        保留大小：数字直接加上 B (bytes), KB (kilobytes), MB (megabytes), GB (gigabytes), TB (terabytes), PB (petabytes), 或 EB (exabytes)。

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

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              retention: 24h
              retentionSize: 10GB

2. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

流程

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

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

2. 将保留时间配置添加到 data/config.yaml 下：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         retention: <time_specification> 1

   1

   以以下格式指定保留时间：数字直接后跟 ms （毫秒）、s （秒）、m （分钟）、h （小时）、d （天）、w （周）或 y （年）。您还可以组合指定时间值，如 1h30m15s。默认值为 24h。

   以下示例将 Thanos Ruler 数据的保留时间设置为 10 天：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         retention: 10d

3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

流程

1. 编辑 ConfigMap 对象：

   • 为 OpenShift Container Platform 核心指标创建集群 ID 标签：

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

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

     2. 在 data/config.yaml/prometheusK8s/remoteWrite 中的 writeRelabelConfigs: 部分添加集群 ID 重新标记配置值：

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

        1

        为您要发送到远程端点的指标添加写入重新标记配置列表。

        2

        替换发送到远程写入端点的指标的标签配置。

        以下示例演示了如何在默认平台监控中使用集群 ID 标签 cluster_id 转发指标：

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                writeRelabelConfigs:
                - sourceLabels:
                  - __tmp_openshift_cluster_id__ 1
                  targetLabel: cluster_id 2
                  action: replace 3

        1

        系统最初应用名为 __tmp_openshift_cluster_id__ 的临时集群 ID 源标签。此临时标签由您指定的集群 ID 标签名称替换。

        2

        指定发送到远程写入存储的指标的集群 ID 标签名称。如果您使用指标已存在的标签名称，则该值会使用这个集群 ID 标签的名称覆盖。对于标签名称，不要使用 __tmp_openshift_cluster_id__。最后重新标记步骤会删除使用此名称的标签。

        3

        replace write relabel 操作，将临时标签替换为传出指标的目标标签。这个操作是默认行为，如果没有指定任何操作，则会被应用。

   • 为用户定义的项目指标创建集群 ID 标签：

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

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

     2. 在 data/config.yaml/prometheus/remoteWrite 下的 writeRelabelConfigs: 部分中，添加集群 ID 重新标记配置值：

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

        1

        为您要发送到远程端点的指标添加写入重新标记配置列表。

        2

        替换发送到远程写入端点的指标的标签配置。

        以下示例演示了如何在 user-workload 监控中使用集群 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 write relabel 操作，将临时标签替换为传出指标的目标标签。这个操作是默认行为，如果没有指定任何操作，则会被应用。

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

流程

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

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

2. 在 data/config.yaml/prometheusK8s 下添加 metrics collection 配置集设置：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       prometheusK8s:
         collectionProfile: <metrics_collection_profile_name> 1

   1

   指标集合配置集的名称。可用值为 full 或 minimal。如果没有指定值，或者配置映射中不存在 collectionProfile 键名称，则会使用 full 的默认设置。

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

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

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

流程

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 中添加 enforcedSampleLimit 配置，以限制用户定义的项目中每个目标提取可接受的示例数量：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         enforcedSampleLimit: 50000 1

   1

   如果指定此参数，则需要一个值。这个 enforceSampleLimit 示例将用户定义的项目中每个目标提取的示例数量限制为 50,000。

3. 将 enforcedLabelLimit, enforcedLabelNameLengthLimit, 和 enforcedLabelValueLengthLimit 配置添加到 data/config.yaml，以限制刮除的标签数量、标签名称长度以及用户定义的项目中的标签值长度：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         enforcedLabelLimit: 500 1
         enforcedLabelNameLengthLimit: 50 2
         enforcedLabelValueLengthLimit: 600 3

   1

   指定每次刮除的最大标签数。默认值为 0，代表没有指定限制。

   2

   指定标签名称字符的最大长度。默认值为 0，代表没有指定限制。

   3

   指定标签值字符的最大长度。默认值为 0，代表没有指定限制。

4. 保存文件以使改变生效。限制会自动应用。

流程

1. 创建一个包含警报的 YAML 文件，用于在目标停机以及即将达到强制的示例限制时通知您。本例中的文件名为 monitoring-stack-alerts.yaml：

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     labels:
       prometheus: k8s
       role: alert-rules
     name: monitoring-stack-alerts 1
     namespace: ns1 2
   spec:
     groups:
     - name: general.rules
       rules:
       - alert: TargetDown 3
         annotations:
           message: '{{ printf "%.4g" $value }}% of the {{ $labels.job }}/{{ $labels.service
             }} targets in {{ $labels.namespace }} namespace are down.' 4
         expr: 100 * (count(up == 0) BY (job, namespace, service) / count(up) BY (job,
           namespace, service)) > 10
         for: 10m 5
         labels:
           severity: warning 6
       - alert: ApproachingEnforcedSamplesLimit 7
         annotations:
           message: '{{ $labels.container }} container of the {{ $labels.pod }} pod in the {{ $labels.namespace }} namespace consumes {{ $value | humanizePercentage }} of the samples limit budget.' 8
         expr: scrape_samples_scraped/50000 > 0.8 9
         for: 10m 10
         labels:
           severity: warning 11

   1

   定义警报规则的名称。

   2

   指定要部署警报规则的用户定义的项目。

   3

   如果在 for 持续时间内无法提取目标或者目标不可用，则 TargetDown 警报将触发。

   4

   TargetDown 警报触发时输出的消息。

   5

   在这个持续时间内必须满足 TargetDown 警报的条件才会触发该警报。

   6

   定义 TargetDown 警报的严重性。

   7

   当在指定的 for 持续时间内达到或超过定义的提取示例阈值时，ApproachingEnforcedSamplesLimit 警报将触发。

   8

   当 ApproachingEnforcedSamplesLimit 警报触发时输出的消息。

   9

   ApproachingEnforcedSamplesLimit 警报的阈值。在本例中，当每个目标提取的示例数量超过强制示例限制 50000 的 80% 时，警报将触发。在警报触发前，还必须已经过了 for 持续时间。表达式 scrape_samples_scraped/<number> > <threshold> 中的 <number> 必须与 user-workload-monitoring-config ConfigMap 对象中定义的 enforcedSampleLimit 值匹配。

   10

   在这个持续时间内必须满足 ApproachingEnforcedSamplesLimit 警报的条件才会触发该警报。

   11

   定义 ApproachingEnforcedSamplesLimit 警报的严重性。

2. 将配置应用到用户定义的项目中：

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

流程

1. 在 OpenShift Container Platform Web 控制台的 Administrator 视角中，进入 User Management → RoleBindings → Create binding。
2. 在 Binding Type 部分中，选择 Namespace Role Binding 类型。
3. 在 Name 字段中输入角色绑定的名称。

4. 在 Namespace 字段中，选择要授予访问权限的项目。

   重要

   您使用此流程向用户授予的监控角色或集群角色权限只适用于您在 Namespace 字段中选择的项目。

5. 从 Role Name 列表中选择监控角色或集群角色。
6. 在 Subject 部分，选择 User。
7. 在 Subject Name 字段中，输入用户名称。
8. 选择 Create 以应用角色绑定。

流程

1. 为服务配置创建 YAML 文件。在本例中，该文件名为 prometheus-example-app.yaml。

2. 在该文件中添加以下部署和服务配置详情：

   apiVersion: v1
   kind: Namespace
   metadata:
     name: ns1
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: prometheus-example-app
     name: prometheus-example-app
     namespace: ns1
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: prometheus-example-app
     template:
       metadata:
         labels:
           app: prometheus-example-app
       spec:
         containers:
         - image: ghcr.io/rhobs/prometheus-example-app:0.4.2
           imagePullPolicy: IfNotPresent
           name: prometheus-example-app
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: prometheus-example-app
     name: prometheus-example-app
     namespace: ns1
   spec:
     ports:
     - port: 8080
       protocol: TCP
       targetPort: 8080
       name: web
     selector:
       app: prometheus-example-app
     type: ClusterIP

   此配置会在用户定义的 ns1 项目中部署名为 prometheus-example-app 的服务。此服务会公开自定义 version 指标。

3. 将配置应用到集群：

   $ oc apply -f prometheus-example-app.yaml

   部署该服务需要一些时间。

4. 您可以检查该 Pod 是否正在运行：

   $ oc -n ns1 get pod

   输出示例

   NAME                                      READY     STATUS    RESTARTS   AGE
   prometheus-example-app-7857545cb7-sbgwq   1/1       Running   0          81m

流程

1. 创建名为 example-app-service-monitor.yaml 的新 YAML 配置文件。

2. 将 ServiceMonitor 资源添加到 YAML 文件中。以下示例创建一个名为 prometheus-example-monitor 的服务监控器，用于提取 ns1 命名空间中的 prometheus-example-app 服务公开的指标：

   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     name: prometheus-example-monitor
     namespace: ns1 1
   spec:
     endpoints:
     - interval: 30s
       port: web 2
       scheme: http
     selector: 3
       matchLabels:
         app: prometheus-example-app

   1

   指定服务运行的用户定义的命名空间。

   2

   指定要由 Prometheus 提取的端点端口。

   3

   配置选择器，根据其元数据标签匹配您的服务。

   注意

   用户定义的命名空间中的 ServiceMonitor 资源只能发现同一命名空间中的服务。也就是说，ServiceMonitor 资源的 namespaceSelector 字段总是被忽略。

3. 将配置应用到集群：

   $ oc apply -f example-app-service-monitor.yaml

   部署 ServiceMonitor 资源需要一些时间。

4. 验证 ServiceMonitor 资源是否正在运行：

   $ oc -n <namespace> get servicemonitor

   输出示例

   NAME                         AGE
   prometheus-example-monitor   81m

流程

1. 从 OpenShift Container Platform Web 控制台中的 Administrator 视角，选择 Observe → Metrics。

2. 要添加一个或多个查询，请执行以下操作之一：

   选项	描述
   创建自定义查询。	将 Prometheus Query Language (PromQL) 查询添加到 Expression 字段中。 当您输入 PromQL 表达式时，自动完成建议会出现在下拉列表中。这些建议包括功能、指标、标签和时间令牌。您可以使用键盘箭头选择其中一项建议的项目，然后按 Enter 将项目添加到您的表达式中。您还可以将鼠标指针移到建议的项目上，以查看该项目的简短描述。
   添加多个查询。	选择 Add query。
   复制现有的查询。	选择查询旁边的 Options 菜单 ，然后选择 Duplicate 查询。
   禁用查询正在运行。	选择查询旁边的 Options 菜单 并选择 Disable query。

3. 要运行您创建的查询，请选择 Run queries。图表中会直观呈现查询的指标。如果查询无效，则 UI 会显示错误消息。

   注意

   如果查询对大量数据进行运算，这可能会在绘制时序图时造成浏览器超时或过载。要避免这种情况，请选择 Hide graph 并且仅使用指标表来校准查询。然后，在找到可行的查询后，启用图表来绘制图形。

   注意

   默认情况下，查询表会显示一个展开的视图，列出每个指标及其当前值。您可以选择 ˅ 来最小化查询的展开视图。

4. 可选：页面 URL 现在包含您运行的查询。要在以后再次使用这一组查询，请保存这个 URL。

5. 探索视觉化指标。最初，图表中显示所有启用的查询中的所有指标。您可以通过执行以下操作来选择显示哪些指标：

   选项	描述
   隐藏查询中的所有指标。	点查询的 Options 菜单 并点 Hide all series。
   隐藏特定指标。	前往查询表，再点指标名称旁边的带颜色的方格。
   放大图表并更改时间范围。	任一： 点击图表并在水平方向上拖动，以可视化方式选择时间范围。 使用左上角的菜单来选择时间范围。
   重置时间范围。	选择 Reset zoom。
   在特定时间点显示所有查询的输出。	将鼠标光标悬停在图表上。弹出框中会显示查询输出。
   隐藏图表。	选择 Hide graph。

流程

1. 在 OpenShift Container Platform web 控制台中的 Developer 视角中，选择 Observe → Metrics。
2. 在 Project: 列表中选择您要查看指标的项目。

3. 从 Select query 列表中选择查询，或者通过选择 Show PromQL 根据所选查询创建自定义 PromQL 查询。图表中会直观呈现查询的指标。

   注意

   在 Developer 视角中，您一次只能运行一个查询。

4. 通过执行以下操作来探索视觉化的指标：

   选项	描述
   放大图表并更改时间范围。	任一： 点击图表并在水平方向上拖动，以可视化方式选择时间范围。 使用左上角的菜单来选择时间范围。
   重置时间范围。	选择 Reset zoom。
   在特定时间点显示所有查询的输出。	将鼠标光标悬停在图表上。查询输出会出现在弹出窗口中。

1. 在 OpenShift Container Platform web 控制台中，进入 Observe → Alerting → Alerts。
2. 对于要静默的警报，点 ，选择 Silence alert 打开 Silence alert 页，其中包括了所选警报的默认配置。

3. 可选：更改静默的默认配置详情。

   注意

   在保存静默前，需要添加一个注释信息。

4. 要保存静默，点 Silence。

1. 在 OpenShift Container Platform web 控制台中进入 Observe → <project_name > → Alerts。
2. 如有必要，通过选择警报名称旁的符号(>)来扩展警报的详情。
3. 在扩展视图中点警报消息以打开警报的 Alert details 页面。
4. 点 Silence alert，打开带有警报默认配置的静默警报页。

5. 可选：更改静默的默认配置详情。

   注意

   在保存静默前，需要添加一个注释信息。

6. 要保存静默，点 Silence。

1. 进入 OpenShift Container Platform Web 控制台中的 Observe → Alerting → Silences。
2. 点 Create silence。

3. 在 Create silence 页面中，设置警报的调度、持续时间和标签详情。

   注意

   在保存静默前，需要添加一个注释信息。

4. 要为与您输入的标签匹配的警报创建静默，请点 Silence。

1. 进入 OpenShift Container Platform Web 控制台中的 Observe → <project_name > → Silences。
2. 点 Create silence。

3. 在 Create silence 页面中，设置警报的持续时间和标签详情。

   注意

   在保存静默前，需要添加一个注释信息。

4. 要为与您输入的标签匹配的警报创建静默，请点 Silence。

1. 进入 Observe → Alerting → Silences。

2. 针对您想要修改的静默，点 并选择 Edit silence。

   或者，您可以点 Actions，然后在静默的 Silence details 页面中选择 Edit silence。

3. 在 Edit silence 页面中，进行更改并点 Silence。这样做会使现有静默到期，并创建带有更新的配置。

1. 进入 Observe → <project_name> → Silences。

2. 针对您想要修改的静默，点 并选择 Edit silence。

   或者，您可以点 Actions，然后在静默的 Silence details 页面中选择 Edit silence。

3. 在 Edit silence 页面中，进行更改并点 Silence。这样做会使现有静默到期，并创建带有更新的配置。

1. 进入 Observe → Alerting → Silences。
2. 对于您要过期的静默，选择对应行的复选框。

3. 点 Expire 1 silence 使一个静默过期，或点 Expire <n> silences 使多个静默过期（其中 <n> 是你选择的静默数）。

   另外，要使单个静默到期，您还可以点 Actions，然后在静默的 Silence details 页面中选择 Expire silence。

1. 进入 Observe → <project_name> → Silences。
2. 对于您要过期的静默，选择对应行的复选框。

3. 点 Expire 1 silence 使一个静默过期，或点 Expire <n> silences 使多个静默过期（其中 <n> 是你选择的静默数）。

   另外，要使单个静默到期，您还可以点 Actions，然后在静默的 Silence details 页面中选择 Expire silence。

流程

1. 创建一个名为 example-alerting-rule.yaml 的新 YAML 配置文件。

2. 向 YAML 文件添加 AlertingRule 资源。以下示例创建一个名为 example 的新警报规则，类似于默认的 Watchdog 警报：

   apiVersion: monitoring.openshift.io/v1
   kind: AlertingRule
   metadata:
     name: example
     namespace: openshift-monitoring 1
   spec:
     groups:
     - name: example-rules
       rules:
       - alert: ExampleAlert 2
         for: 1m 3
         expr: vector(1) 4
         labels:
           severity: warning 5
         annotations:
           message: This is an example alert. 6

   1

   确保命名空间为 openshift-monitoring。

   2

   您要创建的警报规则的名称。

   3

   触发警报前条件应为 true 的持续时间。

   4

   定义新规则的 PromQL 查询表达式。

   5

   警报规则分配给警报的严重性。

   6

   与警报关联的消息。

   重要

   您必须在 openshift-monitoring 命名空间中创建 AlertingRule 对象。否则，将不接受警报规则。

3. 将配置文件应用到集群：

   $ oc apply -f example-alerting-rule.yaml

流程

1. 创建名为 example-modified-alerting-rule.yaml 的新 YAML 配置文件。

2. 在 YAML 文件中添加 AlertRelabelConfig 资源。以下示例将默认平台 watchdog 警报规则的 severity 设置改为 critical ：

   apiVersion: monitoring.openshift.io/v1
   kind: AlertRelabelConfig
   metadata:
     name: watchdog
     namespace: openshift-monitoring 1
   spec:
     configs:
     - sourceLabels: [alertname,severity] 2
       regex: "Watchdog;none" 3
       targetLabel: severity 4
       replacement: critical 5
       action: Replace 6

   1

   确保命名空间为 openshift-monitoring。

   2

   要修改的值的源标签。

   3

   匹配的 sourceLabels 值的正则表达式。

   4

   要修改的值的目标标签。

   5

   要替换目标标签的新值。

   6

   基于正则表达式匹配替换旧值的重新标记操作。默认操作为 Replace。其他可能的值有 Keep,Drop,HashMod,LabelMap,LabelDrop, LabelKeep。

   重要

   您必须在 openshift-monitoring 命名空间中创建 AlertRelabelConfig 对象。否则，警报标签不会改变。

3. 将配置文件应用到集群：

   $ oc apply -f example-modified-alerting-rule.yaml

流程

1. 为警报规则创建 YAML 文件。在本例中，该文件名为 example-app-alerting-rule.yaml。

2. 向 YAML 文件添加警报规则配置。以下示例创建一个名为 example-alert 的新警报规则。当示例服务公开的 version 指标变为 0 时，警报规则会触发警报：

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     name: example-alert
     namespace: ns1
   spec:
     groups:
     - name: example
       rules:
       - alert: VersionAlert 1
         for: 1m 2
         expr: version{job="prometheus-example-app"} == 0 3
         labels:
           severity: warning 4
         annotations:
           message: This is an example alert. 5

   1

   您要创建的警报规则的名称。

   2

   触发警报前条件应为 true 的持续时间。

   3

   定义新规则的 PromQL 查询表达式。

   4

   警报规则分配给警报的严重性。

   5

   与警报关联的消息。

3. 将配置文件应用到集群：

   $ oc apply -f example-app-alerting-rule.yaml

流程

1. 列出 <project> 中的警报规则：

   $ oc -n <project> get prometheusrule

2. 要列出警报规则的配置，请运行以下命令：

   $ oc -n <project> get prometheusrule <rule> -o yaml

流程

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

2. 在 Filter 下拉菜单中选择 Platform 和 User 来源。

   注意

   默认会选择 Platform 来源。

流程

1. 在 Administrator 视角中，进入 Administration → Cluster Settings → Configuration → Alertmanager。

   注意

   或者，您还可以通过 notification drawer 访问同一页面。选择 OpenShift Container Platform Web 控制台右上角的铃铛图标，并在 AlertmanagerReceiverNotConfigured 警报中选择 Configure。

2. 在页面的 Receivers 部分中，点 Create Receiver。
3. 在 Create Receiver 表单中，添加 Receiver Name，然后从列表中选择 Receiver Type。

4. 编辑接收器配置：

   • 对于 PagerDuty 接收器：

     1. 选择集成类型并添加 PagerDuty 集成密钥。
     2. 添加 PagerDuty 安装的 URL。
     3. 如果要编辑客户端和事件详情或严重性规格，请点 Show advanced configuration。

   • 对于 Webhook 接收器：

     1. 添加将 HTTP POST 请求发送到的端点。
     2. 如果要编辑将已解析的警报发送给接收器的默认选项，请点 Show advanced configuration。

   • 对于电子邮件接收器：

     1. 添加要将通知发送到的电子邮件地址。
     2. 添加 SMTP 配置详情，包括发送通知的地址、用来发送电子邮件的智能主机和端口号、SMTP 服务器的主机名以及验证详情。
     3. 选择是否需要 TLS。
     4. 如果要将默认选项编辑为不向接收器发送已解析的警报，或编辑电子邮件通知正文配置，请点 Show advanced configuration。

   • 对于 Slack 接收器：

     1. 添加 Slack Webhook 的 URL。
     2. 添加要将通知发送到的 Slack 频道或用户名。
     3. 如果要将默认选项编辑为不向接收器发送已解析的警报，或编辑图标和用户名配置，请选择 Show advanced configuration。您还可以选择是否查找并链接频道名称和用户名。

5. 默认情况下，如果触发的警报带有与所有选择器匹配的标签，将被发送到接收器。如果您希望触发的警报在发送到接收器前完全匹配的标签值，请执行以下步骤：

   1. 在表单的 Routing Labels 部分中添加路由标签名称和值。
   2. 点 Add label 来添加更多路由标签。
6. 点 Create 创建接收器。

流程

1. 创建用于警报路由的 YAML 文件。此流程中的示例使用名为 example-app-alert-routing.yaml 的文件。

2. 在文件中添加 AlertmanagerConfig YAML 定义。例如：

   apiVersion: monitoring.coreos.com/v1beta1
   kind: AlertmanagerConfig
   metadata:
     name: example-routing
     namespace: ns1
   spec:
     route:
       receiver: default
       groupBy: [job]
     receivers:
     - name: default
       webhookConfigs:
       - url: https://example.org/post

   注意

   对于用户定义的警报规则，用户定义的路由范围到定义资源的命名空间。例如，AlertmanagerConfig 对象中为命名空间 ns1 定义的路由配置仅适用于同一命名空间中的 PrometheusRules 资源。

3. 保存该文件。

4. 将资源应用到集群：

   $ oc apply -f example-app-alert-routing.yaml

   配置会自动应用到 Alertmanager pod。

流程

1. 打开 Alertmanager YAML 配置文件：

   • 通过 CLI 打开 Alertmanager 配置：

     1. 将当前活跃的 Alertmanager 配置从 alertmanager-main secret 输出到 alertmanager.yaml 文件中：

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

     2. 打开 alertmanager.yaml 文件。

   • 从 OpenShift Container Platform Web 控制台打开 Alertmanager 配置：

     1. 进入 web 控制台的 Administration → Cluster Settings → Configuration → Alertmanager → YAML 页面。

2. 通过更新 YAML 中的参数来编辑 Alertmanager 配置：

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

   1

   指定在为一组警报收集初始警报时 Alertmanager 在发送通知时等待的时间。

   2

   指定 Alertmanager 向已发送初始通知的一组警报发送有关新警报的通知前必须经过的时间。

   3

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

   4

   指定触发警报的服务名称。

   5

   指定与警报匹配的标签。

   6

   指定要用于警报的接收器名称。

   7

   指定接收器配置。

   重要
   • 使用 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. 应用文件中的新配置：

   • 要从 CLI 应用更改，请运行以下命令：

     $ 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=-

   • 要从 OpenShift Container Platform Web 控制台应用更改，请点 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> 3

   1

   指定与警报匹配的标签。这个示例将带有 service="prometheus-example-monitor" 标签的所有警报作为目标。

   2

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

   3

   指定接收器配置。

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=-