概述
本文详细阐述了阿里云日志服务 SLS 和开源 ELK 在性能、成本、功能等维度的对比分析。
在日志存储与查询场景中，ElasticSearch（ES）是使用最多的方案。ES 的第一个版本在2010年发布，在 2015 年 ELK Stack（Elastic Logstash Kibana）推出的套件解决集中式日志采集、存储和查询问题。由于 ES 内核是基于 Lucene 实现的，因此对较短的日志场景仍有一定的发展空间：例如对于可观测数据（Log/Trace/Metric）的兼容性，大规模能力，查询稳定性，及场景需要的一些差异化功能（例如智能聚类 LogReduce、上下文查询、日志订阅等）。
阿里云日志服务 SLS 基于一套面向可观测数据采集、存储、分析场景设计的产品。面向 Log/Metric/Trace 等数据提供大规模、低成本、实时平台化服务。一站式提供数据采集、加工、分析、告警可视化与投递功能，全面提升研发、运维、运营和安全等场景数字化能力。
为了能够在日志存储查询场景上有一个直观地了解（非ES通用场景），我们在以下方面做了一定的对比：
- 性能：在同样成本的介质上部署，SLS 能够提供更低的延时、以及更稳定的查询性能。
- 成本：这里的成本不光是部署成本，还需要包括使用成本。要维护良好状态的 ELK 集群，需要从容量规划、稳定性保障、性能调优、数据高可用，数据如何在不同系统间关联等多个方面下功夫。SLS 全托管免运维无需花费额外人力投入。百 TB 规模下，SLS 综合成本是 ELK 的 44%。
- 易用性：SLS 对开源协议及组件相比 ELK 有更好的兼容性。利用 ELK 构建完整可观测分析平台需组合多款服务，这其中包括Logstash、Kibana、Kafka、Flink、TSDB、Prometheus等。SLS 在这个场景上无需多个组件搭配，支持一站式数据监控分析平台能力。
- 互联互通与二次开发：在可观测场景中，我们需要跨多个数据源进行关联分析。SLS 可观测数据统一存储支持 log metric trace 数据存储，打通数据孤岛，并且提供开源友好的 API 接口进行使用。
- 附加能力（新算子、告警等）：开源 ELK 仅支持指标分析聚合、分桶聚合、管道分析、矩阵分析有限的聚合算法。SLS 针对数据分析场景支持 30+ 聚合计算函数，丰富的机器学习函数以及多渠道数据源，是 ELK 提供操作符的 5 倍，充分发掘数据分析能力。除此之外，SLS 内置告警功能可以快速开箱即用，无需搭建系统。
1. 性能比较（查询+分析场景）
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
2. 成本比较（综合使用成本：包括服务器、运维难度、人力在内的综合成本）
百 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/钉钉/微信/飞书等 |
短信语音需与第三方集成 |
3. 易用性（构建完整可观测分析平台需组合多款服务）
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 开源系统进行搭配（增加额外成本） |
|
4. 数据互联互通与开发（数据集成、算法增强、告警加持）
可观测数据平台：开源 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%。
如需了解从ES平滑迁移到SLS 攻略，请参考文章链接/article/1412611
