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

监控问题排查

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

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

      如果在 config map 中包含无法识别的 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 ...