7.2. 配置日志记录收集器
Red Hat OpenShift 的 logging 子系统从集群中收集操作和应用程序日志,并使用 Kubernetes pod 和项目元数据丰富数据。
您可以为日志收集器配置 CPU 和内存限值,并将日志收集器 Pod 移到特定的节点。所有支持的对日志收集器的修改,均可通过 ClusterLogging
自定义资源(CR)中的 spec.collection.log.fluentd
小节来执行。
7.2.1. 不支持的配置
为 Red Hat OpenShift 配置日志记录子系统的支持方法是使用本文档中介绍的选项进行配置。请勿使用其他配置,因为不受支持。各个 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。
7.2.2. 查看日志记录收集器 Pod
您可以查看 Fluentd 日志记录收集器 Pod 以及它们正在运行的对应节点。Fluentd 日志记录收集器 Pod 仅在 openshift-logging
项目中运行。
流程
-
在
openshift-logging
项目中运行以下命令来查看 Fluentd 日志记录收集器 Pod 及其详情:
$ oc get pods --selector component=collector -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>
7.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 和内存限值及请求。显示的值是默认值。
7.2.4. 日志转发器的高级配置
Red Hat 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 的吞吐量,您可以使用这些参数通过配置较大的缓冲和队列、延迟清除以及设置重试间隔间的更多时间来减少网络数据包的数量。请注意,大型缓冲区需要在节点文件系统有更多空间。
- 要优化低延迟,您可以使用参数尽快发送数据,避免批量的构建,具有较短的队列和缓冲,并使用更频繁的清理和重试。
您可以使用 ClusterLogging
自定义资源(CR)中的以下参数配置 chunking 和 flushing 行为。然后这些参数会自动添加到 Fluentd 配置映射中,供 Fluentd 使用。
这些参数:
- 与大多数用户无关。默认设置应该就可以提供良好的一般性能。
- 只适用于对 Fluentd 配置和性能有详细了解的高级用户。
- 仅用于性能调整。它们对日志的功能性没有影响。
参数 | 描述 | 默认 |
---|---|---|
| 每个块的最大值。当数据达到这个大小时,Fluentd 会停止将数据写入一个块。然后,Fluentd 将块发送到队列并打开一个新的块。 |
|
| 缓冲区的最大大小,即阶段(stage)和队列(stage)的总大小。如果缓冲区的大小超过这个值,Fluentd 会停止将数据添加到块,并显示错误失败。所有不在块中的数据都丢失。 |
|
|
块清除之间的间隔。您可以使用 |
|
| 执行清除的方法:
|
|
| 执行块清除(flushing)的线程数量。增加线程数量可提高冲刷吞吐量,这会隐藏网络延迟的情况。 |
|
| 当队列满时块的行为:
|
|
|
|
|
| flushing 失败时重试的方法:
|
|
| 在放弃记录前尝试重试的最长时间。 |
|
| 下一次块清除前的时间(以秒为单位)。 |
|
如需有关 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 ...
验证 Fluentd Pod 是否已重新部署:
$ oc get pods -l component=collector -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>
7.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: {}
验证收集器 Pod 是否已重新部署:
$ oc get pods -l component=collector -n openshift-logging
其他资源