×

确定用户定义项目指标不可用的原因

如果监控用户定义项目时指标未显示,请按照以下步骤进行故障排除。

步骤
  1. 查询指标名称并验证项目是否正确

    1. 在 Web 控制台的**开发者**视角中,单击**观察**并转到**指标**选项卡。

    2. 在**项目:**列表中选择要查看其指标的项目。

    3. 从**选择查询**列表中选择现有查询,或通过向**表达式**字段添加 PromQL 查询来运行自定义查询。

      指标将显示在图表中。

      查询必须基于每个项目进行。显示的指标与您选择的项目相关。

  2. 验证您想要获取指标的 Pod 是否正在主动提供指标。运行以下 oc exec 命令进入 Pod 以定位 podIPport/metrics

    $ oc exec <sample_pod> -n <sample_namespace> -- curl <target_pod_IP>:<port>/metrics

    您必须在安装了 curl 的 Pod 上运行该命令。

    以下示例输出显示具有有效版本指标的结果。

    示例输出
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    # HELP version Version information about this binary-- --:--:-- --:--:--     0
    # TYPE version gauge
    version{version="v0.1.0"} 1
    100   102  100   102    0     0  51000      0 --:--:-- --:--:-- --:--:-- 51000

    无效输出表示相应的应用程序存在问题。

  3. 如果您使用的是 PodMonitor CRD,请验证 PodMonitor CRD 是否使用标签匹配配置为指向正确的 Pod。有关更多信息,请参阅 Prometheus Operator 文档。

  4. 如果您使用的是 ServiceMonitor CRD,并且 Pod 的 /metrics 端点显示指标数据,请按照以下步骤验证配置

    1. 验证服务是否指向正确的 /metrics 端点。此输出中的服务标签必须与服务监控器标签和后续步骤中服务定义的/metrics端点匹配。

      $ oc get service
      示例输出
      apiVersion: v1
      kind: Service (1)
      metadata:
        labels: (2)
          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
      1 指定这是一个服务 API。
      2 指定此服务正在使用的标签。
    2. 查询 serviceIPport/metrics 端点以查看与您之前在 Pod 上运行的 curl 命令相同的指标

      1. 运行以下命令查找服务 IP

        $ oc get service -n <target_namespace>
      2. 查询 /metrics 端点

        $ oc exec <sample_pod> -n <sample_namespace> -- curl <service_IP>:<port>/metrics

        有效的指标在以下示例中返回。

        示例输出
        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
        100   102  100   102    0     0  51000      0 --:--:-- --:--:-- --:--:--   99k
        # HELP version Version information about this binary
        # TYPE version gauge
        version{version="v0.1.0"} 1
    3. 使用标签匹配验证 ServiceMonitor 对象是否配置为指向所需的服务。为此,请将 oc get service 输出中的 Service 对象与 oc get servicemonitor 输出中的 ServiceMonitor 对象进行比较。标签必须匹配才能显示指标。

      例如,从前面的步骤中,请注意 Service 对象如何具有 app: prometheus-example-app 标签,以及 ServiceMonitor 对象如何具有相同的 app: prometheus-example-app 匹配标签。

  5. 如果一切看起来有效但指标仍然不可用,请联系支持团队以寻求进一步帮助。

确定 Prometheus 消耗大量磁盘空间的原因

开发人员可以创建标签来定义指标的属性,形式为键值对。潜在键值对的数量对应于属性可能值的数目。具有无限数量潜在值的属性称为无界属性。例如,customer_id 属性是无界的,因为它具有无限数量的可能值。

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

当 Prometheus 消耗大量磁盘空间时,您可以采取以下措施:

  • 使用 Prometheus HTTP API 检查时间序列数据库 (TSDB) 状态,以获取有关哪些标签正在创建最多时间序列数据的更多信息。此操作需要集群管理员权限。

  • 检查正在收集的抓取样本数量

  • 减少创建的唯一时间序列数量,方法是减少分配给用户定义指标的未绑定属性的数量。

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

  • 对跨用户定义项目可以抓取的样本数量强制执行限制。这需要集群管理员权限。

先决条件
  • 您已作为具有 `dedicated-admin` 角色的用户访问集群。

  • 您已安装 OpenShift CLI ( `oc` )。

步骤
  1. 在**管理员**视角中,导航到**监控** → **指标**。

  2. 在**表达式**字段中输入 Prometheus 查询语言 (PromQL) 查询。以下示例查询有助于识别可能导致高磁盘空间消耗的高基数指标。

    • 通过运行以下查询,您可以识别出抓取样本数量最多的十个作业。

      topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))
    • 通过运行以下查询,您可以通过识别在过去一小时内创建最多时间序列数据的十个作业来查明时间序列波动。

      topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))
  3. 调查分配给具有高于预期抓取样本计数的指标的未绑定标签值的个数。

    • 如果指标与用户定义的项目相关,请检查分配给您的工作负载的指标键值对。这些是通过应用程序级别的 Prometheus 客户端库实现的。尝试限制标签中引用的未绑定属性的数量。

    • 如果指标与核心 OpenShift Dedicated 项目相关,请在Red Hat 客户门户上创建一个 Red Hat 支持案例。

  4. 以 `dedicated-admin` 用户身份登录后,请按照以下步骤使用 Prometheus HTTP API 查看 TSDB 状态:

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

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

      $ TOKEN=$(oc whoami -t)
    3. 运行以下命令查询 Prometheus 的 TSDB 状态:

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"
      示例输出
      "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},
      ...

解决针对 Prometheus 触发的 KubePersistentVolumeFillingUp 警报

作为集群管理员,您可以解决针对 Prometheus 触发的 `KubePersistentVolumeFillingUp` 警报。

当 `openshift-monitoring` 项目中 `prometheus-k8s-*` pod 声明的持久卷 (PV) 的剩余总空间少于 3% 时,此严重警报将触发。这可能会导致 Prometheus 运行异常。

有两个 `KubePersistentVolumeFillingUp` 警报:

  • 严重警报:当挂载的 PV 的剩余总空间少于 3% 时,带有 `severity="critical"` 标签的警报将被触发。

  • 警告警报:当挂载的 PV 的剩余总空间少于 15%,并且预计在四天内填满时,带有 `severity="warning"` 标签的警报将被触发。

要解决此问题,您可以删除 Prometheus 时间序列数据库 (TSDB) 块,为 PV 创建更多空间。

先决条件
  • 您已作为具有 `dedicated-admin` 角色的用户访问集群。

  • 您已安装 OpenShift CLI ( `oc` )。

步骤
  1. 运行以下命令列出所有 TSDB 块的大小,按从旧到新的顺序排序:

    $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \(1)
    -c prometheus --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \(1)
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
    -- sh -c 'cd /prometheus/;du -hs $(ls -dt */ | grep -Eo "[0-9|A-Z]{26}")'
    1 将 `<prometheus_k8s_pod_name>` 替换为 `KubePersistentVolumeFillingUp` 警报说明中提到的 pod。
    示例输出
    308M    01HVKMPKQWZYWS8WVDAYQHNMW6
    52M     01HVK64DTDA81799TBR9QDECEZ
    102M    01HVK64DS7TRZRWF2756KHST5X
    140M    01HVJS59K11FBVAPVY57K88Z11
    90M     01HVH2A5Z58SKT810EM6B9AT50
    152M    01HV8ZDVQMX41MKCN84S32RRZ1
    354M    01HV6Q2N26BK63G4RYTST71FBF
    156M    01HV664H9J9Z1FTZD73RD1563E
    216M    01HTHXB60A7F239HN7S2TENPNS
    104M    01HTHMGRXGS0WXA3WATRXHR36B
  2. 确定可以删除哪些块以及可以删除多少块,然后删除这些块。以下示例命令从 `prometheus-k8s-0` pod 中删除三个最旧的 Prometheus TSDB 块:

    $ oc debug prometheus-k8s-0 -n openshift-monitoring \
    -c prometheus --image=$(oc get po -n openshift-monitoring prometheus-k8s-0 \
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
    -- sh -c 'ls -latr /prometheus/ | egrep -o "[0-9|A-Z]{26}" | head -3 | \
    while read BLOCK; do rm -r /prometheus/$BLOCK; done'
  3. 运行以下命令验证挂载的 PV 的使用情况,并确保有足够的可用空间:

    $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \(1)
    --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \(1)
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') -- df -h /prometheus/
    1 将 `<prometheus_k8s_pod_name>` 替换为 `KubePersistentVolumeFillingUp` 警报说明中提到的 pod。

    以下示例输出显示由 `prometheus-k8s-0` pod 声明的已挂载 PV,剩余空间为 63%:

    示例输出
    Starting pod/prometheus-k8s-0-debug-j82w4 ...
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme0n1p4  40G   15G  40G  37% /prometheus
    
    Removing debug pod ...