关于kubernetes:iLogtail-与Filebeat-性能对比

简介：前段时间, iLogtail 阿里千万实例可观测采集器开源，其中介绍了 iLogtail 采集性能能够达到单核 100MB/s，相比开源采集 Agent 有 5 -10 倍性能劣势。很多小伙伴好奇 iLogtail 具体的性能数据和资源耗费如何，本文将针对目前业界应用度较高且性能绝对较优的 Agent FileBeat 进行比照，测试这两个 Agent 在不同压力场景下的体现如何。

作者 | 少旋
起源 | 阿里技术公众号

前段时间, iLogtail [1]阿里千万实例可观测采集器开源，其中介绍了 iLogtail 采集性能能够达到单核 100MB/s，相比开源采集 Agent 有 5 -10 倍性能劣势。很多小伙伴好奇 iLogtail 具体的性能数据和资源耗费如何，本文将针对目前业界应用度较高且性能绝对较优的 Agent FileBeat 进行比照，测试这两个 Agent 在不同压力场景下的体现如何。

随着 Kubernetes 遍及，Kubernetes 下的日志收集的需要也日益常态化，因而下文将别离进行容器规范输入流采集与容器内动态文件采集比照试验（应用动态文件采集的小伙伴能够参考容器内动态文件采集比照试验, iLogtail 纯动态文件采集会略优于试验 2 容器内文件动态采集），试验项具体如下：

试验 1：恒定采集配置 4，Filebeat & iLogtail 在原始日志产生速率 1M/s、2M/s、3M/s 下的规范输入流采集性能比照。
试验 2：恒定采集配置 4，Filebeat & iLogtail 在原始日志产生速率 1M/s、2M/s、3M/s 下的容器内文件采集性能比照。

而在实在的生产环境中，日志采集组件的可运维性也至关重要，为运维与前期降级便当，相比于 Sidecar 模式，K8s 下采纳 Daemonset 模式部署采集组件更加常见。但因为 Daemonset 同时将整个集群的采集配置下发到各个采集节点的个性，单个采集节点正在工作的配置必然小于全量采集配置数目，因而咱们还会进行以下 2 局部试验，验证采集配置的收缩是否会影响采集器的工作效率：

试验 3：恒定输出速率 3M/s，Filebeat & iLogtail 在采集配置 50、100、500、1000 份下的规范输入流采集性能比照。
试验 4：恒定输出速率 3M/s，Filebeat & iLogtail 在采集配置 50、100、500、1000 份下的容器内文件采集性能比照。

最初会进行 iLogtail 的大流量压测，具体如下：

试验 5：iLogtail 在 5M/s、10M/s、10M/s、40M/s 下的规范输入流采集性能。
试验 6：iLogtail 在 5M/s、10M/s、10M/s、40M/s 下的容器内文件采集性能。

所有采集环境数据存储于[2]，感兴趣的同学能够本人入手进行整个比照测试试验，以下局部别离形容了不同采集模式的具体配置，如果只关怀采集比照后果，能够间接跳过此局部持续浏览。

运行环境：阿里云 ACK Pro 版本
节点配置：ecs.g6.xlarge (4 vCPU 16GB) 磁盘 ESSD
底层容器：Containerd
iLogtail 版本：1.0.28
FileBeat 版本：v7.16.2

对于数据源，咱们首先去除因正则解析或多行拼接能力带来的差别，仅仅以最根本的单行采集进行比照，数据产生源模仿产生 nginx 拜访日志，单条日志大小为 283B，以下配置形容了 1000 条 /s 速率下的输出源：

apiVersion: batch/v1
kind: Job
metadata:
  name: nginx-log-demo-0
  namespace: default
spec:
  template:
    metadata:
      name: nginx-log-demo-0
    spec:
      restartPolicy: Never
      containers:
        - name: nginx-log-demo-0
          image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest
          command: ["/bin/mock_log"]
          args:  ["--log-type=nginx",  "--path=/var/log/medlinker/access.log", "--total-count=1000000000", "--log-file-size=1000000000", "--log-file-count=2", "--logs-per-sec=1000"]
          volumeMounts:
            - name: path
              mountPath: /var/log/medlinker
              subPath: nginx-log-demo-0
          resources:
            limits:
              memory: 200Mi
            requests:
              cpu: 10m
              memory: 10Mi
      volumes:
      - name: path
        hostPath:
          path: /testlog
          type: DirectoryOrCreate
      nodeSelector:
        kubernetes.io/hostname: cn-beijing.192.168.0.140

Filebeat 原生反对容器文件采集，通过 add_kubernetes_metadata 组件减少 kubernetes 元信息，为防止输入组件导致的性能差别，通过 drop_event 插件抛弃数据，防止输入，filebeat 测试配置如下（harvester_buffer_size 调整设置为 512K，filebeat.registry.flush: 30s，queue.mem 参数适当扩充，减少吞吐）：

filebeat.yml: |-
   filebeat.registry.flush: 30s
   processors:
     - add_kubernetes_metadata:
         host: ${NODE_NAME}
         matchers:
         - logs_path:
             logs_path: "/var/log/containers/"
     - drop_event:
         when:
           equals:
             input.type: container
   output.console:
     pretty: false
   queue:
     mem:
       events: 4096
       flush.min_events: 2048
       flush.timeout: 1s
   max_procs: 4
   filebeat.inputs:
   - type: container
     harvester_buffer_size: 524288
     paths:
       - /var/log/containers/nginx-log-demo-0-*.log

Filebeat 原生不反对容器内文件采集，因而须要人工将日志打印门路挂载于宿主机 HostPath，这里咱们应用 subPath 以及 DirectoryOrCreate 性能进行服务打印门路的拆散, 以下为模仿不同服务日志打印门路独立状况。

filebeat 应用根底日志读取性能读取 /testlog 门路下的日志，为防止输入组件导致的性能差别，通过 drop_event 插件抛弃数据，防止输入，测试配置如下（harvester_buffer_size 调整设置为 512K，filebeat.registry.flush: 30s，queue.mem 参数适当扩充，减少吞吐）：

  filebeat.yml: |-
    filebeat.registry.flush: 30s
    output.console:
      pretty: false
    queue:
      mem:
        events: 4096
        flush.min_events: 2048
        flush.timeout: 1s
    max_procs: 4

    filebeat.inputs:
    - type: log
      harvester_buffer_size: 524288
      paths:
        - /testlog/nginx-log-demo-0/*.log
      processors:
        - drop_event:
            when:
              equals:
                log.file.path: /testlog/nginx-log-demo-0/access.log

iLogtail 原生同样反对规范输入流采集，service_docker_stdout 组件曾经会提取 kubernetes 元信息，为防止输入组件导致的性能差别，通过 processor_filter_regex，进行所有日志的过滤，测试配置如下：

{
    "inputs":[
        {
            "detail":{"ExcludeLabel":{},
                "IncludeLabel":{"io.kubernetes.container.name":"nginx-log-demo-0"}
            },
            "type":"service_docker_stdout"
        }
    ],
    "processors":[
        {
            "type":"processor_filter_regex",
            "detail":{
                "Exclude":{"_namespace_":"default"}
            }
        }
    ]
}

iLogtail 原生反对容器内文件采集，但因为文件内采集元信息存在于 tag 标签，暂无过滤插件，为防止输入组件导致的性能差别，因而咱们应用空输入插件进行输入，测试配置如下：

{
    "metrics":{
        "c0":{
            "advanced":{
                "k8s":{
                    "IncludeLabel":{"io.kubernetes.container.name":"nginx-log-demo-0"}
                }
            },
           ......
            "plugin":{
                "processors":[
                    {"type":"processor_default"}
                ],
                "flushers":[
                    {
                        "type":"flusher_statistics",
                        "detail":{"RateIntervalMs":1000000}
                    }
                ]
            },
            "local_storage":true,
            "log_begin_reg":".*",
            "log_path":"/var/log/medlinker",
            ......
        }
    }
}

Filebeat 与 iLogtail 的比照项次要蕴含以下内容：规范输入流采集性能、容器内文件采集性能、规范输入流多用户配置性能、容器内文件多用户配置性能以及大流量采集性能。

输出数据源: 283B/s, 底层容器 contianerd，规范输入流收缩后为 328B，共 4 个输出源：

1M/s 输出日志 3700 条 /s,
2M/s 输出日志 7400 条 /s,
3M/s 输出日志条 11100 条 /s。

以下显示了规范输入流不同采集的性能比照，能够看到 iLogtail 相比于 Filebeat 有十倍级的性能劣势（CPU 的百分比为单核的百分比）：

以下显示了规范输入流不同采集的内存比照，能够看到 logtail 和 filebeat 整体内存相差不大，没有呈现随采集流量回升内存暴涨状况：

输出数据源: 283B/s, 共 4 个输出源：

1M/s 输出日志 3700 条 /s,
2M/s 输出日志 7400 条 /s,
3M/s 输出日志条 11100 条 /s。

以下显示了容器内文件不同采集的性能比照，Filebeat 容器内文件因为与 container 采集共用采集组件，并省略了 Kubernets meta 相干组件，所以相比于规范输入流采集有大性能晋升，iLogtail 的容器内文件采集采纳 Polling + inotify 机制，同样相比于容器规范输入流采集有性能晋升，但能够看到 iLogtail 相比于 Filebeat 有 5 倍级的性能劣势（CPU 的百分比为单核的百分比）：

以下显示了规范输入流不同采集的内存比照，能够看到 logtail 和 filebeat 整体内存相差不大，没有呈现随采集流量回升内存暴涨状况：

采集配置收缩性能比照，输出源设置为 4，总输出速率为 3M/s, 别离进行 50 采集配置，100 采集配置，500 采集配置，1000 采集配置比照。

规范输入流采集配置收缩比照

以下显示了规范输入流不同采集的性能比照，能够看到 Filebeat 因为容器采集与动态文件采集底层共用雷同动态文件采集逻辑，会在规范输入流采集门路 var/log/containers 下存在大量正则匹配的工作，能够看到尽管采集数据量没有减少因为采集配置的减少，CPU 耗费减少 10%+，而 iLogtail 针对容器采集模型全局共享容器门路发现机制，所以防止了正则逻辑带来的性能损耗（CPU 的百分比为单核的百分比）。

在内存收缩方面，能够看到不论是 Filebeat 还是 iLogtail 都存在因为采集配置减少导致的内存收缩，但 2 者的收缩大小都处于可承受范畴。

容器内文件采集配置收缩比照

以下显示了容器内文件采集不同采集器的性能比照，能够看到 Filebeat 动态文件采集因为防止规范输入流通用门路正则，相较于规范减少 CPU 耗费较少，而 iLogtail CPU 变动同样很小，且相比于规范输入流采集性能略好（CPU 的百分比为单核的百分比）。

在内存收缩方面，同样能够看到不论是 Filebeat 还是 iLogtail 都存在因为采集配置减少导致的内存收缩，但 2 者的收缩大小都处于可承受范畴。

因为 FileBeat 在日志量大的场景下呈现采集提早问题，所以以下场景仅针对 iLogtail 进行测试，别离在 5M/s、10M/s、20M/s 下针对 iLogtail 进行容器规范输入流采集与容器内文件采集的性能压测。

输出源数量：10
单条日志大小 283B
5M/s 对应日志速率 18526 条 /s，单输出源产生速率 1852 条 /s
10M/s 对应日志速率 37052 条 /s，单输出源产生速率 3705 条 /s
20M/s 对应日志速率 74104 条 /s，单输出源产生速率 7410 条 /s
40M/s 对应日志速率 148208 条 /s，单输出源产生速率 14820 条 /s

和上述试验相似能够看到 CPU 耗费方面容器文件采集略好于容器规范输入流采集性能（CPU 的百分比为单核的百分比），次要是因为容器文件采集底层 Polling + inotify 机制。

在内存方面，因为规范输入流采集次要依赖于 GO，而容器文件采集次要依赖于 C，能够因为 GC 机制的存在，随着速率的回升，规范输入流采集耗费的内存会逐步超过容器内文件采集耗费的内存。

通过上述试验能够看到 FIlebeat 在不同工作模式下有较大的 CPU 差别，通过 dump 容器规范输入流采集的 pprof 能够失去如下火焰图，能够看到 Filebeat 容器采集下的 add_kubernets_meta 插件是性能瓶颈，同时 FIlebeat 的 add_kubernets_meta 采纳与每个节点监听 api-server 模式，也存在 api-server 压力问题。

而 iLogtail 取 kubernetes meta 齐全是兼容 kubernetes CRI 协定，间接通过 kubernets sandbox 进行 meta 数据读取，保障了 iLogtail 的高性能采集效率。

通过以上比照，能够看到 iLogtail 相比于 Filebeat 具备了优良的内存以及 CPU 耗费，有小伙伴可能好奇 iLogtail 领有如此极致性能背地起因，下文次要解说 iLogtail Daemonset 场景下的优化，如何规范输入流相比于 FIlebeat 领有 10 倍性能。

首先对于规范输入流场景，相比于其余开源采集器，例如 Filebeat 或 Fluentd。个别都是通过监听 var/log/containers 或 /var/log/pods/ 实现容器规范输入流文件的采集，比方 /var/log/pods/ 的门路构造为：/var/log/pods/_<pod_name>_<pod_id>/<container_name>/，通过此门路复用物理机动态文件采集模式进行采集。

而对于 iLogtail，做到了容器化的全反对，iLogtail 通过发现机制，全局保护对 Node 节点容器的列表，并实时监听与保护此容器列表。当咱们领有容器列表后，咱们便具备了如下劣势：

采集门路不在依赖于动态配置门路，能够靠容器标签动静抉择采集源，从而简化用户接入老本。
能够依据容器元信息探测容器主动挂载节点的动静门路，所以 iLogtail 无需挂载即可采集容器内文件，而如 Filebeat 等采集器须要将容器内门路挂载于宿主机门路，再进行动态文件采集。
对于新接入采集配置复用历史容器列表，疾速接入采集，而对于空采集配置，因为容器发现全局共享机制的存在，也就防止了存在空轮训监听门路机制的状况，进而保障了在容器这样动态性极高的环境中，iLogtail 可运维性的老本达到可控态。

综上所述，在动态性极高的 Kubernetes 环境下，iLogtail 不会因为采纳 Daemonset 的部署模型带来的多配置问题，造成内存大幅度收缩，而且在动态文件采集方面，iLogtail 领有 5 倍左右的性能劣势，而对于规范输入流采集，因为 iLogtail 的采集机制，iLogtail 领有约 10 倍左右的性能劣势。然而相比于 Filebeat 或 Fluentd 等老牌开源产品，在文档建设与社区建设上还欠缺很多，欢送对 iLogtail 感兴趣的小伙伴一起参加进来，独特打造易用且高性能的 iLogtail 产品。

参考文献

Logtail 技术分享一
Logtail 技术分享二
Filebeat 配置
Filebeat 容器化部署
iLogtail 使用指南

原文链接
本文为阿里云原创内容，未经容许不得转载。

一前言

二测试试验形容

三试验环境

1 环境

2 数据源

3 Filebeat 规范输入流采集配置

4 Filebeat 容器文件采集配置

5 iLogtail 规范输入流采集配置

6 iLogtail 容器文件采集配置

四 Filebeat 与 iLogtail 比照测试

1 规范输入流采集性能比照

2 容器内文件采集性能比照

3 采集配置收缩性能比照

4 iLogtail 采集性能测试

5 比照总结

五为什么 Filebeat 容器规范输入与文件采集差别微小？

六 iLogtail DaemonSet 场景优化

七结语

一 前言

二 测试试验形容

三 试验环境