簡介：前段時間, 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 使用指南

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的iLogtail 与Filebeat 性能对比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。