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

调查监控问题

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

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

  • 您自己的指标不可用。

  • Prometheus 占用大量磁盘空间。

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

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

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

前提条件

  • 您具有 `dedicated-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 Dedicated Web 控制台 UI 的“指标目标”页面上查看端点的目标状态。**

    1. 登录 OpenShift Dedicated 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

      如果配置文件映射中包含无法识别的Prometheus Operator loglevel值，则prometheus-operator Pod 可能无法成功重启。

    6. 查看调试日志，以确定Prometheus Operator是否正在使用ServiceMonitor资源。查看日志中是否存在其他相关错误。

其他资源

确定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 ...