11.5. 配置日志记录收集器


Red Hat OpenShift 的 logging 从集群中收集操作和应用程序日志,并使用 Kubernetes pod 和项目元数据丰富数据。所有支持的对日志收集器的修改,均可通过 ClusterLogging 自定义资源(CR)中的 spec.collection 小节来执行。

11.5.1. 配置日志收集器

您可以通过修改 ClusterLogging 自定义资源(CR)来配置日志使用哪个日志收集器类型。

注意

Fluentd 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。作为 Fluentd 的替代选择,您可以使用 Vector。

先决条件

  • 有管理员权限。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 Red Hat OpenShift Logging Operator。
  • 您已创建了 ClusterLogging CR。

步骤

  1. 修改 ClusterLogging CR collection 规格:

    ClusterLogging CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      collection:
        type: <log_collector_type> 
    1
    
        resources: {}
        tolerations: {}
    # ...
    Copy to Clipboard Toggle word wrap

    1
    要用于日志记录的日志收集器类型。这可以是 vectorfluentd
  2. 运行以下命令来应用 ClusterLogging CR:

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

11.5.2. 创建 LogFileMetricExporter 资源

在日志记录版本 5.8 及更新版本中,LogFileMetricExporter 不再默认使用收集器部署。您需要手动创建一个 LogFileMetricExporter 自定义资源 (CR),从运行容器生成的日志中生成指标。

如果没有创建 LogFileMetricExporter CR,您可能会在 OpenShift Container Platform Web 控制台仪表板中看到 Produced LogsNo datapoints found 信息。

先决条件

  • 有管理员权限。
  • 已安装 Red Hat OpenShift Logging Operator。
  • 已安装 OpenShift CLI(oc)。

步骤

  1. 创建一个 LogFileMetricExporter CR 作为 YAML 文件:

    LogFileMetricExporter CR 示例

    apiVersion: logging.openshift.io/v1alpha1
    kind: LogFileMetricExporter
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      nodeSelector: {} 
    1
    
      resources: 
    2
    
        limits:
          cpu: 500m
          memory: 256Mi
        requests:
          cpu: 200m
          memory: 128Mi
      tolerations: [] 
    3
    
    # ...
    Copy to Clipboard Toggle word wrap

    1
    可选: nodeSelector 小节定义 pod 调度到哪些节点上。
    2
    resources 小节定义了 LogFileMetricExporter CR 的资源要求。
    3
    可选:tolerations 小节定义 pod 接受的容限。
  2. 运行以下命令来应用 LogFileMetricExporter CR:

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

验证

logfilesmetricexporter pod 在每个节点上同时运行 collector pod。

  • 运行以下命令,验证 logfilesmetricexporter pod 是否在您创建 LogFileMetricExporter CR 的命名空间中运行:

    $ oc get pods -l app.kubernetes.io/component=logfilesmetricexporter -n openshift-logging
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                           READY   STATUS    RESTARTS   AGE
    logfilesmetricexporter-9qbjj   1/1     Running   0          2m46s
    logfilesmetricexporter-cbc4v   1/1     Running   0          2m46s
    Copy to Clipboard Toggle word wrap

11.5.3. 配置日志收集器 CPU 和内存限值

日志收集器允许对 CPU 和内存限值进行调整。

流程

  • 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源(CR):

    $ oc -n openshift-logging edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap
    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      collection:
        type: fluentd
        resources:
          limits: 
    1
    
            memory: 736Mi
          requests:
            cpu: 100m
            memory: 736Mi
    # ...
    Copy to Clipboard Toggle word wrap
    1
    根据需要指定 CPU 和内存限值及请求。显示的值是默认值。

11.5.4. 配置输入接收器

Red Hat OpenShift Logging Operator 为每个配置的输入接收器部署服务,以便客户端可以写入收集器。此服务公开为输入接收器指定的端口。服务名称基于以下内容生成:

  • 对于多日志转发器 ClusterLogForwarder CR 部署,服务名称格式为 <ClusterLogForwarder_CR_name>-<input_name>。例如,example-http-receiver
  • 对于旧的 ClusterLogForwarder CR 部署,这意味着名为 instance 且位于 openshift-logging 命名空间中,服务名称采用 collector-<input_name> 格式。例如,collector-http-receiver

您可以通过在 ClusterLogForwarder 自定义资源(CR)中将 http 指定为接收器输入,将日志收集器配置为侦听 HTTP 连接,并将审计日志作为 HTTP 服务器接收。这可让您对从 OpenShift Container Platform 集群内部和外部收集的审计日志使用通用日志存储。

先决条件

  • 有管理员权限。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 Red Hat OpenShift Logging Operator。
  • 您已创建了 ClusterLogForwarder CR。

步骤

  1. 修改 ClusterLogForwarder CR,以添加 http 接收器输入的配置:

    使用多日志转发器部署的 ClusterLogForwarder CR 示例

    apiVersion: logging.openshift.io/v1beta1
    kind: ClusterLogForwarder
    metadata:
    # ...
    spec:
      serviceAccountName: <service_account_name>
      inputs:
        - name: http-receiver 
    1
    
          receiver:
            type: http 
    2
    
            http:
              format: kubeAPIAudit 
    3
    
              port: 8443 
    4
    
      pipelines: 
    5
    
        - name: http-pipeline
          inputRefs:
            - http-receiver
    # ...
    Copy to Clipboard Toggle word wrap

    1
    为您的输入接收器指定一个名称。
    2
    将输入接收器类型指定为 http
    3
    目前,http 输入接收器只支持 kube-apiserver Webhook 格式。
    4
    可选:指定输入接收器侦听的端口。这必须是 102465535 之间的值。如果没有指定,则默认值为 8443
    5
    为您的输入接收器配置管道。

    使用旧部署的 ClusterLogForwarder CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      inputs:
        - name: http-receiver 
    1
    
          receiver:
            type: http 
    2
    
            http:
              format: kubeAPIAudit 
    3
    
              port: 8443 
    4
    
      pipelines: 
    5
    
      - inputRefs:
        - http-receiver
        name: http-pipeline
    # ...
    Copy to Clipboard Toggle word wrap

    1
    为您的输入接收器指定一个名称。
    2
    将输入接收器类型指定为 http
    3
    目前,http 输入接收器只支持 kube-apiserver Webhook 格式。
    4
    可选:指定输入接收器侦听的端口。这必须是 102465535 之间的值。如果没有指定,则默认值为 8443
    5
    为您的输入接收器配置管道。
  2. 运行以下命令,将更改应用到 ClusterLogForwarder CR:

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

11.5.5. Fluentd 日志转发器的高级配置

注意

Fluentd 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。作为 Fluentd 的替代选择,您可以使用 Vector。

日志记录包括多个 Fluentd 参数,可用于调整 Fluentd 日志转发器的性能。通过这些参数,可以更改以下 Fluentd 行为:

  • 块和块缓冲大小
  • 块清除行为
  • 块转发重试行为

Fluentd 在名为 chunk(块) 的单个 blob 中收集日志数据 。当 Fluentd 创建一个块时,块被视为处于 stage,在这个阶段,数据会被填充到块中。当块已满时,Fluentd 会将块移到 queue,在块被清除或将其写入其目的地前,数据会被保存在这里。有一些原因会导致 Fluentd 清除块,如网络问题或目的地的容量问题。如果无法清除块,Fluentd 会按照配置重试清除操作( flushing)。

在 OpenShift Container Platform 中,Fluentd 会使用 exponential backoff 方法来重试清理(flushing)操作,Fluentd 会加倍尝试重试清理操作之间的等待时间,这有助于减少到目的地的连接请求。您可以禁用 exponential backoff 的方法,并使用 定期重试的方法。它可在指定的时间间隔里重试 flush 块。

这些参数可帮助您权衡延迟和吞吐量之间的利弊。

  • 要优化 Fluentd 的吞吐量,您可以使用这些参数通过配置较大的缓冲和队列、延迟清除以及设置重试间隔间的更多时间来减少网络数据包的数量。请注意,大型缓冲区需要在节点文件系统有更多空间。
  • 要优化低延迟,您可以使用参数尽快发送数据,避免批量的构建,具有较短的队列和缓冲,并使用更频繁的清理和重试。

您可以使用 ClusterLogging 自定义资源(CR)中的以下参数配置 chunking 和 flushing 行为。然后这些参数会自动添加到 Fluentd 配置映射中,供 Fluentd 使用。

注意

这些参数:

  • 与大多数用户无关。默认设置应该就可以提供良好的一般性能。
  • 只适用于对 Fluentd 配置和性能有详细了解的高级用户。
  • 仅用于性能调整。它们对日志的功能性没有影响。
Expand
表 11.11. 高级 Fluentd 配置参数
参数描述默认

chunkLimitSize

每个块的最大值。当数据达到这个大小时,Fluentd 会停止将数据写入一个块。然后,Fluentd 将块发送到队列并打开一个新的块。

8m

totalLimitSize

缓冲区的最大大小,即阶段(stage)和队列(stage)的总大小。如果缓冲区的大小超过这个值,Fluentd 会停止将数据添加到块,并显示错误失败。所有不在块中的数据都丢失。

大约 15% 的节点磁盘分布在所有输出中。

flushInterval

块清除之间的间隔。您可以使用 s(秒)、m(分钟)、h(小时)或 d (天)。

1s

flushMode

执行清除的方法:

  • lazy:基于 timekey 参数对块进行清理。您无法修改 timekey 参数。
  • interval:基于 flushInterval 参数清理块。
  • Immediate: 在将数据添加到一个块后马上清理块。

interval

flushThreadCount

执行块清除(flushing)的线程数量。增加线程数量可提高冲刷吞吐量,这会隐藏网络延迟的情况。

2

overflowAction

当队列满时块的行为:

  • throw_exception:发出一个异常并在日志中显示。
  • block:停止对数据进行块除了,直到缓冲区已用完的问题被解决为止。
  • drop_oldest_chunk:删除旧的块以接受新传入的块。旧块的价值比新块要小。

block

retryMaxInterval

exponential_backoff 重试方法的最大时间(以秒为单位)。

300s

retryType

flushing 失败时重试的方法:

  • exponential_backoff:增加每次重新清理操作的间隔时间。Fluentd 会加倍到下一次重试需要等待的时间,直到达到 retry_max_interval 参数指定的值。
  • periodic:基于 retryWait 参数,定期重试清理操作。

exponential_backoff

retryTimeOut

在放弃记录前尝试重试的最长时间。

60m

retryWait

下一次块清除前的时间(以秒为单位)。

1s

如需有关 Fluentd 块生命周期的更多信息,请参阅 Fluentd 文档 中的缓冲插件。

流程

  1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源(CR):

    $ oc edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap
  2. 添加或修改以下任何参数:

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      collection:
        fluentd:
          buffer:
            chunkLimitSize: 8m 
    1
    
            flushInterval: 5s 
    2
    
            flushMode: interval 
    3
    
            flushThreadCount: 3 
    4
    
            overflowAction: throw_exception 
    5
    
            retryMaxInterval: "300s" 
    6
    
            retryType: periodic 
    7
    
            retryWait: 1s 
    8
    
            totalLimitSize: 32m 
    9
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    请指定每个块在排队进行清除前的最大大小。
    2
    指定块清除之间间隔。
    3
    指定执行块清除的方法: lazyintervalimmediate
    4
    指定用于块清除的线程数量。
    5
    指定当队列满时的块行为:throw_exceptionblockdrop_oldest_chunk
    6
    指定使用 exponential_backoff 块清理方法时的最大间隔时间(以秒为单位)。
    7
    指定当块清除失败时重试的类型: exponential_backoffperiodic
    8
    指定下一次块清除前的时间(以秒为单位)。
    9
    指定块缓冲区的最大大小。
  3. 验证 Fluentd Pod 是否已重新部署:

    $ oc get pods -l component=collector -n openshift-logging
    Copy to Clipboard Toggle word wrap
  4. 检查 fluentd 配置映射中的新值:

    $ oc extract configmap/collector-config --confirm
    Copy to Clipboard Toggle word wrap

    fluentd.conf 示例

    <buffer>
      @type file
      path '/var/lib/fluentd/default'
      flush_mode interval
      flush_interval 5s
      flush_thread_count 3
      retry_type periodic
      retry_wait 1s
      retry_max_interval 300s
      retry_timeout 60m
      queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '32'}"
      total_limit_size "#{ENV['TOTAL_LIMIT_SIZE_PER_BUFFER'] || '8589934592'}"
      chunk_limit_size 8m
      overflow_action throw_exception
      disable_chunk_backup true
    </buffer>
    Copy to Clipboard Toggle word wrap

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat