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。

流程

  1. 修改 ClusterLogging CR collection 规格:

    ClusterLogging CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      collection:
        type: <log_collector_type> 1
        resources: {}
        tolerations: {}
    # ...

    1
    要用于日志记录的日志收集器类型。这可以是 vectorfluentd
  2. 运行以下命令来应用 ClusterLogging CR:

    $ oc apply -f <filename>.yaml

9.5.2. 创建 LogFileMetricExporter 资源

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

如果没有创建 LogFileMetricExporter CR,您可能会在 OpenShift Container Platform Web 控制台仪表板中看到 Produced LogsNo datapoints found 信息。

先决条件

  • 有管理员权限。
  • 已安装 Red Hat OpenShift Logging Operator。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 创建一个 LogFileMetricExporter CR 作为 YAML 文件:

    Example 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

9.5.3. 配置日志记录收集器的资源和调度

管理员可以通过创建位于同一命名空间中的 ClusterLogging 自定义资源(CR)来修改收集器的资源或调度,其名称与它支持的 ClusterLogForwarder CR 的名称相同。

在部署中使用多个日志转发器时,ClusterClusterLogging CR 的适用小节是 managementStatecollection。所有其他小节将被忽略。

先决条件

  • 有管理员权限。
  • 已安装 Red Hat OpenShift Logging Operator 版本 5.8 或更新版本。
  • 您已创建了 ClusterLogForwarder CR。

流程

  1. 创建支持现有 ClusterLogForwarder CR 的 ClusterLogging CR:

    ClusterLogging CR YAML 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name:  <name> 1
      namespace: <namespace> 2
    spec:
      managementState: "Managed"
      collection:
        type: "vector"
        tolerations:
        - key: "logging"
          operator: "Exists"
          effect: "NoExecute"
          tolerationSeconds: 6000
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 100m
            memory: 1Gi
        nodeSelector:
          collector: needed
    # ...

    1
    名称必须与 ClusterLogForwarder CR 的名称相同。
    2
    命名空间必须与 ClusterLogForwarder CR 相同。
  2. 运行以下命令来应用 ClusterLogging CR:

    $ oc apply -f <filename>.yaml

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

您可以查看日志记录收集器 Pod 及其运行的对应节点。

流程

  • 在项目中运行以下命令查看日志记录收集器 Pod 及其详情:

    $ oc get pods --selector component=collector -o wide -n <project_name>

    输出示例

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

9.5.5. 配置日志收集器 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.6. 配置收集器以接收审计日志作为 HTTP 服务器

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

先决条件

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

流程

  1. 修改 ClusterLogForwarder CR,以添加 http 接收器输入的配置:

    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
    可选:指定输入接收器侦听的端口。这必须是 102465535 之间的值。如果没有指定,则默认值为 8443
    5
    为您的输入接收器配置管道。
  2. 将更改应用到 ClusterLogForwarder CR:

    $ oc apply -f <filename>.yaml

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

表 9.10. 高级 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
    指定执行块清除的方法: lazyintervalimmediate
    4
    指定用于块清除的线程数量。
    5
    指定当队列满时的块行为:throw_exceptionblockdrop_oldest_chunk
    6
    指定使用 exponential_backoff 块清理方法时的最大间隔时间(以秒为单位)。
    7
    指定当块清除失败时重试的类型: exponential_backoffperiodic
    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>