公司一直使用的Filebeat进行日志采集
由于Filebeat采集组件一些问题，现需要使用iLogtail进行代替
现记录下iLogtail介绍和实际使用过程
这是iLogtail系列的第五篇文章
目录
前期准备
内存、cpu占用情况对比
采集与发送速率对比
总结
官方对比数据
性能分析
前期准备
为了保证测试环境尽量相同，所以将iLogtail和Filebeat安装在同一台机器上，并配置相同的采集路径，输出数据各发送一个kafka。
iLogtail和Filebeat的性能配置均未修改，因为修改后会用性能换取传输速率和时间，真实使用场景下会影响机器上其他应用，所以目前均采用常规配置，后期可进行性能配置调优。
Filebeat配置如下
| filebeat.prospectors: - input_type: log paths: - /logs/xxx/error.log document_type: DEV_MONITOR_ERROR_LOG close_renamed: true close_removed: true scan_frequency: 1s max_bytes: 31457280 harvester_buffer_size: 409600 fields: xxx: xxx multiline: pattern: '^s*[*[0-9]{4}(/|-)[0-1][0-9](/|-)[0-3][0-9](T*| )[0-2][0-9]:[0-5][0-9]:[0-5][0-9]' negate: true match: after tail_files: true max_procs: 1 filebeat.spool_size: 102400 filebeat.idle_timeout: 1s output.kafka: enabled: true hosts: ["99.67.0.94:5386"] topic: '%{[type]}' metadata: retry.max: 3 retry.backoff: 250ms refresh_frequency: 10m max_retries: 3 bulk_max_size: 2048 timeout: 30s |
iLogtail配置如下
| { "metrics": { "##1.0##kafka_output_test2": { "category": "file", "log_type": "common_reg_log", "keys": ["content"], "regex": ["(.*)"], "log_path": "/logs/xxx", "file_pattern": "*.log", "create_time": 1631018645, "defaultEndpoint": "", "delay_alarm_bytes": 0, "delay_skip_bytes": 0, "discard_none_utf8": false, "discard_unmatch": false, "docker_exclude_env": {}, "docker_exclude_label": {}, "docker_file": false, "docker_include_env": {}, "docker_include_label": {}, "enable": true, "enable_tag": false, "file_encoding": "utf8", "filter_keys": [], "filter_regs": [], "group_topic": "", "plugin": { "processors": [ { "type":"processor_add_fields", "detail": { "Fields": { "input_type": "log", "type": "LOGTAIL_LOG", "offset": "offset", "@timestamp": "@timestamp", "beat": "beat", "fields": "fields" } } }, { "type":"processor_rename", "detail": { "SourceKeys": ["__tag__:__path__","content"], "DestKeys": ["source","message"], "NoKeyError": true } } ], "flushers": [ { "type": "flusher_kafka", "detail": { "Brokers": [ "99.67.0.94:9092" ], "Topic": "logtail-flusher-kafka" } } ] }, "local_storage": true, "log_tz": "", "max_depth": 10, "max_send_rate": -1, "merge_type": "topic", "preserve": true, "preserve_depth": 1, "priority": 0, "raw_log": false, "aliuid": "", "region": "", "project_name": "", "send_rate_expire": 0, "sensitive_keys": [], "shard_hash_key": [], "tail_existed": false, "time_key": "", "timeformat": "", "topic_format": "none", "tz_adjust": false, "version": 1, "advanced": { "force_multiconfig": false, "tail_size_kb": 1024 } } } } |
内存、cpu占用情况对比
在确认了/logs/xxx下磁盘空间充足的情况下，加入约720M的数据，快速加入数据测试两者数据采集性能。
iLogtail和Filebeat 关于cpu使用率比3.3%：26.2%，大约是1：8
iLogtail和Filebeat 关于物理内存使用率比约是1：1
由于加入速率过慢，iLogtail和Filebeat都能及时处理，无法测出采集能力。
采集与发送速率对比
由于模拟实时加入的方式，iLogtail和Filebeat都能及时消费，所以采取新建大文件的方式，对两者采集性能进行对比。
时间：14:19:38 ，将1000M数据文件error.log加入采集目录供iLogtail和Filebeat采集。
查看iLogtail发送的kafka中数据，发现14:19:44采集完成，耗时10s以内，平均采集及发送速率确实可以达到官方介绍的100M/s
查看Filebeat发送的kafka中数据，发现14:23:47采集完成，耗时约250s，平均采集及发送速率约4M/s
总结
| 性能对比项 | iLogtail | Filebeat | 结论 |
|---|---|---|---|
| 物理内存占用率 | 1.10% | 1.10% | 两者相似 |
| cpu占用率 | 3.30% | 26.20% | iLogtail明显占优 |
| 采集与发送速率 | 100M/s | 4M/s | iLogtail明显占优 |
官方对比数据
https://github.com/alibaba/ilogtail/blob/main/docs/zh/performance/Performance-compare-with-filebeat.md
性能分析
iLogtail采用轮询+事件的日志采集方式：
对于日志采集，大家很容易想到通过定期检测日志文件有无更新来进行日志采集，这种我们一般称之为轮询(polling)的方式。轮询是一种主动探测的收集方式，相对也存在被动监听的方式，我们一般称之为事件模式。事件模式依赖于操作系统的事件通知，在linux下2.6.13内核版本引入inotify， 而windows在xp中引入FindFirstChangeNotification，两者都支持以被动监听的方式获取日志文件的修改事件。
轮询和事件之间的区别，对比如下：
| 轮询 | 事件 | |
| 实现复杂度 | 低 | 高 |
| 跨平台 | 不依赖操作系统 | 不同操作系统单独实现 |
| 采集延迟 | 高 | 低 |
| 资源消耗 | 高 | 低 |
| 系统限制 | 基本无限制 | 依赖内核/驱动 |
| 资源限制 | 基本无限制 | 依赖系统 |
| 大规模场景 | 支持较差 | 支持 |
轮询相对事件的实现复杂度要低很多、原始支持跨平台而且对于系统限制性不高；但轮询的采集延迟（默认加上轮询间隔一半的采集延迟）以及资源消耗较高，而且在文件规模较大（十万级/百万级）时轮询一次的时间较长，采集延迟非常高。
filebeats采用基于轮询的方式，相对事件实现较为简单，而且对于大部分轻量级场景基本适用。但这种方式就会暴露以上对比中出现的采集延迟、资源消耗以及大规模环境支持的问题，部分对于这些条件要求较高的应用只能望而却步。
logtail为了同时兼顾采集效率以及支持各类特殊采集场景，logtail使用了轮询与事件并存的混合方式（目前只支持linux，windows下方案正在集成中）。一方面借力inotify的低延迟与低性能消耗，另一方面使用轮询兼容不支持事件的运行环境。
