简介：前段时间，iLogtail阿里开源了千万级实例的observable收集器。据介绍，iLogtail的采集性能可以达到每核100MB/s，相比开源的采集Agent有5-10倍的性能优势。.很多朋友很好奇iLogtail的具体性能数据和资源消耗。本文将对比目前业界应用广泛、性能相对较好的AgentFileBeat，测试两款Agent在不同压力场景下的表现。作者|少轩源|阿里科技公众号前言前段时间iLogtail[1]阿里数万实例ObservableCollector开源，介绍iLogtail采集性能可以达到单核100MB/s，相比开源的采集Agent有5-10倍的性能优势。很多朋友很好奇iLogtail的具体性能数据和资源消耗。本文将对比目前业界应用广泛、性能相对较好的AgentFileBeat，测试两款Agent在不同压力场景下的表现。2、测试说明随着Kubernetes的普及，Kubernetes下的日志采集需求也越来越常态化。因此，下面将对容器内的容器标准输出流采集和静态文件采集进行对比测试（使用静态文件采集的请参考容器内部静态文件采集对比测试，纯静态文件采集iLogtail的使用会比测试2)中容器中的静态文件集合略好。2M/s和3M/s下标准输出码流采集性能对比。实验2：常量采集配置4，Filebeat&iLogtail在原始日志生成速率1M/s、2M/s、3M/s下进行容器内文件采集的性能对比。在真实的生产环境中，日志采集组件的可操作性也很重要，方便运维和后期升级。与Sidecar模式相比，在K8s下以Daemonset模式部署集合组件更为常见。但是由于Daemonset会将整个集群的采集配置同时分发到各个采集节点，所以单个采集节点的工作配置肯定小于全量采集配置的个数。因此，我们将进行以下两部分实验来验证采集配置的扩展是否会影响采集器的工作效率：实验三：恒定输入速率3M/s，采集配置50下的Filebeat&iLogtail，100、500、1000标准输出码流采集性能对比。实验四：恒定输入速率3M/s，Filebeat&iLogtail在50、100、500、1000份采集配置下容器文件采集性能对比。最后对iLogtail进行大流量压测，具体如下：实验5：iLogtail在5M/s、10M/s、10M/s、40M/s的标准输出流采集性能。实验六：iLogtail在5M/s、10M/s、10M/s、40M/s下的容器内文件采集性能。三个测试环境的所有收集的环境数据都存储在[2]中。有兴趣的同学可以自己进行整个对比测试实验。以下章节将介绍不同采集模式的具体配置。如果只关心采集和对比结果，可以直接跳过本节。部分继续阅读。1环境运行环境：阿里云ACKPro版节点配置：ecs.g6.xlarge(4vCPU16GB)DiskESSD底层容器：ContainerdiLogtail版本：1.0.28FileBeat版本：v7.16.22数据源对于数据源，我们先去掉regularity解析或多行拼接能力造成的差异只是与最基本的单行集合相比。数据生成源模拟nginx访问日志。单个日志的大小为283B。以下配置以1000条记录/s的速率描述输入源：apiVersion:batch/v1kind:Jobmetadata:name:nginx-log-demo-0namespace:defaultspec:template:metadata:name:nginx-log-demo-0spec:restartPolicy:Never容器:-name:nginx-log-demo-0image:registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latestcommand:["/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:pathmountPath:/var/log/medlinkersubPath:nginx-log-demo-0资源：限制：内存：200Mi请求：cpu:10mmemory:10Mivolumes:-name:pathhostPath:path:/testlogtype:DirectoryOrCreatenodeSelector:kubernetes.io/hostname:cn-beijing.192.168.0.1403Filebeat标准输出流采集配置Filebeat原生支持容器文件采集，通过add_kubernetes_metadata组件添加kubernetes元信息。为了避免输出组件造成的性能差异，通过drop_event插件丢弃数据，避免输出。filebeat测试配置如下（harvester_buffer_size调整为512K，filebeat.registry.flush:30s，适当扩展queue.mem参数，增加吞吐量）：filebeat.yml:|-filebeat.registry.flush:30sprocessors：-add_kubernetes_metadata:host:${NODE_NAME}匹配器：-logs_path:logs_path:"/var/log/containers/"-drop_event:when:equals:input.type:containeroutput.console:pretty:falsequeue:mem:events：4096flush.min_events：2048flush.timeout：1smax_procs：4filebeat.inputs：-type：containerharvester_buffer_size：524288路径:-/var/log/containers/nginx-log-demo-0-*.log4Filebeat容器文件采集配置Filebeat本身不支持容器中的文件采集，所以需要在宿主机HostPath上手动挂载日志打印路径，这里我们使用subPath和DirectoryOrCreate函数来分离服务打印路径，下面是模拟不同服务日志打印路径独立的情况filebeat使用基本的日志读取功能读取/testlog路径下的日志。为了避免输出组件造成的性能差异，通过drop_event插件丢弃数据，避免输出。测试配置如下（harvester_buffer_size调整为512K，filebeat.registry.flush:30s，适当扩展queue.mem参数增加吞吐量）：filebeat.yml:|-filebeat.registry.flush:30soutput.console：漂亮：假队列：内存：事件：4096flush.min_events：2048flush.timeout：1smax_procs：4filebeat.inputs：-类型：logharvester_buffer_size：524288路径：-/testlog/nginx-log-demo-0/*.logprocessors:-drop_event:when:equals:log.file.path:/testlog/nginx-log-demo-0/access.log5iLogtail标准输出流收集配置iLogtail也原生支持标准输出流收集。service_docker_stdout组件已经提取了kubernetes元信息。为了避免输出组件造成的性能差异，处理所有日志通过processor_filter_regex过滤，测试配置如下：io.kubernetes.container.name":"nginx-log-demo-0"}},"type":"service_docker_stdout"}],"processors":[{"type":"processor_filter_regex","detail":{"Exclude":{"_namespace_":"default"}}]}6iLogtail容器文件采集配置iLogtail原生支持容器中的文件采集，但是由于文件中的采集元数据存在于tag中，所以暂时没有过滤插件。为避免输出组件带来的性能差异，我们使用emptyOutput插件进行输出，测试配置如下：name":"nginx-log-demo-0"}}},......"plugin":{"processors":[{"type":"processor_default"}],"flushers":[{"类型“：”flusher_statistics“，”细节il":{"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/sinputlog7400records/s,3M/sInputlogentries11100entries/s下面是不同采集标准输出流的性能对比，可以看出iLogtail有十倍的性能优势与Filebeat相比（CPU百分比为单核百分比。):下面是不同集合的标准输出流的内存对比。可以看出logtail和filebeat整体内存相差不大，并没有随着采集流量的增加而出现内存暴增：2容器内文件采集性能对比输入数据源：283B/s，共4个输入源：1M/s输入日志3700条/s，2M/s输入日志7400条/s，3M/s输入日志11100条/s。下面展示了容器中不同集合文件的性能对比。由于Filebeat容器中的文件与容器集合共享集合组件，省略了Kubernetesmeta相关组件，因此相比标准输出流集合有较大的性能提升。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都因为采集配置的增加而出现了内存扩展，但是两者的扩展大小都在可接受的范围内。下面展示了不同收集器在容器中收集文件的性能对比。可以看到Filebeat静态文件采集避开了标准输出流的通用路径规律性，相比标准增加消耗的CPU更少，而iLogtailCPU变化也很小，抓取性能相比标准输出流略好（CPU百分比为单核百分比）。在内存扩容方面，也可以看到Filebeat和iLogtail都因为采集配置的增加而出现了内存扩容，但是两者的扩容大小都在可接受的范围内。4iLogtail采集性能测试由于FileBeat在日志量大的场景下存在采集延迟问题，以下场景仅针对iLogtail进行测试，针对iLogtail采集容器标准输出流5M/s、10M/s、20M/s分别用容器中的文件收集进行性能压测。输入源个数：10单条日志大小283B5M/s对应日志速率18526条记录/s，单条输入源生成速率1852条记录/s10M/s对应日志速率37052条记录/s，单条输入sourcegenerationrateof3705records/s20M/s对应lograte为74104entries/s，单输入sourcegenerationrate为7410entries/s40M/s。对应的日志速率为148208条/s，单输入源生成速率为14820条/s。类似上面的测试，可以看出容器文件采集在CPU消耗方面略好于容器的标准输出流采集性能（CPU百分比为单核百分比），主要是由于容器文件集合底层的Polling+inotify机制。在内存方面，由于标准输出流的收集主要依赖GO，而容器文件的收集主要依赖C，由于GC机制的存在，随着速度的提高，标准输出流收集消耗的内存会逐渐超过容器中的文件集合。消耗的内存。5对比总结5为什么Filebeat容器的标准输出和文件集合有巨大的差异？通过以上实验可以看出，FIlebeat在不同的工作模式下，CPU差异较大。下面的火焰图可以通过pprof从dump容器的标准输出流中采集得到。可见Filebeat容器收集的add_kubernets_meta插件是性能瓶颈。add_kubernets_meta采用的是每个节点都监听api-server的方式，同样存在对api-server的压力问题。iLogtail获取的kubernetesmeta完全兼容kubernetesCRI协议，通过kubernets沙箱直接读取meta数据，保证了iLogtail高性能的采集效率。六、iLogtailDaemonSet场景优化通过上面的对比我们可以看出，iLogtail相比Filebeat在内存和CPU消耗方面有着出色的表现。有的朋友可能会疑惑，为什么iLogtail会有如此极致的性能。下面主要讲解如何优化iLogtailDaemonset场景。与Filebeat相比，标准输出流具有10倍的性能。首先，对于标准输出流场景，对比其他开源采集器，比如Filebeat或者Fluentd。一般通过监控var/log/containers或/var/log/pods/来实现容器标准输出流文件的收集。比如/var/log/pods/的路径结构是：/var/log/pods/_
