9.5. 配置日志记录收集器
Red Hat OpenShift 的 logging 从集群中收集操作和应用程序日志,并使用 Kubernetes pod 和项目元数据丰富数据。所有支持的对日志收集器的修改,均可通过 ClusterLogging
自定义资源(CR)中的 spec.collection
小节来执行。
9.5.1. 配置日志收集器
您可以通过修改 ClusterLogging
自定义资源(CR)来配置日志使用哪个日志收集器类型。
Fluentd 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。作为 Fluentd 的替代选择,您可以使用 Vector。
先决条件
- 有管理员权限。
-
已安装 OpenShift CLI(
oc
)。 - 已安装 Red Hat OpenShift Logging Operator。
-
您已创建了
ClusterLogging
CR。
流程
修改
ClusterLogging
CRcollection
规格:ClusterLogging
CR 示例apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... collection: type: <log_collector_type> 1 resources: {} tolerations: {} # ...
- 1
- 要用于日志记录的日志收集器类型。这可以是
vector
或fluentd
。
运行以下命令来应用
ClusterLogging
CR:$ oc apply -f <filename>.yaml
9.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
)。
流程
创建一个
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 # ...
运行以下命令来应用
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
9.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 和内存限值及请求。显示的值是默认值。
9.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
。
9.5.4.1. 配置收集器以接收审计日志作为 HTTP 服务器
您可以通过在 ClusterLogForwarder
自定义资源(CR)中将 http
指定为接收器输入,将日志收集器配置为侦听 HTTP 连接,并将审计日志作为 HTTP 服务器接收。这可让您对从 OpenShift Container Platform 集群内部和外部收集的审计日志使用通用日志存储。
先决条件
- 有管理员权限。
-
已安装 OpenShift CLI(
oc
)。 - 已安装 Red Hat OpenShift Logging Operator。
-
您已创建了
ClusterLogForwarder
CR。
流程
修改
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 # ...
使用旧部署的
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 # ...
运行以下命令,将更改应用到
ClusterLogForwarder
CR:$ oc apply -f <filename>.yaml
其他资源
9.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 配置和性能有详细了解的高级用户。
- 仅用于性能调整。它们对日志的功能性没有影响。
参数 | 描述 | 默认 |
---|---|---|
| 每个块的最大值。当数据达到这个大小时,Fluentd 会停止将数据写入一个块。然后,Fluentd 将块发送到队列并打开一个新的块。 |
|
| 缓冲区的最大大小,即阶段(stage)和队列(stage)的总大小。如果缓冲区的大小超过这个值,Fluentd 会停止将数据添加到块,并显示错误失败。所有不在块中的数据都丢失。 | 大约 15% 的节点磁盘分布在所有输出中。 |
|
块清除之间的间隔。您可以使用 |
|
| 执行清除的方法:
|
|
| 执行块清除(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: 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 # ...
验证 Fluentd Pod 是否已重新部署:
$ oc get pods -l component=collector -n openshift-logging
检查
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>