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/v1
kind: Job
metadata:name: nginx-log-demo-0namespace: default
spec:template:metadata:name: nginx-log-demo-0spec:restartPolicy: Nevercontainers:- 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-0resources:limits:memory: 200Mirequests:cpu: 10mmemory: 10Mivolumes:- name: pathhostPath:path: /testlogtype: DirectoryOrCreatenodeSelector: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: 30sprocessors:- add_kubernetes_metadata:host: ${NODE_NAME}matchers:- 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: 524288paths:- /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: 30soutput.console:pretty: falsequeue:mem:events: 4096flush.min_events: 2048flush.timeout: 1smax_procs: 4filebeat.inputs:- type: logharvester_buffer_size: 524288paths:- /testlog/nginx-log-demo-0/*.logprocessors:- 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 使用指南

原文链接

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

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/511533.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

如何快速开发 Serverless Devs Package ?

如何快速开发 Serverless Devs Package ?

简介&#xff1a;目前&#xff0c;开发者开发 Serverless Package 的流程相对来说是比较简单的。因为在 Serverless Devs 开发者工具中&#xff0c;已经提供了相对完整的脚手架能力&#xff0c;一文了解详情~ 作者 | 江昱&#xff08;阿里云 Serverless 产品经理&#xff09; …
阅读更多...
首发苹果 M2！MacBook Pro 正式开售，更像是一个增强版的 A15？

首发苹果 M2！MacBook Pro 正式开售，更像是一个增强版的 A15？

作者 | Ryan Smith 译者 | 弯月出品 | CSDN虽然一年一度的WWDC主要是一个软件发布会&#xff0c;但也总是时不时地给出一些硬件惊喜&#xff0c;今年也不例外。在WWDC22上&#xff0c;苹果公布了用于Mac&#xff08;和iPad&#xff09;平台的第二代苹果系统芯片——M2。这个…
阅读更多...
专题实战 | 如何快速构建高质量电商行业搜索？

专题实战 | 如何快速构建高质量电商行业搜索？

简介&#xff1a;本文详细介绍如何快速接入智能开放搜索&#xff08;OpenSearch&#xff09;电商行业增强版&#xff0c;助力企业实现高质量搜索效果&#xff0c;提升业务转化率及用户产品体验&#xff01; 电商搜索特点 1. 关键词堆砌 例如&#xff1a;明星同款夏季连衣裙包…
阅读更多...
Linux 网络性能的 15 个优化建议！

Linux 网络性能的 15 个优化建议！

作者 | 张彦飞allen来源 | 开发内功修炼那么具备了对网络的深刻的理解之后&#xff0c;我们在性能方面有哪些优化手段可用呢&#xff1f;我这里给出一些开发或者运维中的性能优化建议。这些建议都是从书中摘录的。不过要注意的是&#xff0c;每一种性能优化方法都有它适用或者不…
阅读更多...
Flink Sort-Shuffle 实现简介

Flink Sort-Shuffle 实现简介

简介&#xff1a;Sort-Shuffle 使 Flink 在应对大规模批数据处理任务时更加游刃有余 本文介绍 Sort-Shuffle 如何帮助 Flink 在应对大规模批数据处理任务时更加游刃有余。主要内容包括&#xff1a; 数据 Shuffle 简介引入 Sort-Shuffle 的意义Flink Sort-Shuffle 实现测试结果调…
阅读更多...
「现代C++设计魅力」虚函数继承-thunk技术初探

「现代C++设计魅力」虚函数继承-thunk技术初探

简介&#xff1a;工作中使用LLDB调试器调试这一段C多继承程序的时候&#xff0c;发现通过lldb print(expression命令的别名) 命令获取的指针地址和实际理解的C的内存模型的地址不一样。那么到底是什么原因呢&#xff1f; 作者 | 扬阜 来源 | 阿里技术公众号 一 问题背景 1 实…
阅读更多...
万物互联时代到来，锐捷发布场景化无线零漫游方案

万物互联时代到来，锐捷发布场景化无线零漫游方案

数字化和万物互联时代到来&#xff0c;物联网与 IoT 设备发展迅猛&#xff0c;以往只在办公区域主要由手机等移动设备使用的无线网络&#xff0c;正在接入更多核心业务生产、物流仓储等各类的生产设备。据分析机构 IDC 预测&#xff0c;无线网络优先是当下智能园区网络建设投资…
阅读更多...
阿里云田涛涛：高效智能的云，CloudOps让运维更简单

阿里云田涛涛：高效智能的云，CloudOps让运维更简单

简介&#xff1a;CloudOps:以应用为中心的自动化运维新趋势 12月21日&#xff0c;在阿里云弹性计算年度峰会上&#xff0c;阿里云弹性计算体验与控制系统负责人田涛涛发表了主题为《高效智能的云&#xff0c;CloudOps让运维更简单》的演讲&#xff0c;深度解读了云上运维新趋势…
阅读更多...
打造南沙“强芯”，南沙首届IC Nansha大会召开

打造南沙“强芯”，南沙首届IC Nansha大会召开

6月25日&#xff0c;2022 中国南沙国际集成电路产业论坛在广州南沙召开。本次峰会由广州南沙经济技术开发区管理委员会、广州市工业和信息化局主办&#xff1b;支持单位为广州湾区半导体产业集团有限公司、广东省集成电路行业协会、广州市半导体协会&#xff1b;广东省半导体及…
阅读更多...
OpenAI开发者大会简介

OpenAI开发者大会简介

文章目录 GPT-4 Turbo 昨天晚上 OpenAI的首届开发者大会召开 Sam Altman也做了公开演讲&#xff0c;应该说 这是继今年春天发布GPT-4之后 OpenAI在AI行业又创造的一个不眠夜 过去一年 ChatGPT绝对是整个科技领域最热的词汇 OpenAI 也依靠ChatGPT取得了惊人的成绩 ChatG…
阅读更多...
阿里云贾少天：大规模云服务器高效使用及管理实践

阿里云贾少天：大规模云服务器高效使用及管理实践

简介&#xff1a;本篇内容分享了大规模云服务器高效使用及管理最佳实践。 2021年10月22日&#xff0c;在云栖大会的《云上运维最佳实践》分论坛&#xff0c;阿里云高级技术专家贾少天发表了主题为“大规模云服务器高效使用及管理最佳实践”的演讲&#xff0c;本篇内容根据他的…
阅读更多...
发现新视界——视觉计算将如何改变生产方式

发现新视界——视觉计算将如何改变生产方式

简介&#xff1a;本篇内容将从3个部分为读者介绍关于视觉计算如何改变生产方式&#xff0c;进一步阐述可视化业务方面的挑战及阿里云视觉计算的解决方案与优势。 编者按&#xff1a;在2021年10月举办的云栖大会的《数字孪生&Cloud XR技术助力产研创新论坛》上&#xff0c;…
阅读更多...
容器监控指南：三剑客轻松实现 Docker 容器监控

容器监控指南：三剑客轻松实现 Docker 容器监控

作者 | Milan Mahat在本指南中&#xff0c;我们将学习如何使用 docker-compose 在容器中设置 cAdvisor&#xff0c;将其与 prometheus 连接&#xff0c;并通过 grafana 监控服务器的容器。CAdvisor 是一种流行的工具&#xff0c;用于收集容器的信息。它是 prometheus 和 grafan…
阅读更多...
N个技巧，编写更高效 Dockerfile｜云效工程师指北

N个技巧，编写更高效 Dockerfile｜云效工程师指北

简介&#xff1a;云原生时代下软件的构建和部署离不开容器技术。提到容器&#xff0c;几乎大家下意识都会联想到 Docker 。而 Docker 中有两个非常重要的概念&#xff0c;一个是Image&#xff08;镜像&#xff09;&#xff0c;一个是Container&#xff08;容器&#xff09;。前…
阅读更多...
TDA-04D8变送器数据上报阿里云

TDA-04D8变送器数据上报阿里云

简介&#xff1a;本文将以TDA-04D8变送器作为采集对象&#xff0c;使用海创微联采集控制系统对TDA-04D8变送器进行采集&#xff0c;然后将设备上的毛重、净重、皮重数据采集上传到阿里云物联网平台&#xff0c;阿里云物联网平台将数据实时可视化。 文章分为3部分&#xff1a; …
阅读更多...
http ，怎么优雅的拒绝你

http ，怎么优雅的拒绝你

作者 | 奇伢来源 | 奇伢云存储典型问题&#xff1a;服务端优雅的拒绝今天分享一个后端编程的实际经验。这个问题来源于对象 S3 后端协议实现的技巧思考。场景&#xff1a;服务端不想接收 http 的 body 的时候&#xff0c;该怎么优雅的拒绝呢&#xff1f;什么意思&#xff1f;对…
阅读更多...
企业物联网平台新版公共实例升级企业实例教程

企业物联网平台新版公共实例升级企业实例教程

简介&#xff1a;2021年7月30日企业物联网平台重磅升级&#xff0c;发布的新版公共实例支持一键升级企业版实例&#xff0c;本文将为大家介绍一键升级教程 一、企业版实例&#xff0c;企业用户首选 企业物联网平台 提供设备上云必备的基础服务&#xff0c;用户无需自建物联网…
阅读更多...
【全观测系列】Elasticsearch应用性能监控实践

【全观测系列】Elasticsearch应用性能监控实践

简介&#xff1a;本文介绍了应用性能监控的应用价值以及解决方案等。 1、什么是全观测&#xff1f; 要了解全观测&#xff0c;我们先看看传统运维存在哪些问题。 数据孤岛&#xff0c;分散在不同部门&#xff0c;分析排查故障困难&#xff1b;多个厂商的多种工具&#xff0c…
阅读更多...
es实战-使用IK分词器进行词频统计

es实战-使用IK分词器进行词频统计

简介&#xff1a;通过IK分词器分词并生成词云。 本文主要介绍如何通过 IK 分词器进行词频统计。使用分词器对文章的词频进行统计&#xff0c;主要目的是实现如下图所示的词云功能&#xff0c;可以找到文章内的重点词汇。后续也可以对词进行词性标注&#xff0c;实体识别以及对…
阅读更多...
IC Nansha|AMD高级副总裁、大中华区总裁潘晓明：制程、架构、平台优化突破计算边界

IC Nansha|AMD高级副总裁、大中华区总裁潘晓明：制程、架构、平台优化突破计算边界

6月25日&#xff0c;中国南沙国际集成电路产业论坛在广州南沙顺利举行。AMD高级副总裁、大中华区总裁潘晓明出席了本次会议&#xff0c;并在高峰论坛环节中以《高性能计算的未来》为主题发表了演讲。 &#xff08;AMD高级副总裁、大中华区总裁 潘晓明&#xff09; 作为一家深耕…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023