提到日志实时分析,大部分人第一想到是社区很火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研发可能带一些主观色彩, 但一切都以技术指标来对比,如有偏颇请不吝指正
对日志分析系统而言,有如下使用过程:
以下是比较结果:
采集
|
协议
|
|
|
客户端
|
|
|
|
配置
|
单元
|
|
|
属性
|
|
|
|
扩容
|
存储
|
|
|
计算
|
|
|
|
配置
|
|
|
|
采集点
|
|
|
|
容量
|
|
|
|
导出
|
方式
|
|
|
多租户
|
安全
|
|
|
流控
|
|
|
|
多租户
|
|
|
整体而言:
查询主要将符合条件的日志快速命中,分析功能是对数据进行统计与计算。例如我们有如下需求:所有大于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支持 |
对比结论
子串命中
* | 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'
在日志分析场景中,光有检索可能还不够,需要能够围绕查询做进一步的工作:
SLS 针对以上问题提供闭环解决方案:
在传统的运维方式中,如果需要对日志文件进行实时监控,需要到服务器上对日志文件执行命令tail -f
,如果实时监控的日志信息不够直观,可以加上grep
或者grep -v
进行关键词过滤。SLS在控制台提供了日志数据实时监控的交互功能LiveTail,针对线上日志进行实时监控分析,减轻运维压力。
Livetail特点如下:
具体使用场景参见文档:https://help.aliyun.com/document_detail/93633.html
业务的高速发展,对系统稳定性提出了更高的要求,各个系统每天产生大量的日志,你是否曾担心过:
文档:
ES在docvalue之上提供一层聚合(Aggregation)语法,并且在6.x版本中提供SQL语法能够对数据进行分组聚合运算。
SLS支持完整SQL92标准(提供restful 和 jdbc两种协议),除基本聚合功能外,支持完整的SQL计算,并支持外部数据源联合查询(Join),机器学习,模式分析等函数。
参考:ES 6.5 Aggregation,SLS 分析语法
除SQL92标准语法外,我们根据实际日志分析需求,研发一系列实用的功能:
同比环比函数能够通过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
可以在查询分析中关联外部数
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
针对IP地址、手机等内容,内置地理位置函数方便分析用户来源,包括:
查询结果分析样例:
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
依托全球白帽子共享安全资产库,提供安全检测函数,您只需要将日志中任意的IP、域名或者URL传给安全检测函数,即可检测是否安全。
文档: https://help.aliyun.com/document_detail/87093.html
新增机器学习与智能诊断系列函数:
1)根据历史自动学习其中规律,并对未来的走势做出预测;
2)实时发现不易察觉的异常变化,并通过分析函数组合推理导致异常的特征;
3)结合环比、告警功能智能发现/巡检。该功能适用在智能运维、安全、运营等领域,帮助更快、更有效、更智能洞察数据。
提供的功能有:
文档: https://help.aliyun.com/document_detail/93024.html
云栖:https://yq.aliyun.com/articles/670718
模式分析函数能够洞察数据中的特征与规律,帮助快速、准确推断问题:
定位两个集合中最大支持因素,例如:
接下来我们测试针对相同数据集,分别对比写入数据及查询,和聚合计算能力。
自建ELK | LogSearch/LogAnalytics | |
---|---|---|
环境 | ECS 4核16GB * 4台 + 高效云盘 SSD | |
Shard | 10 | 10 |
拷贝数 | 2 | 3 (默认配置,对用户不可见) |
测试数据
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 产生计费的存储量包括压缩的原始数据写入量(23G)+索引流量(27G),共50G存储费用。
从测试结果来看
选取两种比较常见的场景:日志查询和聚合计算。分别统计并发度为1,5,10时,两种case的平均延时。
针对全量数据,对任意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
针对全量数据,随机查询日志中的关键词,例如查询 "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 |
ES比较适合服务场景为:写入GB-TB/Day、存储在TB级。主要受限于2个原因:
客户A是国内最大资讯类网站之一,有数千台机器与百号开发人员。运维团队原先负责一套ELK集群用来处理Nginx日志,但始终处于无法大规模使用状态:
在2018年6月份,运维团队开始运行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个月后:
以上述测试数据为例,一天写入50GB数据(其中27GB 为实际的内容),保存90天,平均一个月的耗费。
计费项目 | 值 | 单价 | 费用(元) |
---|---|---|---|
读写流量 | 23G * 30 | 0.2 元/GB | 138 |
存储空间(保存90天) | 50G * 90 | 0.3 元/GB*Month | 1350 |
索引流量 | 27G * 30 | 0.35 元/GB | 283 |
总计 | 1771 |
ES费用包括机器费用,及存储数据SSD云盘费用
计费项目 | 值 | 单价 | 费用(元) |
---|---|---|---|
服务器 | 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(SSD)费用比为 13.6%。在测试过程中,我们也尝试把SSD换成SATA以节省费用(SLS与SATA版费用比为 34%),但测试发现延时会从40ms上升至150ms,在长时间读写下,查询和读写延时变得很高,无法正常工作了。
除硬件成本外,SLS在新数据接入、搭建新业务、维护与资源扩容成本基本为0:
SLS采集和可视化可以参见如下文章,非核心功能不展开做比较
- 采集:https://yq.aliyun.com/articles/672576
- 可视化:https://yq.aliyun.com/articles/670942
ES是一把锋利的军刀,支撑更新、查询、删除等更通用场景,在搜索、数据分析、应用开发等领域有广泛使用,ELK组合在日志分析场景上把ES灵活性与性能发挥到极致;SLS是纯定位在日志类数据分析场景的服务,在该领域内做了很多定制化开发。一个服务更广,一个场景更专。当然离开了场景纯数字的比较没有意义,找到适合自己场景的才重要。