配置日志收集器

配置日志收集器
创建 LogFileMetricExporter 资源
配置日志收集器的 CPU 和内存限制
配置输入接收器
- 配置收集器以 HTTP 服务器的形式接收审计日志
Fluentd 日志转发器的高级配置

Red Hat OpenShift 的日志记录功能会从集群收集操作和应用程序日志，并使用 Kubernetes Pod 和项目元数据丰富数据。所有支持的对日志收集器的修改都可以通过ClusterLogging自定义资源 (CR) 中的spec.collection 部分来执行。

编辑

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

Fluentd 已弃用，计划在未来的版本中移除。Red Hat 在当前的发布生命周期中为该功能提供错误修复和支持，但此功能不再接收增强功能。作为 Fluentd 的替代方案，您可以使用 Vector。

先决条件

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

步骤

修改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`。

通过运行以下命令应用ClusterLogging CR
```
$ oc apply -f <filename>.yaml
```

编辑

创建 LogFileMetricExporter 资源

在日志版本 5.8 和更高版本中，LogFileMetricExporter 默认不再与收集器一起部署。您必须手动创建一个LogFileMetricExporter自定义资源 (CR) 以从运行容器生成的日志生成指标。

如果您不创建LogFileMetricExporter CR，您可能会在 AWS 网络控制台的 Red Hat OpenShift Service 仪表板中看到未找到数据点消息（针对已生成的日志）。

先决条件

您拥有管理员权限。
您已安装 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)
# ...

1	可选：`nodeSelector` 部分定义了 Pod 调度的节点。
2	`resources` 部分定义了`LogFileMetricExporter` CR 的资源需求。
3	可选：`tolerations` 部分定义了 Pod 接受的容忍度。

通过运行以下命令应用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

编辑

配置日志收集器的 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 和内存限制和请求。显示的值是默认值。

编辑

配置输入接收器

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。

编辑

配置收集器以 HTTP 服务器的形式接收审计日志

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

先决条件

您拥有管理员权限。
您已安装 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
# ...

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	为您的输入接收器配置管道。

通过运行以下命令应用对ClusterLogForwarder CR 的更改
```
$ oc apply -f <filename>.yaml
```

附加资源

API 审计筛选器的概述

编辑

Fluentd 日志转发器的高级配置

日志记录包含多个 Fluentd 参数，您可以使用这些参数来调整 Fluentd 日志转发器的性能。使用这些参数，您可以更改以下 Fluentd 行为

块和块缓冲区大小
块刷新行为
块转发重试行为

Fluentd 将日志数据收集到称为“块”的单个 blob 中。当 Fluentd 创建一个块时，该块被认为处于“阶段”，其中块被填充数据。当块已满时，Fluentd 将块移动到“队列”，在该队列中，块在刷新（或写入其目标）之前被保存。Fluentd 可能会由于多种原因而无法刷新块，例如网络问题或目标处的容量问题。如果无法刷新块，Fluentd 会根据配置重试刷新。

在 Red Hat OpenShift Service on AWS 中，Fluentd 默认使用指数退避方法来重试刷新，其中 Fluentd 会将等待时间加倍，以减少对目标的连接请求。

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

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

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

这些参数是：

与大多数用户无关。默认设置应提供良好的整体性能。
仅供具有 Fluentd 配置和性能详细知识的高级用户使用。
仅用于性能调整。它们对日志记录的功能方面没有影响。

表 1. Fluentd 高级配置参数
参数	描述	默认值
`chunkLimitSize`	每个数据块的最大大小。当Fluentd写入的数据达到此大小限制时，它会停止写入，将数据块发送到队列，然后打开一个新的数据块。	`8MB`
`totalLimitSize`	缓冲区的最大大小，即阶段和队列的总大小。如果缓冲区大小超过此值，Fluentd将停止向数据块添加数据，并报错。所有不在数据块中的数据将会丢失。	大约节点磁盘空间的15%，分布在所有输出端。
`flushInterval`	数据块刷新间隔。可以使用`s`（秒）、`m`（分钟）、`h`（小时）或`d`（天）作为单位。	`1秒`
`flushMode`	执行刷新的方法 `lazy`：基于`timekey`参数刷新数据块。您无法修改`timekey`参数。 `interval`：基于`flushInterval`参数刷新数据块。 `immediate`：在数据添加到数据块后立即刷新数据块。	`interval`
`flushThreadCount`	执行数据块刷新的线程数。增加线程数可以提高刷新吞吐量，从而隐藏网络延迟。	`2`
`overflowAction`	队列已满时的分块行为 `throw_exception`：抛出异常并在日志中显示。 `block`：停止数据分块，直到解决缓冲区满的问题。 `drop_oldest_chunk`：丢弃最旧的数据块以接受新的传入数据块。较旧的数据块比较新的数据块价值较低。	`block`
`retryMaxInterval`	`exponential_backoff`重试方法的最大时间（秒）。	`300秒`
`retryType`	刷新失败时的重试方法 `exponential_backoff`：增加刷新重试之间的时间间隔。Fluentd会将等待下一次重试的时间加倍，直到达到`retry_max_interval`参数的值。 `periodic`：基于`retryWait`参数定期重试刷新。	`exponential_backoff`
`retryTimeOut`	在丢弃记录之前尝试重试的最大时间间隔。	`60分钟`
`retryWait`	下一次数据块刷新之前的时间（秒）。	`1秒`

有关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)
# ...

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 -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>