流程

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. 保存文件以使改变生效。新配置中指定的组件会自动移到新节点上。

   注意

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

   警告

   当您将更改保存到监控配置映射时，可能会重新部署相关项目中的 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>:
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class>
                  resources:
                    requests:
                      storage: <amount_of_storage>

        如需有关如何指定 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: local-storage
                  resources:
                    requests:
                      storage: 40Gi

        在上例中，由 Local Storage Operator 创建的存储类称为 local-storage。

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

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 10Gi

   • 要为监控用户定义的项目的组件配置 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>:
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class>
                  resources:
                    requests:
                      storage: <amount_of_storage>

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

        以下示例配置了一个 PVC 来为监控用户定义的项目的 Prometheus 实例声明本地持久性存储：

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

        在上例中，由 Local Storage Operator 创建的存储类称为 local-storage。

        以下示例配置了一个 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: local-storage
                  resources:
                    requests:
                      storage: 10Gi

        注意

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

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

   注意

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

   警告

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

流程

1. 编辑 ConfigMap 对象：

   • 为监控 OpenShift Container Platform 核心项目的组件重新定义 PVC 的大小：

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

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

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

        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

        指定核心监控组件。

        2

        指定存储类。

        3

        指定存储卷的新大小。

        以下示例配置了一个 PVC，它将监控 OpenShift Container Platform 核心组件的 Prometheus 实例的本地持久性存储设置为 100GB：

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

        以下示例配置了一个 PVC，将 Alertmanager 的本地持久性存储设置为 40GB：

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

   • 为监控用户定义的项目的组件调整 PVC 大小：

     注意

     您可以调整监控用户定义的项目的 Thanos Ruler 和 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:
                  storageClassName: <storage_class> 2
                  resources:
                    requests:
                      storage: <amount_of_storage> 3

        1

        指定核心监控组件。

        2

        指定存储类。

        3

        指定存储卷的新大小。

        以下示例将监控用户定义的项目的 Prometheus 实例的 PVC 大小配置为 100GB：

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

        以下示例将 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:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 20Gi

        注意

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

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

   警告

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

3. 使用更新的存储请求手动对每个 PVC 进行补丁。以下示例将 openshift-monitoring 命名空间中的 Prometheus 组件的存储大小调整为 100Gi：

   $ for p in $(oc -n openshift-monitoring get pvc -l app.kubernetes.io/name=prometheus -o jsonpath='{range .items[*]}{.metadata.name} {end}'); do \
     oc -n openshift-monitoring patch pvc/${p} --patch '{"spec": {"resources": {"requests": {"storage":"100Gi"}}}}'; \
     done

4. 使用 --cascade=orphan 参数删除底层 StatefulSet:

   $ oc delete statefulset -l app.kubernetes.io/name=prometheus --cascade=orphan

流程

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>

        将 <time_specification> 替换为一个数字，后面紧跟 ms（毫秒）、s（秒）、m（分钟）、h（小时）、d（天）、w（周）或 y（年）。

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

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

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

        将 <time_specification> 替换为一个数字，后面紧跟 ms（毫秒）、s（秒）、m（分钟）、h（小时）、d（天）、w（周）或 y（年）。

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

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

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

   注意

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

   警告

   一旦将更改保存到监控配置映射，可能会重新部署相关项目中的 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. 在 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. 保存文件以使改变生效。该限制会自动应用。

   注意

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

   警告

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

流程

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 → Role Bindings → Create Binding。
2. 在 Binding Type 部分中，选择“Namespace Role Binding”类型。
3. 在 Name 字段中输入角色绑定的名称。

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

   重要

   监控角色将绑定到您在 Namespace 字段中应用的项目。您使用此流程向用户授予的权限将只应用于所选项目。

5. 在 Role Name 列表中选择 monitoring-rules-view、monitoring-rules-edit 或 monitoring-edit。
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.1
           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. 为 ServiceMonitor 资源配置创建一个 YAML 文件。在本例中，该文件名为 example-app-service-monitor.yaml。

2. 添加以下 ServiceMonitor 资源配置详情：

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

   这会定义一个 ServiceMonitor 资源，用于提取由 prometheus-example-app 示例服务公开的指标，其中包含 version 指标。

   注意

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

3. 将配置应用到集群：

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

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

4. 您可以检查 ServiceMonitor 资源是否正在运行：

   $ oc -n ns1 get servicemonitor

   输出示例

   NAME                         AGE
   prometheus-example-monitor   81m

流程

1. 在 OpenShift Container Platform Web 控制台内的 Administrator 视角中，选择 Observe → Metrics。
2. 选择 Insert Metric at Cursor 来查看预定义的查询列表。
3. 要创建自定义查询，请将 Prometheus Query Language (PromQL) 查询添加到 Expression 字段。
4. 要添加多个查询，选择 Add Query。
5. 要删除查询，选择查询旁边的 ，然后选择 Delete query。
6. 要禁止运行查询，请选择查询旁边的 并选择 Disable query。

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

   注意

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

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

流程

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

3. 从 Select Query 列表中选择查询，或者通过选择 Show PromQL 运行自定义 PromQL 查询。

   注意

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

1. 最初，图表中显示所有启用的查询中的所有指标。您可以要选择显示哪些指标。

   注意

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

   • 要隐藏查询的所有指标，请点击 查询并点击 Hide all series。
   • 要隐藏特定的指标，请转至查询表，然后点击指标名称旁边带颜色的方块。

2. 要放大图表并更改时间范围，请执行以下操作之一：

   • 点击图表并在水平方向上拖动，以可视化方式选择时间范围。
   • 使用左上角的菜单来选择时间范围。
3. 要重置时间范围，请选择 Reset Zoom。
4. 要显示所有查询在特定时间点的输出，请将鼠标光标停留在图表中的对应点上。弹出框中会显示查询输出。
5. 要隐藏图表，请选择 Hide Graph。

1. 要放大图表并更改时间范围，请执行以下操作之一：

   • 点击图表并在水平方向上拖动，以可视化方式选择时间范围。
   • 使用左上角的菜单来选择时间范围。
2. 要重置时间范围，请选择 Reset Zoom。
3. 要显示所有查询在特定时间点的输出，请将鼠标光标停留在图表中的对应点上。弹出框中会显示查询输出。

流程

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

2. 向 YAML 文件添加警报规则配置。例如：

   注意

   当创建警报规则时，如果在其他项目中存在具有相同名称的规则，则对其强制使用项目标签。

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     name: example-alert
     namespace: ns1
   spec:
     groups:
     - name: example
       rules:
       - alert: VersionAlert
         expr: version{job="prometheus-example-app"} == 0

   此配置会创建一个名为 example-alert 的警报规则。当示例服务公开的 version 指标变为 0 时，警报规则会触发警报。

   重要

   用户定义的警报规则可以包含其自身项目的指标和集群指标。您不能包含其他用户定义的项目的指标。

   例如，用户定义的项目 ns1 的警报规则可以包含来自 ns1 的指标和集群指标，如 CPU 和内存指标。但是，该规则无法包含来自 ns2 的指标。

   另外，您无法为 openshift-* 核心 OpenShift Container Platform 项目创建警报规则。OpenShift Container Platform 监控默认为这些项目提供一组警报规则。

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

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

   创建警报规则需要一些时间。

流程

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

2. 向 YAML 文件添加警报规则配置，该文件中包含键为 openshift.io/prometheus-rule-evaluation-scope 且值为 leaf- prometheus 的标签。例如：

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     name: example-alert
     namespace: ns1
     labels:
       openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus
   spec:
     groups:
     - name: example
       rules:
       - alert: VersionAlert
         expr: version{job="prometheus-example-app"} == 0

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

   $ 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. 进入到 OpenShift Container Platform Web 控制台中的 Observe → Alerting → Silences 页面。
2. 选择 Create Silence。
3. 在 Create Silence 表单中设置警报的时间表、持续时间和标签详情。您还必须为静默添加注释。
4. 要为与您在上一步中输入的标签选择器匹配的警报创建静默，请选择 Silence。

1. 进入到 Observe → Alerting → Silences 页面。

2. 针对您想要修改的静默，选择最后一列中的 ，然后选择 Edit silence。

   另外，您还可以在静默的 Silence Details 页面中选择 Actions → Edit Silence。

3. 在 Edit Silence 页面中，输入您的更改并选择 Silence。这会使现有的静默到期，并以所选配置创建新静默。

1. 进入到 Observe → <project_name> → Alerts 页面。
2. 选择警报名称左侧的 > 来展开警报的详情。选择展开视图中的警报名称以打开警报的 Alert Details 页面。
3. 在该页面的 Silenced By 部分中选择静默名称，以导航到该静默的 Silence Details 页面。
4. 选择静默的名称以导航到其 Silence Details 页面。
5. 在静默的 Silence Details 页面中选择 Actions → Edit Silence。
6. 在 Edit Silence 页面中，输入您的更改并选择 Silence。这会使现有的静默到期，并以所选配置创建新静默。

1. 进入到 Observe → Alerting → Silences 页面。

2. 针对您想要修改的静默，选择最后一列中的 ，然后选择 Expire silence。

   另外，您还可以在静默的 Silence Details 页面中选择 Actions → Expire Silence。

1. 进入到 Observe → <project_name> → Alerts 页面。
2. 选择警报名称左侧的 > 来展开警报的详情。选择展开视图中的警报名称以打开警报的 Alert Details 页面。
3. 在该页面的 Silenced By 部分中选择静默名称，以导航到该静默的 Silence Details 页面。
4. 选择静默的名称以导航到其 Silence Details 页面。
5. 在静默的 Silence Details 页面中选择 Actions → Expire Silence。

流程

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. 如果想要使用正则表达式，请选择 Regular Expression。
   3. 选择 Add Label 来添加更多路由标签。
6. 选择 Create 来创建接收器。

流程

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

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

   apiVersion: monitoring.coreos.com/v1alpha1
   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. 为 Bare Metal Event Relay 创建命名空间。

   1. 将以下 YAML 保存到 bare-metal-events-namespace.yaml 文件中：

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-bare-metal-events
        labels:
          name: openshift-bare-metal-events
          openshift.io/cluster-monitoring: "true"

   2. 创建 Namespace CR：

      $ oc create -f bare-metal-events-namespace.yaml

2. 为 Bare Metal Event Relay Operator 创建 Operator 组。

   1. 将以下 YAML 保存到 bare-metal-events-operatorgroup.yaml 文件中：

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: bare-metal-event-relay-group
        namespace: openshift-bare-metal-events
      spec:
        targetNamespaces:
        - openshift-bare-metal-events

   2. 创建 OperatorGroup CR：

      $ oc create -f bare-metal-events-operatorgroup.yaml

3. 订阅裸机恢复事件中继。

   1. 将以下 YAML 保存到 bare-metal-events-sub.yaml 文件中：

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bare-metal-event-relay-subscription
        namespace: openshift-bare-metal-events
      spec:
        channel: "stable"
        name: bare-metal-event-relay
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. 创建 Subscription CR：

      $ oc create -f bare-metal-events-sub.yaml

流程

1. 使用 OpenShift Container Platform Web 控制台安装 Bare Metal Event Relay：

   1. 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
   2. 从可用的 Operator 列表中选择 Bare Metal Event Relay，然后点 Install。
   3. 在 Install Operator 页面中，选择或创建一个命名空间，选择 openshift-bare-metal-events，然后点 Install。

1. 切换到 Operators → Installed Operators 页面。

2. 确保项目中列出了 Bare Metal Event Relay，Status 为 InstallSucceeded。

   注意

   在安装过程中，Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息，您可以忽略这个 Failed 信息。

流程

1. 通过运行以下 curl 命令确认节点硬件启用了 Redfish EventService ：

   curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"

   其中：

   bmc_ip_address

   是生成 Redfish 事件的 BMC 的 IP 地址。

   输出示例

   {
      "@odata.context": "/redfish/v1/$metadata#EventService.EventService",
      "@odata.id": "/redfish/v1/EventService",
      "@odata.type": "#EventService.v1_0_2.EventService",
      "Actions": {
         "#EventService.SubmitTestEvent": {
            "EventType@Redfish.AllowableValues": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
            "target": "/redfish/v1/EventService/Actions/EventService.SubmitTestEvent"
         }
      },
      "DeliveryRetryAttempts": 3,
      "DeliveryRetryIntervalSeconds": 30,
      "Description": "Event Service represents the properties for the service",
      "EventTypesForSubscription": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
      "EventTypesForSubscription@odata.count": 5,
      "Id": "EventService",
      "Name": "Event Service",
      "ServiceEnabled": true,
      "Status": {
         "Health": "OK",
         "HealthRollup": "OK",
         "State": "Enabled"
      },
      "Subscriptions": {
         "@odata.id": "/redfish/v1/EventService/Subscriptions"
      }
   }

2. 运行以下命令，获取集群的 Bare Metal 事件中继服务路由：

   $ oc get route -n openshift-bare-metal-events

   输出示例

   NAME             HOST/PORT                                                                                           PATH   SERVICES                 PORT   TERMINATION   WILDCARD
   hw-event-proxy   hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com          hw-event-proxy-service   9087   edge          None

3. 创建一个 BMCEventSubscription 资源来订阅 Redfish 事件：

   1. 将以下 YAML 保存到 bmc_sub.yaml 文件中：

      apiVersion: metal3.io/v1alpha1
      kind: BMCEventSubscription
      metadata:
        name: sub-01
        namespace: openshift-machine-api
      spec:
         hostName: <hostname> 1
         destination: <proxy_service_url> 2
         context: ''

      1

      指定生成 Redfish 事件的 worker 节点的名称或 UUID。

      2

      指定裸机事件代理服务，例如 https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook。

   2. 创建 BMCEventSubscription CR：

      $ oc create -f bmc_sub.yaml

4. 可选： 要删除 BMC 事件订阅，请运行以下命令：

   $ oc delete -f bmc_sub.yaml

5. 可选： 要在不创建 BMCEventSubscription CR 的情况下手动创建 Redfish 事件订阅，请运行以下 curl 命令并指定 BMC 用户名和密码。

   $ curl -i -k -X POST -H "Content-Type: application/json"  -d '{"Destination": "https://<proxy_service_url>", "Protocol" : "Redfish", "EventTypes": ["Alert"], "Context": "root"}' -u <bmc_username>:<password> 'https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions' –v

   其中：

   proxy_service_url

   裸机事件代理服务，例如 https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook。

   bmc_ip_address

   是生成 Redfish 事件的 BMC 的 IP 地址。

   输出示例

   HTTP/1.1 201 Created
   Server: AMI MegaRAC Redfish Service
   Location: /redfish/v1/EventService/Subscriptions/1
   Allow: GET, POST
   Access-Control-Allow-Origin: *
   Access-Control-Expose-Headers: X-Auth-Token
   Access-Control-Allow-Headers: X-Auth-Token
   Access-Control-Allow-Credentials: true
   Cache-Control: no-cache, must-revalidate
   Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>; rel=describedby
   Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>
   Link: </redfish/v1/EventService/Subscriptions>; path=
   ETag: "1651135676"
   Content-Type: application/json; charset=UTF-8
   OData-Version: 4.0
   Content-Length: 614
   Date: Thu, 28 Apr 2022 08:47:57 GMT

流程

1. 运行以下 curl 命令，检查 BMC 的当前订阅：

   $ curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions

   其中：

   bmc_ip_address

   是生成 Redfish 事件的 BMC 的 IP 地址。

   输出示例

   % Total % Received % Xferd Average Speed Time Time Time Current
   Dload Upload Total Spent Left Speed
   100 435 100 435 0 0 399 0 0:00:01 0:00:01 --:--:-- 399
   {
     "@odata.context": "/redfish/v1/$metadata#EventDestinationCollection.EventDestinationCollection",
     "@odata.etag": ""
     1651137375 "",
     "@odata.id": "/redfish/v1/EventService/Subscriptions",
     "@odata.type": "#EventDestinationCollection.EventDestinationCollection",
     "Description": "Collection for Event Subscriptions",
     "Members": [
     {
       "@odata.id": "/redfish/v1/EventService/Subscriptions/1"
     }],
     "Members@odata.count": 1,
     "Name": "Event Subscriptions Collection"
   }

   本例中配置了单个订阅：/redfish/v1/EventService/Subscriptions/1。

2. 可选： 要使用 curl 删除 /redfish/v1/EventService/Subscriptions/1 订阅，请运行以下命令并指定 BMC 用户名和密码：

   $ curl --globoff -L -w "%{http_code} %{url_effective}\n" -k -u <bmc_username>:<password >-H "Content-Type: application/json" -d '{}' -X DELETE https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions/1

   其中：

   bmc_ip_address

   是生成 Redfish 事件的 BMC 的 IP 地址。

流程

1. 创建 HardwareEvent 自定义资源(CR)：

   1. 将以下 YAML 保存到 hw-event.yaml 文件中：

      apiVersion: "event.redhat-cne.org/v1alpha1"
      kind: "HardwareEvent"
      metadata:
        name: "hardware-event"
      spec:
        nodeSelector:
          node-role.kubernetes.io/hw-event: "" 1
        transportHost: "amqp://amq-router-service-name.amq-namespace.svc.cluster.local" 2
        logLevel: "debug" 3
        msgParserTimeout: "10" 4

      1

      必需。使用 nodeSelector 字段来带有指定标签的目标节点，如 node-role.kubernetes.io/hw-event: ""。

      2

      必需。使用 AMQP 协议在传输层提供事件的 AMQP 主机。

      3

      可选的。默认值为 debug。在 hw-event-proxy 日志中设置日志级别。可用的日志级别如下： fatal、error、warning、info、debug、trace。

      4

      可选的。为 Message Parser 设置超时值（毫秒）。如果在超时时间内没有响应消息解析请求，原始硬件事件信息会被传递给云原生事件框架。默认值为 10。

   2. 创建 HardwareEvent CR：

      $ oc create -f hardware-event.yaml

2. 创建一个 BMC 用户名和密码 Secret CR，使硬件事件代理能够访问裸机主机的 Redfish 消息 registry。

   1. 将以下 YAML 保存到 hw-event-bmc-secret.yaml 文件中：

      apiVersion: v1
      kind: Secret
      metadata:
        name: redfish-basic-auth
      type: Opaque
      stringData: 1
        username: <bmc_username>
        password: <bmc_password>
        # BMC host DNS or IP address
        hostaddr: <bmc_host_ip_address>

      1

      为 stringData 下的各种项目输入纯文本值。

   2. 创建 Secret CR：

      $ oc create -f hw-event-bmc-secret.yaml