4.3. 为用户工作负载监控存储和记录数据


存储和记录您的指标和警报数据,配置日志以指定记录哪些活动,控制 Prometheus 保留数据的时长,并为数据设置最大磁盘空间量。这些操作可帮助您保护数据并将其用于故障排除。

4.3.1. 配置持久性存储

使用持久性存储运行集群监控以获取以下优点:

  • 通过将指标和警报数据存储在持久性卷(PV)中来保护您的指标和警报数据。因此,它们可以在 pod 重启或重新创建后保留。
  • 避免获取重复的通知,并在 Alertmanager pod 重启时丢失警报静默。
重要

在多节点集群中,您必须为 Prometheus、Alertmanager 和 Thanos Ruler 配置持久性存储,以确保高可用性。

注意

在生产环境中,强烈建议配置持久性存储。

4.3.1.1. 持久性存储的先决条件

  • 分配充足的专用持久性存储,以确保磁盘不会被填满。
  • 在配置持久性卷时,使用 Filesystem 作为 volumeMode 参数的存储类型值。

    重要
    • 不要使用原始块卷,它由 PersistentVolume 资源中的 volumeMode: Block 描述。Prometheus 无法使用原始块卷。
    • Prometheus 不支持兼容 POSIX 的文件系统。例如,一些 NFS 文件系统实现不兼容 POSIX。如果要使用 NFS 文件系统进行存储,请验证与其 NFS 实现完全兼容 POSIX 的供应商。

4.3.1.2. 配置持久性卷声明

要将持久性卷 (PV) 用于监控组件,您必须配置持久性卷声明 (PVC)。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. 将组件的 PVC 配置添加到 data/config.yaml 下:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        <component>: 
    1
    
          volumeClaimTemplate:
            spec:
              storageClassName: <storage_class> 
    2
    
              resources:
                requests:
                  storage: <amount_of_storage> 
    3
    1
    指定要配置 PVC 的监控组件。
    2
    指定现有存储类。如果没有指定存储类,则使用默认存储类。
    3
    指定所需的存储量。

    以下示例配置了一个 PVC 来声明用于 Thanos Ruler 的持久性存储:

    PVC 配置示例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          volumeClaimTemplate:
            spec:
              storageClassName: my-storage-class
              resources:
                requests:
                  storage: 10Gi

    注意

    thanosRuler 组件的存储要求取决于要评估的规则数量以及每个规则生成的样本数量。

  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署并应用新的存储配置。

    警告

    当您使用 PVC 配置更新配置映射时,受影响的 StatefulSet 对象会被重新创建,从而导致临时服务中断。

4.3.1.3. 重新定义持久性卷大小

您可以为 Prometheus、Thanos Ruler 和 Alertmanager 实例重新定义持久性卷(PV)大小。您需要手动扩展持久性卷声明 (PVC),然后更新配置组件的配置映射。

重要

您只能扩展 PVC 的大小。无法缩小存储大小。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 至少有一个 PVC 用于监控用户定义的项目的组件。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 使用更新的存储请求手动扩展 PVC。如需更多信息,请参阅 扩展持久性卷 中的"使用文件系统扩展持久性卷声明 (PVC) "。
  2. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  3. data/config.yaml 下为组件添加新存储大小:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        <component>: 
    1
    
          volumeClaimTemplate:
            spec:
              resources:
                requests:
                  storage: <amount_of_storage> 
    2
    1
    要更改存储大小的组件。
    2
    指定存储卷的新大小。它必须大于上一个值。

    以下示例将 Thanos Ruler 的新 PVC 请求设置为 20GB:

    thanosRuler 的存储配置示例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          volumeClaimTemplate:
            spec:
              resources:
                requests:
                  storage: 20Gi

    注意

    thanosRuler 组件的存储要求取决于要评估的规则数量以及每个规则生成的样本数量。

  4. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

    警告

    当您使用新存储大小更新配置映射时,受影响的 StatefulSet 对象会被重新创建,从而导致临时服务中断。

默认情况下,Prometheus 会保留 24 小时的指标数据,供用户定义的项目监控。您可以修改 Prometheus 实例的保留时间,以便在删除数据时更改。您还可以设置保留指标数据使用的最大磁盘空间量。

注意

数据压缩每两小时进行一次。因此,持久性卷 (PV) 可能会在压缩前已被填满,可能会超过 retentionSize 限制。在这种情况下,KubePersistentVolumeFillingUp 警报会触发,直到 PV 上的空间低于 retentionSize 限制。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. data/config.yaml 下添加保留时间和大小配置:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          retention: <time_specification> 
    1
    
          retentionSize: <size_specification> 
    2
    1
    保留时间:数字直接加上 ms (毫秒)、s (秒)、m (分钟)、h (小时)、d (天)、w (周)或 y (年)。您还可以组合指定时间值,如 1h30m15s
    2
    保留大小:数字直接加上 B (bytes), KB (kilobytes), MB (megabytes), GB (gigabytes), TB (terabytes), PB (petabytes), 和 EB (exabytes).。

    以下示例将 Prometheus 实例的保留时间设置为 24 小时,保留大小设为 10GB:

    为 Prometheus 设置保留时间示例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          retention: 24h
          retentionSize: 10GB

  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

4.3.2.1. 修改 Thanos Ruler 指标数据的保留时间

默认情况下,对于用户定义的项目,Thanos Ruler 会在 24 小时内自动保留指标数据。您可以通过在 openshift-user-workload-monitoring 命名空间中指定 user-workload-monitoring-config 配置映射中的 time 值来修改这些数据的保留时间。

先决条件

  • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  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 下:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          retention: <time_specification> 
    1
    1
    以以下格式指定保留时间:数字直接后跟 ms (毫秒)、s (秒)、m (分钟)、h (小时)、d (天)、w (周)或 y (年)。您还可以组合指定时间值,如 1h30m15s。默认值为 24h

    以下示例将 Thanos Ruler 数据的保留时间设置为 10 天:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          retention: 10d
  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

4.3.3. 为监控组件设置日志级别

您可以为 Alertmanager、Prometheus Operator、Prometheus 和 Thanos Ruler 配置日志级别。

以下日志级别可应用到 user-workload-monitoring-config ConfigMap 中的相关组件:

  • debug。记录调试、信息、警告和错误消息。
  • info。记录信息、警告和错误消息。
  • warn。仅记录警告和错误消息。
  • error。仅记录错误消息。

默认日志级别为 info

先决条件

  • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. data/config.yaml 下为组件添加 logLevel: <log_level>

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        <component>: 
    1
    
          logLevel: <log_level> 
    2
    1
    您要为其设置日志级别的监控堆栈组件。可用的组件值包括 prometheusalertmanagerprometheusOperatorthanosRuler
    2
    为组件设置的日志级别。可用值为 errorwarninfodebug。默认值为 info
  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
  4. 通过查看相关项目中的部署或 Pod 配置来确认已应用了日志级别。以下示例检查 prometheus-operator 部署的日志级别:

    $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml | grep "log-level"

    输出示例

            - --log-level=debug

  5. 检查组件的 Pod 是否正在运行。以下示例列出了 pod 的状态:

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

    如果 ConfigMap 中包含了一个未识别的 loglevel 值,则组件的 Pod 可能无法成功重启。

4.3.4. 为 Prometheus 启用查询日志文件

您可以将 Prometheus 配置为将引擎运行的所有查询写入到日志文件。

重要

由于不支持日志轮转,因此仅在需要对问题进行故障排除时才临时启用此功能。完成故障排除后,通过恢复您对 ConfigMap 对象所做的更改来禁用查询日志记录,以启用该功能。

先决条件

  • 您可以使用具有 cluster-admin 集群角色或具有 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. 将 Prometheus 的 queryLogFile 参数添加到 data/config.yaml 下:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          queryLogFile: <path> 
    1
    1
    添加要记录查询的文件的完整路径。
  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
  4. 验证组件的 pod 是否正在运行。以下示例命令列出了 pod 的状态:

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

    输出示例

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

  5. 读取查询日志:

    $ oc -n openshift-user-workload-monitoring exec prometheus-user-workload-0 -- cat <path>
    重要

    在检查了记录的查询信息后,恢复配置映射的设置。

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2026 Red Hat
返回顶部