日志分析：SLS vs ELK

背景

提到日志实时分析，大部分人第一想到是社区很火ELK Stack（Elastic/Logstash/Kibana）。ELK方案上手难度小、开源材料众多、在社区中有大量的使用案例。
阿里云日志服务(SLS/Log) 是阿里巴巴集团对日志场景的解决方案产品，前身是2012年初阿里云在研发飞天操作系统过程中用来监控+问题诊断的产物，但随着用户增长与产品发展，慢慢开始向面向Ops(DevOps，Market Ops，SecOps)日志分析领域发展（见下图），期间经历双十一、蚂蚁双十二、新春红包、国际业务等场景挑战，成为同时服务内外的产品。

面向日志分析场景

搞搜索都知道Apache Lucene（Lucene是Doug Cutting 2001年贡献，Doug也是Hadoop创始人）。2012年Elastic把Lucene基础库包成了一个更好用的软件，并且在2015年推出ELK Stack（Elastic Logstash Kibana）解决集中式日志采集、存储和查询问题。Lucene设计场景是Information Retrial，面对是Document类型，因此对于Log这种数据有一定限制，例如规模、查询能力、以及一些定制化功能（例如智能聚类LogReduce）等。

SLS提供日志存储引擎是阿里内部自研究技术，经过3年W级应用锤炼，每日索引数据量达PB级，服务万级开发者每天亿次查询分析。在阿里集团内阿里云全站，SQL审计、鹰眼、蚂蚁云图、飞猪Tracing、阿里云谛听等都选择SLS作为日志分析引擎。

而日志查询是DevOps最基础需求，从业界的调研《50 Most Frequently Used Unix Command》也验证了这一点，排名第一的是tar、第二的就Grep这个命令了，由此可见他对程序员的重要性。
我们在日志查询分析场景上以如下点对ELK 与 SLS 做一个全方位比较：

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

利益关系：本人SLS研发可能带一些主观色彩， 但一切都以技术指标来对比，如有偏颇请不吝指正

易用性

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

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

以下是比较结果：

整体而言：

• ELK 有非常多生态和写入工具，使用中的安装、配置等都有较多工具可以参考
• SLS 是托管服务，从接入、配置、使用上集成度非常高，普通用户5分钟就可以接入，但在生态与丰富度和ELK相比有较大差距
• SLS 是SaaS化服务，在过程中不需要担心容量、并发等问题，弹性伸缩，免运维

功能（查询+分析）

查询主要将符合条件的日志快速命中，分析功能是对数据进行统计与计算。例如我们有如下需求：所有大于200读请求，根据Ip统计次数和流量，这样的分析请求就可以转化为两个操作：查询到指定结果，对结果进行统计分析。在一些情况下我们也可以不进行查询，直接对所有日志进行分析。

Query1:
Status in (200,500] and Method:Get* 

Query2:
select count(1) as c, sum(inflow) as sum_inflow, ip group by Ip

查询基础对比

参考：Elastic 6.5 Indices

对比结论

• ES 支持数据类型丰富度，原生查询能力比SLS更完整
• SLS​ 能够通过SQL方式（如下）来代替字符串模糊查询，Geo等比较函数，但性能会比原生查询稍差

子串命中
* | select content where content like '%substring%' limit 100

正则表达式匹配
* | select content where regexp_like(content, '\d+m'）limit 100

JSON内容解析与匹配
* | select content where json_extract(content, '$.store.book')='mybook' limit 100
如果设置json类型索引也可以使用：
field.store.book='mybook'

查询扩展能力

在日志分析场景中，光有检索可能还不够，需要能够围绕查询做进一步的工作：

1. 定位到错误日志后，想看看上下文是什么参数引起了错误
2. 定位到错误后，想看看之后有没有类似错误，类似tail -f 原始日志文件，并进行grep
3. 通过关键词搜索到一大堆日志（例如百万条），其中90%都是已知问题刚干扰调查线索

SLS 针对以上问题提供闭环解决方案：

• 上下文查询（Context Lookup）：原始上下文翻页，免登服务器
• LiveTail功能（Tail-f）：原始上下文tail-f，更新实时情况
• 智能聚类（LogReduce）：根据日志Pattern动态归类，合并重复模式，洞察异常

查询扩展能力（1）：LiveTail（云端 tail -f)

在传统的运维方式中，如果需要对日志文件进行实时监控，需要到服务器上对日志文件执行命令tail -f，如果实时监控的日志信息不够直观，可以加上grep或者grep -v进行关键词过滤。SLS在控制台提供了日志数据实时监控的交互功能LiveTail，针对线上日志进行实时监控分析，减轻运维压力。

Livetail特点如下：

• 智能支持Docker、K8S、服务器、Log4J Appender等来源数据
• 监控日志的实时信息，标记并过滤关键词
• 日志字段做分词处理，以便查询包含分词的上下文日志

具体使用场景参见文档：https://help.aliyun.com/document_detail/93633.html

查询扩展能力（2）：智能聚类（LogReduce）

业务的高速发展，对系统稳定性提出了更高的要求，各个系统每天产生大量的日志，你是否曾担心过：

• 系统有潜在异常，但被淹没在海量日志中
• 机器被入侵，有异常登录，却后知后觉
• 新版本上线，系统行为有变化，却无法感知
  这些问题，归根到底，是信息太多、太杂，不能良好归类，同时记录信息的日志，往往还都是无Schema，格式多样，归类难道更大。SLS提供实时日志智能聚类(LogReduce)功能根据日志的相似性进行归类，快速掌握日志全貌：
• 支持任意格式日志：Log4J、Json、单行（syslog）
• 日志经任意条件过滤后再Reduce；对Reduce后Pattern，根据signature反查原始数据
• 不同时间段Pattern比较
• 动态调整Reduce精度
• 亿级数据，秒级出结果

文档：

• 说明：https://yq.aliyun.com/articles/679078
• 文档：https://help.aliyun.com/document_detail/100039.html

分析能力对比

ES在docvalue之上提供一层聚合（Aggregation）语法，并且在6.x版本中提供SQL语法能够对数据进行分组聚合运算。
SLS支持完整SQL92标准（提供restful 和 jdbc两种协议），除基本聚合功能外，支持完整的SQL计算，并支持外部数据源联合查询（Join），机器学习，模式分析等函数。

参考：ES 6.5 Aggregation，SLS 分析语法

除SQL92标准语法外，我们根据实际日志分析需求，研发一系列实用的功能：

分析功能演示（1）：同比、环比函数

同比环比函数能够通过SQL嵌套对任意计算（单值、多值、曲线）计算同环比（任意时段），以便洞察增长趋势。

* | select compare( pv , 86400) from (select count(1) as pv from log)

*|select t, diff[1] as current, diff[2] as yestoday, diff[3] as percentage from(select t, compare( pv , 86400) as diff from (select count(1) as pv, date_format(from_unixtime(__time__), '%H:%i') as t from log group by t) group by t order by t) s

文档：https://help.aliyun.com/document_detail/86661.html

分析功能演示（2）：外部数据源联合查询（Join）

可以在查询分析中关联外部数

• 支持logstore，MySQL，OSS（CSV）等数据源
• 支持left，right，out，innerjoin
• SQL查询外表，SQLJoin外表

Join外表的样例：

sql
创建外表：
* | create table user_meta ( userid bigint, nick varchar, gender varchar, province varchar, gender varchar,age bigint) with ( endpoint='oss-cn-hangzhou.aliyuncs.com',accessid='LTA288',accesskey ='EjsowA',bucket='testossconnector',objects=ARRAY['user.csv'],type='oss')

使用外表
* | select u.gender, count(1) from chiji_accesslog l join user_meta1 u on l.userid = u.userid group by u.gender

云栖：https://yq.aliyun.com/articles/613365
文档：https://help.aliyun.com/document_detail/70479.html

分析功能演示（3）：地理位置函数

针对IP地址、手机等内容，内置地理位置函数方便分析用户来源，包括：

• IP：国家、省市、城市、经纬度、运营商
• Mobile：运营商、省市
• GeoHash：Geo位置与坐标转换

查询结果分析样例：

sql
* | SELECT count(1) as pv, ip_to_province(ip) as province WHERE ip_to_domain(ip) != 'intranet' GROUP BY province ORDER BY pv desc limit 10

* | SELECT mobile_city(try_cast("mobile" as bigint)) as "城市", mobile_province(try_cast("mobile" as bigint)) as "省份", count(1) as "请求次数" group by "省份", "城市" order by "请求次数" desc limit 100 

查询结果：

GeoHash：https://help.aliyun.com/document_detail/84374.html
IP函数：https://help.aliyun.com/document_detail/63458.html
电话号码：https://help.aliyun.com/document_detail/98580.html

分析功能演示（4）：安全分析函数

依托全球白帽子共享安全资产库，提供安全检测函数，您只需要将日志中任意的IP、域名或者URL传给安全检测函数，即可检测是否安全。

• security_check_ip
• security_check_domain
• security_check_url

文档: https://help.aliyun.com/document_detail/87093.html

分析功能演示（5）：机器学习与时序检测函数

新增机器学习与智能诊断系列函数：
1）根据历史自动学习其中规律，并对未来的走势做出预测；
2）实时发现不易察觉的异常变化，并通过分析函数组合推理导致异常的特征；
3）结合环比、告警功能智能发现/巡检。该功能适用在智能运维、安全、运营等领域，帮助更快、更有效、更智能洞察数据。
提供的功能有：

• 预测：根据历史数据拟合基线
• 异常检测、变点检测、折点检测：找到异常点
• 多周期检测：发现数据访问中的周期规律
• 时序聚类：找到形态不一样的时序

文档： https://help.aliyun.com/document_detail/93024.html
云栖：https://yq.aliyun.com/articles/670718

分析功能演示（6）：模式分析函数

模式分析函数能够洞察数据中的特征与规律，帮助快速、准确推断问题：

1. 定位频繁集
   例如：错误请求中90%由某个用户ID构成

2. 定位两个集合中最大支持因素，例如：

   • 延时>10S请求中某个ID构成比例远远大于其他维度组合
   • 并且该ID在对比集合（B）中的比例较低
   • A和B中差异明显

性能

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

实验环境

1. 测试配置

1. 测试数据

   • 5列double，5列long，5列text，字典大小分别是256，512，768，1024，1280
   • 以上字段完全随机（测试日志样例如下）
   • 原始数据大小：50 GB
   • 日志行数：162,640,232 (约为1.6亿条)

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

写入测试结果

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

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

从测试结果来看

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

读取（查询+分析）测试

测试场景

选取两种比较常见的场景：日志查询和聚合计算。分别统计并发度为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. 规模能力

1. SLS可以处理PB/Day级数据，一次查询可以在秒级过TB规模数据，在数据规模上可以做到弹性伸缩与水平扩展

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

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

1.1 用户案例（规模带来的问题）

客户A是国内最大资讯类网站之一，有数千台机器与百号开发人员。运维团队原先负责一套ELK集群用来处理Nginx日志，但始终处于无法大规模使用状态：

1. 一个大Query容易把集群打爆，导致其他用户无法使用
2. 在业务高峰期间，采集与处理能力打满集群，造成数据丢失，查询结果不准确
3. 业务增长到一定规模，因内存设置、心跳同步等节点经常内存失控导致OOM
   不能保证可用性与准确性，开发最终没有使用起来，成为一个摆设。

在2018年6月份，运维团队开始运行SLS方案：

1. 使用Logtail来采集线上日志，将采集配置，机器管理等通过API集成进客户自己运维与管控系统
2. 将SLS查询页面嵌入统一登录与运维平台，进行业务与账户权限隔离
3. 通过控制台内嵌方案满足开发查询日志需求，通过Grafana插件调用SLS统一业务监控，通过DataV连接SLS进行大盘搭建

控制台嵌入方案：https://help.aliyun.com/document_detail/74971.html
接入Grafana：https://help.aliyun.com/document_detail/60952.html
接入DataV：https://help.aliyun.com/document_detail/62961.html
对接Jaeger：https://help.aliyun.com/document_detail/68035.html

整体架构如下图：

平台上线2个月后：

1. 每天查询的调用量大幅上升，开发逐步开始习惯在运维平台进行日志查询与分析，提升了研发的效率，运维部门也回收了线上登录的权限
2. 除Nginx日志外，把App日志、移动端日志、容器日志也进行接入，规模是之前10倍
3. 除查询日志外，也衍生出很多新的玩法，例如通过Jaeger插件与控制台基于日志搭建了Trace系统，将线上错误配置成每天的告警与报表进行巡检
4. 通过统一日志接入管理，规范了各平台对接总线，不再有一份数据同时被采集多次的情况，大数据部门Spark、Flink等平台可以直接去订阅实时日志数据进行处理

2. 成本估计

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

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

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

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

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

3. 时间成本（Time to Value）

除硬件成本外，SLS在新数据接入、搭建新业务、维护与资源扩容成本基本为0：

1. 支持各种日志处理生态，可以和Spark、Hadoop、Flink、Grafana等系统无缝对接
2. 在全球化部署（有20+ Region），方便拓展全球化业务
3. 提供30+日志接入SDK，与阿里云产品无缝打通集成

SLS采集和可视化可以参见如下文章，非核心功能不展开做比较

• 采集：https://yq.aliyun.com/articles/672576
• 可视化：https://yq.aliyun.com/articles/670942

写在最后

ES是一把锋利的军刀，支撑更新、查询、删除等更通用场景，在搜索、数据分析、应用开发等领域有广泛使用，ELK组合在日志分析场景上把ES灵活性与性能发挥到极致；SLS是纯定位在日志类数据分析场景的服务，在该领域内做了很多定制化开发。一个服务更广，一个场景更专。当然离开了场景纯数字的比较没有意义，找到适合自己场景的才重要。

• 日志服务（SLS）：https://www.aliyun.com/product/sls
• 用户手册：https://promotion.aliyun.com/ntms/act/logdoclist.html