4.2. 配置日志记录收集器

OpenShift Container Platform 使用 Fluentd 从集群中收集操作和应用程序日志，并使用 Kubernetes pod 和项目元数据丰富这些日志。

您可以为日志收集器配置 CPU 和内存限值，并将日志收集器 Pod 移到特定的节点。所有支持的对日志收集器的修改，均可通过 ClusterLogging 自定义资源（CR）中的 spec.collection.log.fluentd 小节来执行。

4.2.1. 不支持的配置

配置 OpenShift Logging 的支持方法是使用本文档中介绍的选项进行配置。请勿使用其他配置，因为不受支持。各个 OpenShift Container Platform 发行版本的配置范例可能会有所变化，只有掌握了所有可能的配置，才能稳妥应对这样的配置变化。如果使用本文档中描述的配置以外的配置，您的更改可能会丢失，因为 OpenShift Elasticsearch Operator 和 Red Hat OpenShift Logging Operator 会调节差异。按照设计，Operator 会默认将一切还原到定义的状态。

注意

如果必须执行 OpenShift Container Platform 文档中没有描述的配置，您必须将 Red Hat OpenShift Logging Operator 或 OpenShift Elasticsearch Operator 设置为 Unmanaged。一个不受管理的 OpenShift Logging 环境 不被支持，且不会接收更新，直到 OpenShift Logging 返回到 Managed。

4.2.2. 查看日志记录收集器 Pod

您可以查看 Fluentd 日志记录收集器 Pod 以及它们正在运行的对应节点。Fluentd 日志记录收集器 Pod 仅在 openshift-logging 项目中运行。

流程

在 openshift-logging 项目中运行以下命令来查看 Fluentd 日志记录收集器 Pod 及其详情：

$ oc get pods --selector component=fluentd -o wide -n openshift-logging

输出示例

NAME           READY  STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
fluentd-8d69v  1/1    Running   0          134m    10.130.2.30   master1.example.com   <none>           <none>
fluentd-bd225  1/1    Running   0          134m    10.131.1.11   master2.example.com   <none>           <none>
fluentd-cvrzs  1/1    Running   0          134m    10.130.0.21   master3.example.com   <none>           <none>
fluentd-gpqg2  1/1    Running   0          134m    10.128.2.27   worker1.example.com   <none>           <none>
fluentd-l9j7j  1/1    Running   0          134m    10.129.2.31   worker2.example.com   <none>           <none>

4.2.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:
    logs:
      fluentd:
        resources:
          limits: 1
            memory: 736Mi
          requests:
            cpu: 100m
            memory: 736Mi

1: 根据需要指定 CPU 和内存限值及请求。显示的值是默认值。

4.2.4. 日志转发器的高级配置

OpenShift Logging 包含多个 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 会无限期重试块清除。在 OpenShift Container Platform 中，您无法更改无限期重试行为。

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

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

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

注意

这些参数：

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

表 4.1. 高级 Fluentd 配置参数
参数	描述	默认
`chunkLimitSize`	每个块的最大值。当数据达到这个大小时，Fluentd 会停止将数据写入一个块。然后，Fluentd 将块发送到队列并打开一个新的块。	`8m`
`totalLimitSize`	缓冲区的最大大小，即阶段（stage）和队列（stage）的总大小。如果缓冲区的大小超过这个值，Fluentd 会停止将数据添加到块，并显示错误失败。所有不在块中的数据都丢失。	`8G`
`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`
`retryWait`	下一次块清除前的时间（以秒为单位）。	`1s`

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

流程

编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）：
```
$ oc edit ClusterLogging instance
```
添加或修改以下任何参数：
```
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  forwarder:
    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
指定块缓冲区的最大大小。
验证 Fluentd Pod 是否已重新部署：
```
$ oc get pods -n openshift-logging
```

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

$ oc extract configmap/fluentd --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 32m
 chunk_limit_size 8m
 overflow_action throw_exception
</buffer>

4.2.5. 如果不使用默认的 Elasticsearch 日志存储，请删除未使用的组件

作为管理员，在非常罕见的情况下，当您将日志转发到第三方日志存储且不使用默认的 Elasticsearch 存储时，您可以从日志集群中移除几个未使用的组件。

换句话说，如果没有使用默认的 Elasticsearch 日志存储，您可以从 ClusterLogging 自定义资源 (CR) 中删除内部 Elasticsearch logStore 和 Kibana visualization 组件。删除这些组件是可选的，但会保存资源。

先决条件

验证您的日志转发程序没有将日志数据发送到默认的内部 Elasticsearch 集群。检查您用来配置日志转发的 ClusterLogForwarder CR YAML 文件。验证它没有指定 default 的 outputRefs 元素。例如：
```
outputRefs:
- default
```

警告

假定 ClusterLogForwarder CR 将日志数据转发到内部 Elasticsearch 集群，并从 ClusterLogging CR 中删除 logStore 组件。在这种情况下，内部 Elasticsearch 集群将不存在来存储日志数据。这会导致数据丢失。

流程

编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）：
```
$ oc edit ClusterLogging instance
```
如果存在，请从 ClusterLogging CR 中删除 logStore 和 visualization 小节。

保留 ClusterLogging CR 的 collection 小节。结果应类似以下示例：

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  collection:
    logs:
      type: "fluentd"
      fluentd: {}

验证 Fluentd Pod 是否已重新部署：
```
$ oc get pods -n openshift-logging
```

其他资源

将日志转发到第三方系统

4.2. 配置日志记录收集器

4.2.1. 不支持的配置

4.2.2. 查看日志记录收集器 Pod

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

4.2.4. 日志转发器的高级配置

4.2.5. 如果不使用默认的 Elasticsearch 日志存储，请删除未使用的组件

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links