支持控制台（Console）开发人员开始试用联系人

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: {}
# ...

    1
    要用于日志记录的日志收集器类型。这可以是 vector 或 fluentd。

  2. 运行以下命令来应用 ClusterLogging CR： 

    $ oc apply -f <filename>.yaml

11.5.2. 创建 LogFileMetricExporter 资源

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

如果没有创建 LogFileMetricExporter CR，您可能会在 OpenShift Container Platform Web 控制台仪表板中看到 Produced Logs 的 No 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
# ...

    1
    可选： nodeSelector 小节定义 pod 调度到哪些节点上。
    2
    resources 小节定义了 LogFileMetricExporter CR 的资源要求。
    3
    可选：tolerations 小节定义 pod 接受的容限。

  2. 运行以下命令来应用 LogFileMetricExporter CR： 

    $ oc apply -f <filename>.yaml

验证

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

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

    $ oc get pods -l app.kubernetes.io/component=logfilesmetricexporter -n openshift-logging

    输出示例

    NAME                           READY   STATUS    RESTARTS   AGE
logfilesmetricexporter-9qbjj   1/1     Running   0          2m46s
logfilesmetricexporter-cbc4v   1/1     Running   0          2m46s

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

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

流程

  • 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）： 

    $ oc -n openshift-logging edit ClusterLogging instance
    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
# ...
    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。

11.5.4.1. 配置收集器以接收审计日志作为 HTTP 服务器

您可以通过在 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
# ...

    1
    为您的输入接收器指定一个名称。
    2
    将输入接收器类型指定为 http。
    3
    目前，http 输入接收器只支持 kube-apiserver Webhook 格式。
    4
    可选：指定输入接收器侦听的端口。这必须是 1024 到 65535 之间的值。如果没有指定，则默认值为 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
# ...

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

  2. 运行以下命令，将更改应用到 ClusterLogForwarder CR： 

    $ oc apply -f <filename>.yaml

其他资源

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 配置和性能有详细了解的高级用户。
  • 仅用于性能调整。它们对日志的功能性没有影响。
表 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

  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
# ...
    1
    请指定每个块在排队进行清除前的最大大小。
    2
    指定块清除之间间隔。
    3
    指定执行块清除的方法： lazy、interval 或 immediate。
    4
    指定用于块清除的线程数量。
    5
    指定当队列满时的块行为：throw_exception、block 或 drop_oldest_chunk。
    6
    指定使用 exponential_backoff 块清理方法时的最大间隔时间（以秒为单位）。
    7
    指定当块清除失败时重试的类型： exponential_backoff 或 periodic。
    8
    指定下一次块清除前的时间（以秒为单位）。
    9
    指定块缓冲区的最大大小。

  3. 验证 Fluentd Pod 是否已重新部署： 

    $ oc get pods -l component=collector -n openshift-logging

  4. 检查 fluentd 配置映射中的新值： 

    $ oc extract configmap/collector-config --confirm

    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>

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.