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

概述

本文详细阐述了阿里云日志服务 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 副本

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

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

开源 ELK 运维工作项解析

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

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

3. 易用性（构建完整可观测分析平台需组合多款服务）

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

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

4. 数据互联互通与开发（数据集成、算法增强、告警加持）

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

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

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

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

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

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

小结

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

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

如需了解从ES平滑迁移到SLS 攻略，请参考文章链接https://developer.aliyun.com/article/1412611