关于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]，感兴趣的同学能够本人入手进行整个比照测试试验，以下局部别离形容了不同采集模式的具体配置，如果只关怀采集比照后果，能够间接跳过此局部持续浏览。

1 环境

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

2 数据源

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

apiVersion: batch/v1kind: Jobmetadata:  name: nginx-log-demo-0  namespace: defaultspec:  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

3 Filebeat 规范输入流采集配置

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

4 Filebeat 容器文件采集配置

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

5 iLogtail 规范输入流采集配置

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"                }            }        }    ]}

6 iLogtail 容器文件采集配置

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比照测试

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

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

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

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

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

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

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

输出数据源: 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 整体内存相差不大，没有呈现随采集流量回升内存暴涨状况：

3 采集配置收缩性能比照

采集配置收缩性能比照，输出源设置为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者的收缩大小都处于可承受范畴。

4 iLogtail 采集性能测试

因为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机制的存在，随着速率的回升，规范输入流采集耗费的内存会逐步超过容器内文件采集耗费的内存。

5 比照总结

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

通过上述试验能够看到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 DaemonSet 场景优化

通过以上比照，能够看到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 使用指南

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

一 前言

二 测试试验形容

三 试验环境