自建ELK vs 日志服务(SLS)全方位对比

简介

提到日志实时分析，很多人都会想到很火的ELK Stack（Elastic/Logstash/Kibana）来搭建。ELK方案开源，在社区中有大量的内容和使用案例。

阿里云日志服务产品在新版中增强查询分析功能（LogSearch/Analytics），支持对日志数据实时索引与查询分析，并且对查询性能和计算数据量做了大量优化。在这里我们做一个全方位的比较，对于用户关心的点，我们依次展开分析：

• 易用：上手及使用过程中的代价
• 功能（重点）：主要针对查询与分析两块
• 性能（重点）：对于单位大小数据量查询与分析需求，延时如何
• 规模（重点）：能够承担的数据量，扩展性等
• 成本（重点）：同样功能和性能，使用分别花多少钱

易用

对日志分析系统而言，有如下使用过程：

1. 采集：将数据稳定写入
2. 配置：如何配置数据源
3. 扩容：接入更多数据源，更多机器，对存储空间，机器进行扩容
4. 使用：这部分在功能这一节介绍
5. 导出：数据能否方便导出到其他系统，例如做流计算、放到对象存储中进行备份
6. 多租户：如何将数据能否分享给他人使用，使用是否安全等

以下是比较结果：

总体而言：

ELK 有非常多的生态和写入工具，使用中的安装、配置等都有较多工具可以参考。LogSearch/Anlaytics是一个托管服务，从接入、配置、使用上集成度非常高，普通用户5分钟就可以接入。并且过程中不需要担心容量、并发等问题，按量计费，弹性伸缩。

功能（查询+分析）

查询主要将符合条件的日志快速命中，分析功能是对数据进行统计与计算。

例如我们有如下需求：所有大于200读请求，根据Ip统计次数和流量，这样的分析请求就可以转化为两个操作：查询到指定结果，对结果进行统计分析。在一些情况下我们也可以不进行查询，直接对所有日志进行分析。

1: Status in (200,500] and Method:Get* 
2: select count(1) as c, sum(inflow) as sum_inflow, ip group by Ip

查询能力对比

ElasticSearch 支持的数据类型，以及查询方式上要更强。Log-Search/Analytics 支持大部分常用查询，也有一些特色（例如程序日志上下文查询与展开）。

分析能力对比

• ES 5.5 Aggregation
• Log-Search/Analytics分析语法

从结果看Log-Search/Analytics 提供的功能是ES 超集，完整支持SQL 92 语义，只要会写SQL 都能直接使用。

性能

接下来我们测试针对相同数据集，分别对比写入数据及查询，和聚合计算能力。

实验环境

1、 测试配置

2、测试数据

• 5列double
• 5列long
• 5列text，字典大小分别是256，512，768，1024，1280

• 以上字段完全随机，如下为一条测试日志样例：

  timestamp:August 27th 2017, 21:50:19.000 
  long_1:756,444 double_1:0 text_1:value_136 
  long_2:-3,839,872,295 double_2:-11.13 text_2:value_475 
  long_3:-73,775,372,011,896 double_3:-70,220.163 text_3:value_3 
  long_4:173,468,492,344,196 double_4:35,123.978 text_4:value_124 
  long_5:389,467,512,234,496 double_5:-20,10.312 text_5:value_1125

3、 数据集大小

• 原始数据大小：50 GB
• 原始数据除去Key后内容大小：27 GB（LogSearch/Analytics 以该大小作为存储计费单元）
• 日志行数：162,640,232 (约为1.6亿条)

写入测试结果

ES采用bulk api批量写入，LogSearch/Analytics 用PostLogstoreLogs API批量写入，结果如下：

备注：LogSearch/Analytics 产生计费的存储量包括压缩的原始数据写入量(23G)+索引流量(27G)，共50G存储费用。

从测试结果来看

• LogSearch/Analytics写入延时好于ES，40ms vs 14 ms
• 空间：原始数据50G，因测试数据比较随机所以存储空间会有膨胀（大部分真实场景下，存储会因压缩后会比原始数据小）。ES胀到86G，膨胀率为172%，在存储空间超出LogSearch/Analytics 58%

读取（查询+分析）测试

测试场景

我们在此选取两种比较常见的场景：日志查询和聚合计算。分别统计并发度为1，5，10时，两种case的平均延时。

1. 针对全量数据，对任意text列计算group by，计算5列数值的avg/min/max/sum/count，并按照count排序，取前1000个结果，例如：

   select count(long_1) as pv,sum(long_2),min(long_3),max(long_4),sum(long_5) 
   group by text_1 order by pv desc limit 1000

2. 针对全量数据，随机查询日志中的关键词，例如查询 "value_126"，获取命中的日志数目与前100行，例如：

   value_126

测试结果

结果分析

• 从结果看，对于1.5亿数据量这个规模，两者都达到了秒级查询与分析能力
• 针对统计类场景（case 1）， ES和日志服务延时处同一量级。ES采用SSD硬盘，在读取大量数据时IO优势比较高
• 针对查询类场景（case 2）， LogAnalytics在延时明显优于ES。随着并发的增加，ELK延时对应增加，而LogAnalytics延时保持稳定甚至略有下降

规模

1. LogSearch/Analytics 一天可以索引PB级数据，一次查询可以在秒级过几十TB规模数据，在数据规模上可以做到弹性伸缩与水平扩展

2. ES比较适合服务场景为：写入GB-TB/Day、存储在TB级。主要受限于2个原因：

   • 单集群规模：比较理想为20台左右，业界比较大的为100节点一个集群
   • 写入扩容：shard创建后便不可再修改，当吞吐率增加时，需要动态扩容节点，最多可使用的节点数便是shard的个数
   • 存储扩容：主shard达到磁盘的上线时，要么迁移到更大的一块磁盘上，要么只能分配更多的shard。一般做法是创建一个新的索引，指定更多shard，并且rebuild旧的数据

   LogSearch/Analytics 则没有扩展性方面的问题，每个shard都是分布式存储。并且当吞吐率增加时，可以动态分裂shard，达到处理能力水平扩展。

成本

以上述测试数据为例，一天写入50GB数据（其中27GB 为实际的内容），保存90天，平均一个月的耗费。

1、 日志服务（LogSearch/LogAnalytics）计费规则参考文档，包括读写流量、索引流量、存储空间等计费项，查询功能免费。

2、 ES费用包括机器费用，及存储数据SSD云盘费用

• 云盘一般可以提供高可靠性，因此我们这里不计费副本存储量
• 存储盘一般需要预留15%剩余空间，以防空间写满，因此乘以一个1.15系数

​ 同样性能，使用LogSearch/Analytics与ELK（SSD）费用比为 13.6%。在测试过程中，我们也尝试把SSD换成SATA以节省费用（LogAnalytics与SATA版费用比为 34%），但测试发现延时会从40ms上升至150ms，在长时间读写下，查询和读写延时变得很高，无法正常工作了。

总结

​ LogSearch/Analytics在提供同样查询速度、更高吞吐量、更强分析能力背后，只需要开源方案13%成本（集团用户默认7折，计算后只有10%成本），并且按量付费免运维，让你把精力放在业务分析上。

​ 日志服务除了LogSearch/Analytics外，还提供LogHub、LogShipper功能，支持实时采集数据、与流计算系统（Spark、Storm、Flink、StreamCompute）、离线分析系统（MaxCompute、E-MapReduce、Presto、Hive等）打通，提供一站式实时数据解决方案。

线上数据演示

一天20亿条数据量进行查询与分析（2分钟）:

Dashboard功能演示视频（4分钟）：

除此之外，我们提供了三组测试数据供尝试：

• 试用链接1 访问日志数据介绍和使用样例
• 试用链接2 行车轨迹数据介绍和使用样例
• 试用链接3 账单日志数据介绍和使用样例

以下5个子帐号供试用，请随机选择一个登录，若登录不成功请换一个子帐号尝试：