引言
Cloud Native
近期，iLogtail 2.0 隆重推出了新功能 SPL 处理模式，进一步增强了日志处理的能力。在本文中，我们将深入探讨为何选择 iLogtail，以及它在 SPL 数据处理方面相较于 Logstash 有何独特优势。通过对比这两款工具的架构、性能以及功能，我们希望能够揭示 iLogtail 如何在日益复杂的日志处理需求中脱颖而出，帮助您做出明智的技术选择。
iLogtail & SPL 介绍
Cloud Native
iLogtail 是阿里巴巴开源的日志采集工具，设计之初便针对大规模数据以及云原生场景进行了优化，旨在提供低延迟、高效率的日志收集解决方案。iLogtail 拥有轻量级、高性能、自动化配置等诸多生产级别特性，在阿里巴巴以及外部数万家阿里云客户内部广泛应用。你可以将它部署于物理机，虚拟机，Kubernetes 等多种环境中来采集可观测数据，例如 logs、traces 和 metrics。
除了语言本身所提供的灵活处理功能之外，iLogtail SPL 本身使用了大量的高性能技术。通过 SIMD 等并行化计算，在保持灵活性的同时兼顾了高性能。
iLogtail SPL vs Logstash Filter
Cloud Native
Logstash 的 filter 插件提供了对日志数据的过滤、解析和修改能力。常见的插件如 grok（grok 正则解析）、date（时间解析）、mutate（修改字段）等等。通过将这些插件组合成一条流水线的方式，Logstash 提供了强大的日志数据处理能力。那么，与 iLogtail 的 SPL 处理模式相比，两者孰强孰弱呢？接下来，我们将从功能支持和场景性能两个方面进行 PK。
根据最新的官方文档 [ 2] ，Logstash 目前提供了 49 种 filter 插件功能，基本覆盖了常见的日志处理场景。用户通过在配置文件中编写配置，将这些插件组合起来。
SPL 作为一个流式处理语言，同样提供了丰富的算子和可编程性。根据最新的官方文档 [ 3] ，SPL 提供了 8 种数据处理的指令，包括正则解析、Json 解析等等常见的功能。除此之外，SPL 还兼容大部分 SQL 指令，提供了 110 个 SQL 中常见的数据解析和处理指令，并且仍在积极开发，提供更多的处理功能。基于这些指令，用户可以编写 SPL 语句满足各种数据处理需求。
正则解析 + 时间解析
以 nginx access log 为例，输入：
142.207.88.67 - - [18/Jun/2024:12:14:26 +0800] "DELETE http://www.districtdot-com.biz/syndicate HTTP/1.1" 289 3715 "http://www.chiefscalable.biz/webservices" "Mozilla/5.0 (iPhone; CPU iPhone OS 8_2_1 like Mac OS X; en-US) AppleWebKit/534.46.7 (KHTML, like Gecko) Version/5.0.5 Mobile/8B119 Safari/6534.46.7"不同条件下添加、删除、过滤字段
以一段简单的 Json 日志为例，根据其中的 user-agent 添加一个新的字段：
{"url": "POST /PutData HTTP/1.1", "user-agent": "aliyun-sdk-java"}
在 Logstash 中，由于配置文件本身有自身的一套语法，也提供了一定的可编程性。
但作为配置文件语言，并不是特别擅长进行数据处理。
其语法与 SPL 兼容 SQL 的语法相比，书写复杂度显然更高，使得配置文件冗长且难以管理。
而且 Logstash 处理插件本身使用了 Ruby 实现，其对于数据并行性的利用也存在着一定局限性，在下一章中将进行详细地展开。
多层嵌套 Json 提取与解析
在很多情况下，原始日志是一个复杂的嵌套 Json 结构。对于其中的字段需要进一步处理才可以存入到后端中。假设如我们需要对以下的 Nginx 日志进行处理：
2024-06-24 12:26:04.063 INFO 24 --- [traceId=edda5daxxxxxxxxxcfa3387d48][ xnio-1 task-1] c.g.c.gateway.filter.AutoTestFilter : {"traceId":"edda5da8xxxxxxxxxxxxxxxxxxx387d48","headers":[{"x-forwarded-proto":"http,http","x-tenant-id":"123","x-ca-key":"a62d5xxxxxxxxxxxxxxxxxxxxxxxxb1cff8637","x-forwarded-port":"80,80","x-forwarded-for":"10.244.2.0","x-ca-client-ip":"10.244.2.0","x-product-code":"xxxxx","authorization":"bearer 0ed29xxxxxxxxxxxxxxxxxxxxxxxxx71899","x-forwarded-host":"gatxxxxxxxxx.gm","x-forwarded-prefix":"/xxxxxx","trace-id":"edda5da8278xxxxxxxxxxxxxxxxxxx49cfa3387d48","x-ca-api-id":"1418470181321347075","x-ca-env-code":"TEST"}],"appName":"超级管理员","responseTime":15,"serverName":"test-server","appkey":"a62d54b6bxxxxxxxxxxxxxxxxxxx37","time":"2021-08-01 12:26:04.062","responseStatus":200,"url":"/test/v4/orgs/123/list-children","token":"bearer 0ed29c72-0d68-4e13-a3f3-c77e2d971899"}包括以下的处理步骤：
Logstash 不支持解析嵌套的 Json 日志，所以在解析时需要一系列麻烦的操作。iLogtail SPL 支持 JsonPath 解析，从而可以更简洁地从 Json 字符串中提取嵌套的字段的值。除此之外，与 Logstash 类似，iLogtail SPL 也提供了丰富的字符串操作方法，能够对字符串进行一系列复杂的解析操作。
作为一个日志采集器，所占用的资源也至关重要。如果占用的资源过多，对用户的业务产生了影响，这也是不可接受的。接下来，本文将对 iLogtail 和 Logstash 采集日志时所占用的资源使用量进行对比。
由于 Logstash 本身不支持采集 K8s 场景下的日志，所以以 Linux 主机为测试场景，测试两个采集器在采集前文提到的 Nginx access log 时的资源占用情况。
-
测试环境：8 核 16GB，操作系统 Ubuntu 22.04 -
测试版本：iLogtail 2.0.4，Logstash 8.14.1，两者均使用默认参数配置 -
测试场景： -
场景一：正则解析+时间解析 -
场景二：不同条件下添加、删除、过滤字段 -
场景三：多层嵌套 Json 提取与解析 -
测试数据：以 1MB/s、5MB/s、10MB/s 生成日志写入到文件中，总时长 3 分钟
下面为三个场景中对 iLogtail 和 Logstash 进程资源使用量的监控：
场景一：正则解析+时间解析
场景二：不同条件下添加、删除、过滤字段
观察： 在日志生成（180 秒）结束后，Logstash 仍然还在进行处理日志，说明其处理能力已经达到了瓶颈，采集出现了比较大的延迟。
为了进一步探究 Logstash 和 iLogtail 的采集瓶颈在哪里，我们进一步细化测试不同的日志生成速率，并以 CPU 使用率低于 0.1 作为采集处理结束，3 秒作为正常的采集延迟。最终，我们测试发现 Logstash 在场景二中的处理瓶颈在日志生成 8MB/s。而 iLogtail 在 50MB/s 仍然可以几乎无延迟地采集日志，并且资源使用仍然保持了较低的水平（CPU 使用率 130%，内存使用 61MB）。两者之间性能相差 6 倍！
场景三：多层嵌套 Json 提取与解析
