日志分析：SLS vs ELK

2021-10-14 06:18:47

背景

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

日志分析：SLS vs ELK

面向日志分析场景

搞搜索都知道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作为日志分析引擎。

日志分析：SLS vs ELK

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

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

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

易用性

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

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

以下是比较结果：

采集
协议
  • Restful API
  • Restful API
  • JDBC
客户端
  • Logstash/Beats/Fluentd
  • 生态十分丰富
  • Logtail（为主）
  • 其他Agent (例如Logstash，Beats)
配置
单元
  • 提供Index概念用以区分不同日志
  • Project + Logstore。提供两层概念，Project相当于命名空间，可以在Project下建立多个Logstore
属性
  • API
  • Kibana
  • API/SDK
  • 控制台
扩容
存储
  • 增加机器
  • 购买云盘
  • 无需操作
计算
  • 新增机器
  • 无需操作
配置
  • 通过配管系统应用机器
  • （Logstash在Beta版本中已经提供中心化配置功能）
  • 控制台/API 操作，无需配管系统
采集点
  • 通过配管系统应用机器
  • 控制台/API 操作，无需配管系统
容量
  • 不支持动态扩容
  • 动态扩容，弹性伸缩
导出
方式
  • API
  • SDK
  • API
  • SDK
  • 类Kafka接口消费
  • 各流计算引擎消费（Spark，Storm，Flink）
  • 流计算类库消费（Python、Java）
多租户
安全
  • 商业版
  • https
  • 传输签名
  • 多租户隔离
  • 访问控制
流控
  • 无
  • Project级
  • Shard级
多租户
  • Kibana支持
  • 原生提供账号与权限级管理

整体而言：

  • 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

类型 小项 ELK SLS
文本 索引查询 支持 支持
分词 支持 支持
中文分词 支持 支持
前缀 支持 支持
后缀 支持
模糊 支持 可通过SQL支持
Wildcast 支持 可通过SQL支持
数值 long 支持 支持
double 支持 支持
Nested Json 支持
Geo Geo 支持 可通过SQL支持
Ip Ip查询 支持 可通过SQL支持

对比结论

  • 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动态归类，合并重复模式，洞察异常

日志分析：SLS vs ELK

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

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

日志分析：SLS vs ELK

Livetail特点如下：

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

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

日志分析：SLS vs ELK

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

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

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

日志分析：SLS vs ELK

文档：

分析能力对比

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

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

日志分析：SLS vs ELK

除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

日志分析：SLS vs ELK

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

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

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

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

日志分析：SLS vs ELK

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

查询结果：

日志分析：SLS vs ELK

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

日志分析：SLS vs ELK

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

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

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

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

日志分析：SLS vs ELK

文档： 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中差异明显

日志分析：SLS vs ELK

性能

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

实验环境

  1. 测试配置
自建ELK LogSearch/LogAnalytics
环境 ECS 4核16GB * 4台 + 高效云盘 SSD
Shard 10 10
拷贝数 2 3 （默认配置，对用户不可见）

  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批量写入，结果如下：

类型 项目 自建ELK LogSearch/Analytics
延时 平均写入延时 40 ms 14 ms
存储 单拷贝数据量 86G 58G
膨胀率：数据量/原始数据大小 172% 121%

日志分析：SLS vs ELK

备注：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

测试结果

类型 并发数 ES延时(单位s) LogSearch/Analytics延时(单位s)
case1：分析类 1 3.76 3.4
5 3.9 4.7
10 6.6 7.2
case2：查询类 1 0.097 0.086
5 0.171 0.083
10 0.2 0.082

日志分析：SLS vs ELK

结果分析

  • 从结果看，对于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

整体架构如下图：

日志分析：SLS vs ELK

平台上线2个月后：

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

2. 成本估计

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

  1. 日志服务（LogSearch/LogAnalytics）计费规则参考，包括读写流量、索引流量、存储空间等计费项，查询功能免费。
计费项目 值 单价 费用(元)
读写流量 23G * 30 0.2 元/GB 138
存储空间（保存90天） 50G * 90 0.3 元/GB*Month 1350
索引流量 27G * 30 0.35 元/GB 283
总计 1771

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

    • 云盘一般可以提供高可靠性，因此我们这里不计费副本存储量
    • 存储盘一般需要预留15%剩余空间，以防空间写满，因此乘以一个1.15系数
计费项目 值 单价 费用(元）
服务器 4台4核16G(三个月)(ecs.mn4.xlarge) 包年包月费用：675 元/Month 2021
存储 86 * 1.15 * 90 （这里只计算一个副本） SSD：1 元/GB*M 8901
SATA：0.35 元/GB*M 3115
总计 12943 (SSD)
5135 (SATA)

日志分析：SLS vs ELK

同样性能，使用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采集和可视化可以参见如下文章，非核心功能不展开做比较

日志分析：SLS vs ELK

写在最后

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

上一篇：虚拟机NAT的配置


下一篇：【功能发布】日志服务（SLS）11-12月功能合集