采集器采集(前段时间,iLogtail阿里千万实例可观测采集器开源(组图))

　　采集器采集(前段时间,iLogtail阿里千万实例可观测采集器开源(组图))

　　介绍：前段时间可以观察到千万级iLogtail阿里巴巴实例采集器开源，其中介绍iLogtail采集性能可以达到每核100MB/s，对比开源< @采集代理5-10倍性能优势。很多朋友好奇iLogtail具体的性能数据和资源消耗情况。本文将对比目前业界广泛使用且性能相对较好的Agent FileBeat，测试两种agent在不同压力场景下的表现。

　　

　　作者 |减少旋转

　　来源 |阿里巴巴科技公众号

　　前言

　　前段时间，iLogtail[1]可以观察到阿里巴巴千万级实例采集器开源，其中引入iLogtail采集性能可以达到每核100MB/s，对比开源< @采集代理有5-10倍的性能优势。很多朋友好奇iLogtail具体的性能数据和资源消耗情况。本文将对比目前业界广泛使用且性能相对较好的Agent FileBeat，测试两种agent在不同压力场景下的表现。

　　第二次测试说明

　　随着Kubernetes的普及，Kubernetes下对日志采集的需求越来越正常，所以下面将容器标准输出流采集和静态文件采集@进行对比测试> 容器内（使用静态文件采集的小伙伴可以参考容器内的静态文件采集进行对比测试，iLogtail纯静态文件采集会比测试2略好容器中的静态文件采集)，测试项详细如下：

　　在真实的生产环境中，log采集组件的可操作性也很重要。为方便运维及后期升级，相比Sidecar模式，K8s下部署采用Daemonset模式采集组件较为常见。但是，由于 Daemonset 将整个集群的 采集 配置同时分发到每个 采集 节点，单个 采集 节点的工作配置必须小于 采集@ 的总数> 配置，因此我们还将进行以下 2 部分实验，以验证 采集config bloat 会影响 采集器 的生产力：

　　

　　最后iLogtail会进行大流量压力测试，如下：

　　三个测试环境

　　所有采集环境数据都存储在[2]中，有兴趣的同学可以自行进行整个对比测试实验。下面介绍不同采集模式的具体配置。如果只关心采集比较结果，可以跳过这部分继续阅读。

　　1 环境

　　运行环境：阿里云ACK Pro版

　　节点配置：ecs.g6.xlarge（4 vCPU 16GB）磁盘ESSD

　　底层容器：Containerd

　　iLogtail 版本：1.0.28

　　FileBeat 版本：v7.16.2

　　2 个数据源

　　对于数据源，我们先去掉正则解析或者多行拼接能力带来的差异，只比较最基本的单行采集。数据生成源模拟nginx访问日志的生成。单条日志大小为283B，以下配置以1000bar/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

　　3 Filebeat标准输出流采集配置

　　Filebeat原生支持容器文件采集，通过add_kubernetes_metadata组件添加kubernetes元信息，为了避免输出组件带来的性能差异，通过drop_event插件drop数据避免输出，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个输入源：

　　下面是不同标准输出流的性能对比采集。可以看出iLogtail相比Filebeat有十倍的性能优势（CPU占比为单核占比）：

　　

　　下面是不同标准输出流的内存对比采集。可以看出logtail和filebeat的整体内存差别不大，并没有随着采集traffic的增加内存暴增：

　　

　　

　　

　　2个容器文件采集性能对比

　　输入数据源：283B/s，共4个输入源：

　　下面是容器采集中不同文件的性能对比。 Filebeat容器中的文件与容器采集共享采集组件，省略了Kubernetes元相关的组件，因此相比标准输出流采集有很大的性能提升。 iLogtail容器内文件采集采用Polling+inotify机制，相比容器标准输出流采集也有性能提升，但可以看到iLogtail与Filebeat相比有5倍的提升性能优势（CPU占比为单核占比）：

　　

　　下面是不同标准输出流的内存对比采集。可以看出logtail和filebeat的整体内存差别不大，并没有随着采集traffic的增加内存暴增：

　　

　　

　　

　　3 采集配置扩展性能对比

　　采集配置扩展性能对比，输入源设置为4，总输入速率为3M/s，50采集配置，100采集配置，500采集 @>配置，1000采集配置比较。

　　标准输出流采集配置膨胀比较

　　下面是不同标准输出流的性能对比采集。可以看到Filebeat与容器底层采集和静态文件采集共享相同的静态文件采集逻辑。标准输出流采集的路径var/log/containers下会有很多正则匹配工作。可以看到虽然采集的数据量并没有因为采集的配置增加而增加，但是CPU消耗增加了10%+，iLogtail全局共享容器路径发现机制针对容器采集模型，避免了常规逻辑带来的性能损失（CPU占比为单核占比）。

　　

　　在内存扩展方面，可以看出Filebeat和iLogtail都有因采集配置增加导致的内存扩展，但两者的扩展大小都在可接受的范围内。

　　

　　

　　

　　容器中的文件采集配置扩展对比

　　下图是容器中文件采集与不同采集器的性能对比，可以看到Filebeat静态文件采集相比标准增加了CPU是由于规避标准输出流的正则路径消耗少，iLogtail CPU变化也小，性能略优于标准输出流采集（CPU的百分比就是单核）。

　　

　　在内存扩展方面，也可以看出Filebeat和iLogtail都有因采集配置增加导致的内存扩展，但两者的扩展大小都在可接受的范围内。

　　

　　

　　

　　4 iLogtail 采集性能测试

　　由于FileBeat在日志量大的场景下存在采集延迟问题，以下场景仅针对iLogtail进行测试，iLogtail的容器标准输出为5M/s、10M/ s 和 20M/s。流 采集 和容器 采集 中的文件的性能压力测试。

　　和上面的测试类似，可以看出容器文件采集的性能在CPU消耗方面略优于容器标准输出流采集（百分比CPU是单核的百分比），主要是因为容器文件采集@采集底层的Polling+inotify机制。

　　

　　在内存方面，由于标准输出流采集主要依赖GO，而容器文件采集主要依赖C，由于GC机制的存在，随着速率的增加，标准输出流采集消耗的内存会逐渐超过容器中文件采集消耗的内存。

　　

　　

　　

　　5 比较总结

　　

　　5 为什么Filebeat容器的标准输出和文件有这么大的差别采集？

　　通过以上实验，我们可以看出FIlebeat在不同工作模式下的CPU差异很大。通过dump容器采集的标准输出流的pprof，可以得到如下火焰图，可以看出Filebeat容器采集下的add_kubernets_meta插件是性能瓶颈。同时FIlebeat的add_kubernets_meta采用了api-server模式监控各个节点，也存在api-server压力问题。

　　

　　iLogtail的kubernetes meta完全兼容kubernetes CRI协议，直接通过kubernets沙箱读取meta数据，保证了iLogtail的高性能采集效率。

　　

　　六大iLogtail DaemonSet场景优化

　　从上面的对比可以看出，iLogtail相比Filebeat，内存和CPU消耗都非常出色。可能有朋友好奇iLogtail的极致性能背后的原因。下面主要讲解iLogtail Daemonset场景下的优化，以及如何将标准输出Streaming比FIlebeat提升10倍的性能。

　　首先针对标准输出流的场景，对比其他开源采集器，比如Filebeat或者Fluentd。一般容器的标准输出流文件的采集是通过*敏*感*词*var/log/containers或者/var/log/pods/来实现的。例如/var/log/pods/的路径结构为：/var/log/pods /_

　　_

　　//，使用该路径复用物理机静态文件采集方式为采集。

　　

　　对于iLogtail，它完全支持容器化。 iLogtail通过发现机制，全局维护一个Node节点容器列表，并实时监控维护这个容器列表。当我们有一个容器列表时，我们有以下优势：

　　

　　七个结论

　　综上所述，在高动态的 Kubernetes 环境下，iLogtail 不会因为 Daemonset 的部署模式带来的多重配置问题而导致内存大的扩展，而在静态文件 采集 方面，iLogtail 有5倍左右的性能优势，对于标准输出流采集，由于iLogtail的采集机制，iLogtail有10倍左右的性能优势。但是，与 Filebeat 或 Fluentd 等老式开源产品相比，文档和社区建设方面仍然存在很多不足。欢迎对iLogtail感兴趣的朋友参与，共同打造易用、高性能的iLogtail产品。

　　参考文献

　　原文链接