日志服务 SLS 和开源 ELK 全面对比

概述

Elasticsearch 的第一个版本在2010年发布，在 2015 年 ELK Stack（Elastic Logstash Kibana）推出解决集中式日志采集、存储和查询问题。ElasticSearch 基于 Lucene 全文索引实现，查询分析实现成本较高。Lucene 设计场景是 Information Retrial，面对是 Document 类型，因此对于可观测分析（Log/Trace/Metric）数据有一定限制，例如规模、查询能力、以及一些定制化功能（例如智能聚类 LogReduce）。

阿里云日志服务 SLS 基于阿里云自研灵活索引的一站式云原生可观测数据分析平台。为Log/Metric/Trace 等数据提供大规模、低成本、实时平台化服务。一站式提供数据采集、加工、分析、告警可视化与投递功能，全面提升研发、运维、运营和安全等场景数字化能力。

本文详细阐述了阿里云日志服务 SLS 和开源 ELK 在性能、成本、功能等维度的对比分析。

• 性能：开源 ELK 方案比 SLS 性能更差。SLS 查询和分析性能高达自建 ELK 的十倍，且随着并发增加，延迟保持稳定。
• 成本：开源 ELK 方案比 SLS 更贵。要维护良好状态的 ELK 集群，需要从容量规划、稳定性保障、性能调优、数据高可用，数据如何在不同系统间关联等多个方面下功夫。SLS 全托管免运维无需花费额外人力投入。百 TB 规模下，SLS 综合成本是 ELK 的 44%。
• 功能：开源 ELK 方案比 SLS 更复杂。开源 ELK 构建完整可观测分析平台需组合多款服务，这其中包括Logstash、Kibana、Kafka、Flink、TSDB、Prometheus等。SLS 支持一站式数据监控分析平台能力。
• 可观测数据平台：开源 ELK 方案相比 SLS 存在数据孤岛现象。SLS 可观测数据统一存储支持 log metric trace 数据存储，打通数据孤岛。
• 算法支持：开源 ELK 方案比 SLS 支持更有限的聚合算法。ELK 仅支持指标分析聚合、分桶聚合、管道分析、矩阵分析有限的聚合算法。SLS 针对数据分析场景支持 30+ 聚合计算函数，丰富的机器学习函数以及多渠道数据源。
• 告警能力：开源 ELK 比 SLS 的告警能力更低效。开源 ELK 仅支持同一结构多索引合并分析有限的告警能力。SLS 相比 ELK 提供全面监控、智能降噪和多为分析的能力。

自建 ELK 性能更差

SLS 可以支持百 PB 级的日志量，查询效率极高，百亿条数据数秒内出结果，多运算亿级数据 1 秒出结果。ELK 超过 10TB 就会遇到性能瓶颈。SLS 查询和分析性能高达自建 ELK 的十倍，且随着并发增加，延迟保持稳定。

查询场景性能测试：

• 1/10 亿条数据查询 5 条件，并发 1/5/10 查询
• 1 亿数据量规模下查询性能与 ES 持平
• 10 亿数据量规模下性能高达 ES 的十倍
• 随着并发增加，延时保持稳定

统计分析场景性能测试：

• 1/10 亿条数据，并发 1/5/10 分析
• SLS 分析性能高达 ES 的十倍
• 随着并发增加，延时保持稳定

测试环境：

• 测试机器 ： 5台
• Replica ：1
• 磁盘类型 ： 本地盘， 所有磁盘都使用（* 4）
• Index ： 每个 Index 20 个shard
• ES 版本： 7.10.1
• ECS 规格： ecs.d1ne.2xlarge 8 vCPU 32 GiB （I/O优化）
• ES jvm 配置： -Xms26g -Xmx26g
• 检索 Query：Status: 200 and Method:PostLogStoreLogs and ProjectName: hangzhou and InFlow>2048 and UserAgent:"aliyun-log-java-producer"
• 统计分析 SQL：select count(*), avg(Latency), sum(InFlow), ProjectName group by ProjectName

自建 ELK 成本更贵：包括服务器、运维难度、人力在内的综合成本

百 TB 规模下，SLS 综合成本是 ELK 的 44%，很多 ELK 客户转向 SLS 的重要考虑是包括服务器、运维难度、人力在内的综合成本。参考【资源成本对比：全索引场景】

要维护良好状态的 ELK 集群，需要从容量规划、稳定性保障、性能调优、数据高可用，数据如何在不同系统间关联等多个方面下功夫。SLS 全托管免运维无需花费额外人力投入！参考【资源工作项对比】

现实场景中，自建资源成本受用户服务器选型、组合情况，以及供应链的议价能力影响，存在较大差异。以下仅以两个极限的实验环境场景对比，数据结果仅供参考。

资源成本对比：全索引场景

ECS SSD（7天热数据）+ 高效云盘磁盘（7天以上冷数据）vs SLS 标准版

• 测试机型 ecs.g7.4xlarge：16Core、64GB、￥2208 /月
• 写入吞吐： 每秒写入峰值 16MB/sec 平均 8MB/sec， 一天写入量 0.66TB 写多查少
• 磁盘空间： 原始数据 * 1.1（膨胀率） *1.25 = 原始数据 * 1.375，ESSD-PL0 0.5元/GB/月 高效云盘 0.35元/GB/月，ES 0 副本

每天写入量	保存天数	计算需要机器数	需要存储空间（TB）	机器费用	存储费用	ELK费用每月	SLS费用每月	SLS/自建
10	30	15.15	96.25(热) + 316.25(冷)	¥33454.55	¥162624	¥196078.55	¥234954	1.19
10	90	15.15	96.25(热) + 1141.25(冷)	¥33454.55	¥458304	¥491758.55	¥339371	0.66
10	180	15.15	96.25(热) + 2378.75(冷)	¥33454.55	¥901824	¥935278.55	¥495997	0.69

ECS + ESSD（7天热数据）+ 高效云盘磁盘 （7天以上冷数据）vs SLS Query 版

• 索引比例 100%，ES 为 0 副本

每天写入量	保存天数	计算需要机器数	需要存储空间(TB)	机器费用	存储费用	ELK 费用	SLS费用	SLS/自建
10	30	15.15	96.25(热) + 316.25(冷)	¥33454.55	¥162624	¥196078.55	¥158,154	0.80
10	90	15.15	96.25(热) + 1141.25(冷)	¥33454.55	¥458304	¥491758.55	¥287,147	0.53
10	180	15.15	96.25(热) + 2378.75(冷)	¥33454.55	¥901824	¥935278.55	¥443,773	0.44

开源 ELK 运维工作项解析

要维护一个处于较为良好运行状态下的 ELK 集群，仅简单的维持系统的正常运作是并不够的。还需要从容量规划，稳定性保障，性能调优，数据高可用，数据如何在不同系统间关联等多个方面下功夫。

运维工作项	详细内容
容量规划	原始数据 * 膨胀系数 *（1 + 副本数) * (1 + 预留空间)， 一般膨胀系数取 1.1~ 1.3， 1 个副本，25% 的预留（剩余空间，临时文件等）， 实际磁盘空间最终是原始空间的 2.75~3.5 倍。如果需要开启_all 参数设置的话，数据膨胀会更严重，也需要预留更多空间。自建 ES 集群在维护过程中需要持续关注水位，在必要时进行扩容。
冷热分离	所有数据全部保留到 SSD 上成本会过高，需要根据数据的重要程度和时间因素，可以将部分 Index 直接保存至 HDD 磁盘，或使用 Rollover 功能将 Index 迁移
Index 设置	每个应用的 2 类日志，分别按照时间周期性创建 Index，根据数据大小合理设置 shard 数，单 shard 以 30~50GB 为宜，但是各应用的日志量很难准确估计，常在遇到写入或查询问题后再调整，然而 reindex 的消耗又非常大
ES 参数调优	需要对写入吞吐，可见性延时，数据安全性，以及查询性能等多方面因素进行综合评估和权衡后，结合集群 CPU、内存，对ES一些列参数进行调优，才能更好发挥 ES 的特性，常见的参数包括线程数、内存控制、translog 设置、队列长度、各类操作间隔 interval、merge 参数等
内存问题	通常 JVM 堆内存大小在 32GB 以内，剩余的留个 OS 缓存使用，如果频繁gc会严重影响性能，甚至直接导致服务不可用。 master 节点内存占用和集群中shard数直接相关，一般集群shard需要控制在 10W 以内，ES 默认配置中，单节点 shard 数上限为 1000，需要合理控制 index 和 shard 数量
查询问题	影响查询性能的因素非常多，需要花费大量时间不断试错和积累，常见的如：•合理设置 mapping，如 text 和 keyword 的选择，尽量避免无必要的 nested mapping•避免过大的查询范围和复杂度（过深的 group by 等），以免急剧消耗系统资源；对结果集大小进行限制，否则复杂的聚合查询或模糊查询等，在过大数据集上甚至直接导致 oom
数据损坏	如果遇到异常的 crash 或者磁盘损坏（es 的坏盘容忍度低），可能导致文件损坏，在 segment 或 translog 文件受损时，shard 可能无法加载，需要使用工具或手动将有问题的数据清理掉，但这也会导致部分数据丢失
版本管理	当社区版本存在一些功能性或者安全方面的问题时，需要对于部署版本进行版本升级，而版本升级本身的风险性高。
问题 support	ES 出问题需要求助开源社区，并且由团队自身自行兜底

SLS 和开源 ELK 资源工作项对比

类别	对比项	日志服务SLS	开源ELK
监控规模	监控日志/时序规模	PB 级别	TB级别
协同监控	多存储单元关联监控（如索引/库）	支持（SQL Join、告警集合操作扩展）	仅支持同一结构多索引合并分析，不支持JOIN
关联日志与时序监控	支持（SQL Join、告警集合操作扩展）	不支持
跨存储容器监控（如集群/项目）	支持	不支持
跨区域监控	支持	不支持
降噪控制	连续同一警报去重	时间窗口内，同一告警去重或延迟发送（基于标签）	不支持
多种警报归类合并	时间窗口内，将各类警报合并分组发送（基于包括标签的任意属性归类）	不支持
警报等级抑制/压制	特定源警报可抑制特定目标告警（源和目标可基于包括标签的任意属性匹配）	不支持
警报静默	静默特定时间（基于包括标签的主要属性）	不支持
通知管理	动态分派通知渠道	基于警报的任意属性匹配，可动态分派任意渠道和任意人/组/值班组	不支持
告警提升	基于警报的任意属性匹配，长时间未确认/未解决可升级到任意渠道以及相关人/组/值班组	不支持
用户/用户组/值班组管理	支持	不支持
通知渠道	短信/语音/邮件/webhook/钉钉/微信/飞书等	短信语音需与第三方集成

自建 ELK 方案复杂，构建完整可观测分析平台需组合多款服务

SLS 支持一站式数据平台能力，完整支持了运维和 SRE 工作中对于监控分析平台的需求。同时如数据加工、告警等增值功能均支持按实际使用量付费，无额外功能预留成本。

ES 为主流的日志分析开源方案，但是如果要构建一套完整的可观测分析平台。还需要组合多款服务，这其中包括Logstash、Kibana、Kafka、Flink、TSDB、Prometheus 等服务。

对比项	SLS Standard 规格	SLS Query 规格	开源 ELK
服务保证	全托管免运维，具备可靠的SLA保证	ELK 依赖用户自运维保障稳定性
数据采集	支持 Logtail，SDK 等多种采集方式，支持 PB 级数据写入能力	依赖 Beats 套组进行采集。在大数据量场景，需要依赖 Kafka 实现写入缓存，防止 es 写入性能超限进而导致数据丢失。
数据存储	原生支持 Log/Trace/Metric 存储	默认支持 Log 存储，Trace/Metric 属于 X-Pack 组件需单独付费。业内 Metric 数据主流方案是使用时序数据库如 Influxdb、TSDB 存储
查询检索	支持	支持
分析（SQL 分析）	支持	不支持（依赖 Scan 支持）	支持
Scan（无索引分析）	支持	不支持
告警	支持，提供多种智能降噪方案，可有效实现报警降噪。	部分支持（不支持带SQL 监控）	主要依赖 Kibana Alerting 属于 X-Pack 组件，需单独付费。Kibana Alerting 不具备告警降噪功能
加工-行处理（流式加工）	原生支持	ELK 的 Logstash filter 组件在写入时加工，无法保证数据完整性，主流方案是依赖 Kafka+Flink 或者 flume 完成数据清洗之后再写入 Kafka
Scheduled-SQL（批处理加工）	原生支持	不支持	支持（rollup、transforms）
可视化	原生支持	不支持	依赖 Kibana 组件实现可视化能力
导出/消费	原生支持	无法对写入的日志进行实时消费，一般要配一个 kafka 开源系统进行搭配（增加额外成本）

自建 ELK 数据孤岛、算法有限、告警低效

可观测数据平台：开源 ELK 方案相比 SLS 存在数据孤岛现象

• SLS 可观测数据统一存储支持 log metric trace 数据存储，打通数据孤岛。

算法支持：传统开源 ELK 方案比 SLS支持更有限的聚合算法

• SLS 针对数据分析场景支持 30+ 聚合计算函数，丰富的机器学习函数以及多渠道数据源。ELK 仅支持指标分析聚合、分桶聚合、管道分析、矩阵分析有限的聚合算法。

告警能力：传统开源 ELK 比 SLS 的告警能力更低效

• SLS 相比 ELK 提供全面监控、智能降噪和多为分析的能力。开源 ELK 仅支持同一结构多索引合并分析有限的告警能力。

类别	对比项	日志服务SLS	开源ELK
监控规模	监控日志/时序规模	PB 级别	TB 级别
协同监控	多存储单元关联监控（如索引/库）	支持（SQL Join、告警集合操作扩展）	仅支持同一结构多索引合并分析，不支持 JOIN
关联日志与时序监控	支持（SQL Join、告警集合操作扩展）	不支持
跨存储容器监控（如集群/项目）	支持	不支持
跨区域监控	支持	不支持
降噪控制	连续同一警报去重	时间窗口内，同一告警去重或延迟发送（基于标签）	不支持
多种警报归类合并	时间窗口内，将各类警报合并分组发送（基于包括标签的任意属性归类）	不支持
警报等级抑制/压制	特定源警报可抑制特定目标告警（源和目标可基于包括标签的任意属性匹配）	不支持
警报静默	静默特定时间（基于包括标签的主要属性）	不支持
通知管理	动态分派通知渠道	基于警报的任意属性匹配，可动态分派任意渠道和任意人/组/值班组	不支持
告警提升	基于警报的任意属性匹配，长时间未确认/未解决可升级到任意渠道以及相关人/组/值班组	不支持
用户/用户组/值班组管理	支持	不支持
通知渠道	短信/语音/邮件/webhook/钉钉/微信/飞书等	短信语音需与第三方集成

小结

ElasticSearch 基于 Lucene 全文索引实现，面向 Document 类型，构建一套完整的可观测分析平台需要组合多款服务，这其中包括 logstash、Kibana、Kafka、Flink、TSDB、Prometheus 等服务，对于规模、查询能力等方面存在一定限制，整体成本较高。

日志服务 SLS 基于阿里云自研灵活索引，支持一站式云原生可观测性，多规格多场景支持，SLS 十亿级别数据查询和分析场景性能高达 ES 的 10 倍，综合成本是 ES 的 44%。

原文链接

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