7.11. 调查监控问题

OpenShift Container Platform 包括一个预配置、预安装和自我更新的监控堆栈，用于监控核心平台组件。在 OpenShift Container Platform 4.10 中，集群管理员可以选择性地为用户定义的项目启用监控。

如果您自己的指标不可用，或者 Prometheus 消耗了大量磁盘空间，则可按照以下步骤操作。

7.11.1. 检查为什么用户定义的指标不可用

通过 ServiceMonitor 资源，您可以确定如何使用用户定义的项目中的服务公开的指标。如果您创建了 ServiceMonitor 资源，但无法在 Metrics UI 中看到任何对应的指标，请按该流程中所述的步骤操作。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI（oc）。
  • 您已为用户定义的工作负载启用并配置了监控。
  • 您已创建了 user-workload-monitoring-config ConfigMap 对象。
  • 您已创建了 ServiceMonitor 资源。

流程

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

其他资源

7.11.2. 确定为什么 Prometheus 消耗大量磁盘空间

开发人员可以使用键值对的形式为指标定义属性。潜在的键值对数量与属性的可能值数量对应。具有无限数量可能值的属性被称为未绑定属性。例如，customer_id 属性不绑定，因为它有无限多个可能的值。

每个分配的键值对都有唯一的时间序列。在标签中使用许多未绑定属性可导致所创建的时间序列数量出现指数增加。这可能会影响 Prometheus 性能，并消耗大量磁盘空间。

当 Prometheus 消耗大量磁盘时，您可以使用以下方法：

  • 检查正在收集的提取示例数量。
  • 检查 Prometheus UI 中的时间序列数据库（TSDB）状态以了解有关哪些标签创建最多时间序列的更多信息。这需要集群管理员特权。

  • 要减少创建的唯一时间序列数量，您可以减少分配给用户定义的指标的未绑定属性数量。

    注意

    使用绑定到一组有限可能值的属性可减少潜在的键-值对组合数量。

  • 对可在用户定义的项目中提取的示例数量实施限制。这需要集群管理员特权。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户身份访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  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。

其他资源