SLS 数据加工 vs 自建 Logstash-阿里云开发者社区

开发者社区> 开发与运维> 正文

SLS 数据加工 vs 自建 Logstash

简介: 阿里云 SLS 是云上一站式大数据处理、分析平台。SLS 数据加工功能则是一个可托管、高可用、可扩展的数据处理服务,广泛适用于数据的规整、富化、分发、汇总、重建索引等场景。

简介

阿里云 SLS 是云上一站式大数据处理、分析平台。SLS 数据加工功能则是一个可托管、高可用、可扩展的数据处理服务,广泛适用于数据的规整、富化、分发、汇总、重建索引等场景。Logstash 是 ELK 数据架构中,作为数据处理的组成部件,其能够从多个来源采集数据,转换数据,然后将数据发送到目标“存储库”中。这里,我们就对 SLS 数据加工和自建 Logstash 这二者做一个全方位的对比。

SLS 数据加工

SLS 数据加工.png

  • 易用:功能丰富,已经实现 200+ DSL 算子。开箱即用,无需部署、运维
  • 实时:实时处理、秒级延迟。可以通过源 logstore 的 shard 数目实现即时扩展
  • 实惠:按量付费,无需预留。成本才是 0.15元/GB

Logstash

Logstash.png

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"

解析目标:

  1. 通过正则匹配,抽取出访问日志中的每个组成部分
  2. 把时间转换为标准 ISO8601 格式
  3. 抽取请求 URL 中的参数
  4. 抽取出请求 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

数据加工:

  1. 每个月的数据量:10亿 * 200 Bytes * 30 = 5588 GB/月
  2. 总成本:0.15 元/GB/月 * 7153 GB = 838 元/月

Logstash:

  1. 计算资源需求:57870/秒 / 8000条/秒/Core = 7.23 Core,即2台 ecs.g6e.xlarge
  2. 支撑业务增长需求,预留 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:

  • 开源、生态丰富适,各种数据处理架构通用
  • 适合一般数据量的处理(面对大型数据量场景,运维成本昂贵)

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章