第 12 章 监控问题的故障排除

流程

1. 确保您的项目没有从用户工作负载监控中被排除。以下示例使用 ns1 项目。

   1. 验证项目没有附加 openshift.io/user-monitoring=false 标签：

      $ oc get namespace ns1 --show-labels | grep 'openshift.io/user-monitoring=false'

      注意

      用户工作负载项目设置的默认标签为 openshift.io/user-monitoring=true。但是，除非手动应用了该标签，否则标签不可见。

   2. 如果附加了标签，请删除该标签：

      从项目中删除该标签的示例

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

      输出示例

      namespace/ns1 unlabeled

2. 在服务和 ServiceMonitor 资源配置中，检查对应的标签是否匹配。以下示例使用 prometheus-example-app 服务、prometheus-example-monitor 服务监控和 ns1 项目。

   1. 获取服务中定义的标签。

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

      输出示例

        labels:
          app: prometheus-example-app

   2. 检查 ServiceMonitor 资源配置中的 matchLabels 定义是否与上一步中的标签输出匹配。

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

      输出示例

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

      注意

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

3. 在 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

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

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

5. 在 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. 保存文件以使改变生效。受影响的 prometheus-operator Pod 会自动重新部署。

   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 资源。查看日志中的其他相关错误。