7.7. 调查监控问题


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

如果出现问题,请使用这些步骤:

  • 您自己的指标不可用。
  • Prometheus 消耗大量磁盘空间。
  • KubePersistentVolumeFillingUp 警报正在触发 Prometheus。

7.7.1. 调查用户定义的项目指标不可用的原因

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

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。
  • 您已为用户定义的项目启用并配置了监控。
  • 您已创建了 ServiceMonitor 资源。

流程

  1. 确保您的项目和资源没有不包括在用户工作负载监控中。以下示例使用 ns1 项目。

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

      $ oc get namespace ns1 --show-labels | grep 'openshift.io/user-monitoring=false'
      Copy to Clipboard Toggle word wrap
      注意

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

    2. 验证 ServiceMonitorPodMonitor 资源没有附加 openshift.io/user-monitoring=false 标签。以下示例检查 prometheus-example-monitor 服务监控器。

      $ oc -n ns1 get servicemonitor prometheus-example-monitor --show-labels | grep 'openshift.io/user-monitoring=false'
      Copy to Clipboard Toggle word wrap
    3. 如果附加了标签,请删除该标签:

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

      $ oc label namespace ns1 'openshift.io/user-monitoring-'
      Copy to Clipboard Toggle word wrap

      从资源中删除标签的示例

      $ oc -n ns1 label servicemonitor prometheus-example-monitor 'openshift.io/user-monitoring-'
      Copy to Clipboard Toggle word wrap

      输出示例

      namespace/ns1 unlabeled
      Copy to Clipboard Toggle word wrap

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

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

      $ oc -n ns1 get service prometheus-example-app -o yaml
      Copy to Clipboard Toggle word wrap

      输出示例

        labels:
          app: prometheus-example-app
      Copy to Clipboard Toggle word wrap

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

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      Copy to Clipboard Toggle word wrap

      注意

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

  3. openshift-user-workload-monitoring 项目中检查 Prometheus Operator 的日志。

    1. 列出 openshift-user-workload-monitoring 项目中的 Pod:

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap

      如果服务监控器出现问题,日志可能包含类似本例的错误:

      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
      Copy to Clipboard Toggle word wrap
  4. 在 OpenShift Dedicated Web 控制台 UI 中的 Metrics 目标 页面中查看您的端点的目标状态。

    1. 登录 OpenShift Dedicated Web 控制台,再进入 Observe Targets
    2. 在列表中找到指标端点,并在 Status 列中查看目标的状态。
    3. 如果 StatusDown,点端点的 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
      Copy to Clipboard Toggle word wrap
    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
      # ...
      Copy to Clipboard Toggle word wrap
    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"
      Copy to Clipboard Toggle word wrap

      输出示例

              - --log-level=debug
      Copy to Clipboard Toggle word wrap

      Debug 级别日志记录将显示 Prometheus Operator 发出的所有调用。

    5. 检查 prometheus-operator Pod 是否正在运行:

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap
      注意

      如果配置映射中包含了一个未识别的 Prometheus Operator loglevel 值,则 prometheus-operator Pod 可能无法成功重启。

    6. 查看 debug 日志,以了解 Prometheus Operator 是否在使用 ServiceMonitor 资源。查看日志中的其他相关错误。

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

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

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

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

  • 使用 Prometheus HTTP API 检查时间序列数据库(TSDB)状态,以了解有关哪些标签创建最多时间序列数据的更多信息。这样做需要集群管理员特权。
  • 检查正在收集的提取示例数量
  • 减少创建的唯一时间序列数量,您可以减少分配给用户定义的指标的未绑定属性数量

    注意

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

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

先决条件

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

流程

  1. 在 OpenShift Dedicated Web 控制台中,进入 Observe Metrics
  2. Expression 字段中输入 Prometheus Query Language (PromQL) 查询。以下示例查询有助于识别可能导致高磁盘空间消耗的高卡性指标:

    • 通过运行以下查询,您可以识别具有最高提取示例数的十个作业:

      topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))
      Copy to Clipboard Toggle word wrap
    • 通过运行以下查询,您可以通过识别在上一小时内创建了最多时间序列数据的十个作业,从而找出相关的时间序列:

      topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))
      Copy to Clipboard Toggle word wrap
  3. 如果指标的提取示例数大于预期,请检查分配给指标的未绑定标签值数量:

    • 如果指标与用户定义的项目相关,请查看分配给您的工作负载的指标键-值对。它们通过应用程序级别的 Prometheus 客户端库实施。尝试限制标签中引用的未绑定属性数量。
    • 如果指标与 OpenShift Dedicated 核心项目相关,请在红帽客户门户网站上创建一个红帽支持问题单。
  4. dedicated-admin 身份登录时,按照以下步骤使用 Prometheus HTTP API 查看 TSDB 状态:

    1. 运行以下命令来获取 Prometheus API 路由 URL:

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath='{.status.ingress[].host}')
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令来提取身份验证令牌:

      $ TOKEN=$(oc whoami -t)
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令,查询 Prometheus 的 TSDB 状态:

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"
      Copy to Clipboard Toggle word wrap

      输出示例

      "status": "success","data":{"headStats":{"numSeries":507473,
      "numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
      "maxTime":1712257935346},"seriesCountByMetricName":
      [{"name":"etcd_request_duration_seconds_bucket","value":51840},
      {"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
      ...
      Copy to Clipboard Toggle word wrap

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat