OpenShift 文档正在迁移，很快将仅在docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

调查监控问题

OpenShift Container Platform 包含一个预配置、预安装和自动更新的监控堆栈，该堆栈提供对核心平台组件的监控。在 OpenShift Container Platform 4.17 中，集群管理员可以选择启用对用户定义项目的监控。

如果出现以下问题，请使用以下步骤

  • 您的自定义指标不可用。

  • Prometheus 正在消耗大量磁盘空间。

  • 针对 Prometheus 触发了 `KubePersistentVolumeFillingUp` 警报。

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

`ServiceMonitor` 资源使您可以确定如何使用用户定义项目中服务公开的指标。如果您已创建 `ServiceMonitor` 资源，但无法在指标 UI 中看到任何相应的指标，请按照此过程中的步骤操作。

先决条件

  • 您可以作为具有 `cluster-admin` 角色的用户访问集群。

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

  • 您已启用并配置了对用户定义项目的监控。

  • 您已创建 `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` 定义是否与上一步中的标签输出匹配。以下示例查询 `ns1` 项目中的 `prometheus-example-monitor` 服务监控器

      $ 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` 资源标签。

  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. **在 OpenShift Container Platform Web 控制台 UI 的“指标目标”页面上查看端点的目标状态。**

    1. 登录 OpenShift Container Platform Web 控制台，然后在**管理员**视角中导航到**观察** → **目标**。

    2. 在列表中找到指标端点，然后查看**状态**列中目标的状态。

    3. 如果**状态**为**关闭**，请单击端点的 URL 以在该指标目标的**目标详细信息**页面上查看更多信息。

  4. **为 `openshift-user-workload-monitoring` 项目中的 Prometheus Operator 配置调试级别日志记录。**

    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

      调试级别日志记录将显示 Prometheus Operator 执行的所有调用。

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

      $ oc -n openshift-user-workload-monitoring get pods

      如果在 ConfigMap 中包含无法识别的 Prometheus Operator `loglevel` 值，则 `prometheus-operator` Pod 可能无法成功重启。

    6. 查看调试日志以查看 Prometheus Operator 是否正在使用 `ServiceMonitor` 资源。查看其他相关错误的日志。

其他资源

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

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

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

当 Prometheus 消耗大量磁盘空间时，您可以使用以下措施

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

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

  • **通过减少分配给用户定义指标的无界属性的数量来减少创建的唯一时间序列的数量。**

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

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

先决条件

  • 您可以作为具有 `cluster-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 Container Platform 项目相关，请在Red Hat 客户门户上创建一个 Red Hat 支持案例。

  4. 以集群管理员身份登录后，请按照以下步骤使用 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 创建更多空间。

先决条件

  • 您可以作为具有 `cluster-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 ...