简介
阿里云 SLS 是云上一站式大数据处理、分析平台。SLS 数据加工功能则是一个可托管、高可用、可扩展的数据处理服务，广泛适用于数据的规整、富化、分发、汇总、重建索引等场景。Logstash 是 ELK 数据架构中，作为数据处理的组成部件，其能够从多个来源采集数据，转换数据，然后将数据发送到目标“存储库”中。这里，我们就对 SLS 数据加工和自建 Logstash 这二者做一个全方位的对比。
SLS 数据加工
- 易用：功能丰富，已经实现 200+ DSL 算子。开箱即用，无需部署、运维
- 实时：实时处理、秒级延迟。可以通过源 logstore 的 shard 数目实现即时扩展
- 实惠：按量付费，无需预留。成本才是 0.15元/GB
Logstash
Logstash 是开源的数据处理工具，生态非常丰富，可以嵌入到很多数据处理架构中。而且从 软件实用角度来说，它是免费的。但是系统的计算资源，以及系统的部署、运维工作都是自理。
对比
功能
数据处理包括4个主要场景：事件操作（过滤/复制/分裂）、字段操作（过滤/解析/转换）、数据富化、数据聚集。从这4个场景对比二者的功能。
| 场景 | 数据加工 | Logstash |
|---|---|---|
| 事件操作 （过滤/复制/分裂） |
drop/keep copy split drop_field/keep_field |
drop clone split |
| 字段操作 （过滤/解析/转换） |
REGEX (GROK) JSON KV …… |
mutate/alter GROK CSV JSON …… |
| 数据富化 | GeoIP MySQL OSS文件 IP/OSS风险扫描（即将上线） |
GeoIP DNS JDBC |
| 数据聚集 | 规划中 | aggregate 支持单worker内，无法扩展 |
从以上对比表格中可以看出，前2个场景二者都很好的支持。在数据富化场景中，数据加工所支持的富化途径更为丰富。数据加工暂时不支持数据聚集场景（在规划中）。Logstash 的 aggregate 能够支持部分聚集功能，但是只能在单 worker 内部进行聚集，无法扩展到多 worker，更没法扩展到集群，所以 Logstash aggregate 无法应用到大数据场景。
成本
实例：nginx 访问日志解析
Nginx 是目前非常受欢迎的 WebService。这里就以 nginx 的访问日志解析为例，分别看一下数据加工的Logstash 的解析代码。
原始日志（文本）：
192.168.56.1 - - [21/Apr/2020:02:42:11 +0800] "GET /?a=1&b=2&c=3&e=11 HTTP/1.1" 200 612 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0"解析目标：
- 通过正则匹配，抽取出访问日志中的每个组成部分
- 把时间转换为标准 ISO8601 格式
- 抽取请求 URL 中的参数
- 抽取出请求 UserAgent 的信息
{
"os": "{\"family\": \"Mac OS X\", \"major\": \"10\", \"minor\": \"15\", \"patch\": \"3\"}",
"bytes": "612",
"client": "192.168.1.1",
"status": "200",
"http_version": "HTTP/1.1\"",
"uri": "/",
"param:e": "11",
"time": "2020-04-21 02:42:11",
"refer": "\"-\"",
"device": "{\"family\": \"Other\"}",
"user_agent": "{\"family\": \"Chrome\", \"major\": \"80\", \"minor\": \"0\", \"patch\": \"3987\"}",
"method": "GET",
"param:c": "3",
"user": "-",
"param:a": "1",
"param:b": "2"
}SLS 数据加工
e_regex("message", grok("%{IPORHOST:client} - %{USER:user} \[%{HTTPDATE:time}\] %{QS:request} %{NUMBER:status} (?:%{NUMBER:bytes}|-) %{QS:refer} %{QS:user_agent}"))
e_regex("request", grok("%{WORD:method} %{URIPATH:uri}%{URIPARAM:params} %{NOTSPACE:http_version}"))
e_set("time", dt_strftime(dt_strptime(v("time"), "%d/%b/%Y:%H:%M:%S %z"), "%Y-%m-%d %H:%M:%S"))
e_kv("params", prefix="param:")
e_set("user_agent", ua_parse_all(v("user_agent")))
e_json("user_agent", depth=1, mode="overwrite")
e_drop_fields("message", "request", "params", regex=False)Logstash 规则
filter {
grok {
match => { "message" => "%{IPORHOST:client} - %{USER:user} \[%{HTTPDATE:time}\] %{QS:request} %{NUMBER:status} (?:%{NUMBER:bytes}|-) %{QS:refer} %{QS:user_agent}" }
}
grok {
match => { "request" => "%{WORD:method} %{URIPATH:uri}%{URIPARAM:params} %{NOTSPACE:http_version}" }
}
date {
match => ["time", "dd/MMM/yyyy:HH:mm:ss Z"]
target => "time"
}
kv {
source => "params"
prefix => "param:"
field_split => "?&"
}
useragent {
target => "user_agent"
source => "user_agent"
}
mutate {
remove_field => [ "message", "request", "params" ]
}
}成本计算
以上实例，基于阿里云 ecs.g6e.xlarge 型号的 ECS 进行测试 logstash，4 CPU + 16 GB RAM + 100 GB ESSD，成本 578 元/月（包年包月）。在此场景下，logstash 的性能为 8000条/秒/Core。测试场景预设：
- 系统每天的 PV 为 10亿
- 峰值 QPS 是平均值的5倍：10亿/86400秒 * 5 = 57870/秒
- 平均每条访问日志 200 Bytes
数据加工：
- 每个月的数据量：10亿 * 200 Bytes * 30 = 5588 GB/月
- 总成本：0.15 元/GB/月 * 7153 GB = 838 元/月
Logstash：
- 计算资源需求：57870/秒 / 8000条/秒/Core = 7.23 Core，即2台 ecs.g6e.xlarge
- 支撑业务增长需求，预留 20% 水位：578 元/月 * 2 * 120% = 1387/月
根据以上计算，在该测试场景下，SLS 数据加工的成本仅仅是自建 logstash 所需的资源成本的 60%。
综合
| 维度 | 数据加工 | Logstash |
|---|---|---|
| 功能 | 1. Python 语法，灵活 2. 预定义算子丰富 3. 数据富化途径丰富 |
1. 自定义语法 2. 支持 Ruby 代码 |
| 实时性 | 秒级 服务端弹性伸缩保证 |
秒级 集群资源算力保证 |
| 缓存 | 支持 无需任何配置 |
Kafaka/Persistent Queues 部署、运维自理 |
| 扩展 | 源 logstore 的 shard 数目 简单方便、即时生效 |
前置 Kafaka / LoadBalancer 额外部署 |
| 资源预留 | 不需要 按量付费 |
需要 支撑业务增长、非预期爆发 |
| 运维 | 开箱即用、免运维 | 系统部署、运维完全自理 |
| 成本 | 实惠 （测试中仅为自建 logstash 所需资源成本的60%） |
除了资源成本，还需考虑系统运维成本 |
从以上对比表格中不难看出，在数据处理的业务场景中，SLS 数据加工整体比 logstash 更有优势。Logstash 的于是在于其通用性，各种数据处理架构都可嵌入使用。
总结
通过以上的对比，我们的到 SLS 数据加工和 自建 logstash 分别适用于各自的场景。
数据加工：
- 在 SLS 大数据分析平台上，无运维、易扩展、成本实惠
- 适合从一般数据量、到超大型数据量的处理
自建 Logstash：
- 开源、生态丰富适，各种数据处理架构通用
- 适合一般数据量的处理（面对大型数据量场景，运维成本昂贵）
