Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

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

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

3.3.1. 配置持久性存储
复制链接

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

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

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

注意

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

3.3.1.1. 持久性存储的先决条件
复制链接

  • 使用块存储类型。

3.3.1.2. 配置持久性卷声明
复制链接

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

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • user-workload-monitoring-config ConfigMap 对象存在。在集群创建时默认创建此对象。
  • 已安装 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 对象会被重新创建，从而导致临时服务中断。

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

注意

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

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • user-workload-monitoring-config ConfigMap 对象存在。在集群创建时默认创建此对象。
  • 已安装 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 会自动重新部署。

3.3.2.1. 修改 Thanos Ruler 指标数据的保留时间
复制链接

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

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • user-workload-monitoring-config ConfigMap 对象存在。在集群创建时默认创建此对象。
  • 已安装 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 会自动重新部署。

3.3.3. 为监控组件设置日志级别
复制链接

您可以为 Alertmanager、Prometheus Operator、Prometheus 和 Thanos Ruler 配置日志级别。您可以使用这些设置进行故障排除，并更好地了解组件如何正常运行。

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

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

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • user-workload-monitoring-config ConfigMap 对象存在。在集群创建时默认创建此对象。
  • 已安装 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: |
    <component>:
    1 
    
      logLevel: <log_level>
    2 
    
    # ...
    1
    指定您要为其设置日志级别的监控堆栈组件。可用的组件值包括 prometheus、alertmanager、prometheusOperator 和 thanosRuler。
    2
    指定组件的日志级别。可用值为 error、warn、info 和 debug。默认值为 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 是否正在运行： 

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

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

3.3.4. 为 Prometheus 启用查询日志文件
复制链接

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

重要

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

先决条件

  • 您可以使用具有 dedicated-admin 角色的用户访问集群。
  • user-workload-monitoring-config ConfigMap 对象存在。在集群创建时默认创建此对象。
  • 已安装 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返回顶部