通过将阿里云日志服务与ELK Stack进行全面对比,帮助您更好的了解阿里云日志服务的主要功能和优势。
背景信息
提到日志实时分析,很多人都会想到基于ELK Stack(Elastic/Logstash/Kibana)来搭建。ELK方案开源,在社区中有大量的内容和使用案例。
阿里云 日志服务 是阿里巴巴集团对日志场景的解决方案产品,前身是2012年初阿里云在研发飞天操作系统过程中用来监控+问题诊断的产物,但随着用户增长与产品发展,慢慢开始向面向Ops(DevOps,Market Ops,SecOps)日志分析领域发展,期间经历双十一、蚂蚁双十二、新春红包、国际业务等场景挑战,成为同时服务国内外的产品。
面向日志分析场景
Apache Lucene是Apache软件基金会一个开放源代码的全文检索引擎工具包,一个全文检索引擎的架构,提供了完整的查询引擎和索引引擎、部分文本分析引擎。2012年Elastic把Lucene基础库包成了一个更好用的软件,并且在2015年推出ELK Stack(Elastic Logstash Kibana)解决集中式日志采集、存储和查询问题。Lucene设计场景是Information Retrival,面对是Document类型,因此对于Log这种数据有一定限制,例如规模、查询能力、以及智能聚类LogReduce等定制化功能。
Log Service提供日志存储引擎是阿里内部自研究技术,经过3年万级应用锤炼,每日索引数据量达PB级,服务万级开发者每天亿次查询分析。在阿里集团内阿里云全站,SQL审计、鹰眼、蚂蚁云图、飞猪Tracing、阿里云谛听等都选择Log Service作为日志分析引擎。
而日志查询是DevOps最基础需求,业界的调研50 Most Frequently Used Unix Command也验证了这一点,tar排名第一、Grep排名第二,由此可见日志查询对程序员的重要性。
在日志查询分析场景,以如下点对ELK 与Log Service做一个全方位比较。
- 易用:上手和使用的便利程度。
- 功能:主要针对查询与分析。
- 性能:对于单位大小数据量查询与分析需求,延时如何。
- 规模:能够承担的数据量、扩展性等。
- 成本:同样功能和性能,使用分别花多少钱。
易用性
- 采集:将数据稳定写入。
- 配置:如何配置数据源。
- 扩容:接入更多数据源,更多机器,对存储空间,机器进行扩容。
- 使用:这部分在功能这一节介绍。
- 导出:数据能否方便导出到其他系统,例如做流计算、放到对象存储中进行备份。
- 多租户:如何将数据分享给其他人使用,使用是否安全等。
项目 | 分项 | 自建ELK | Log Service |
---|---|---|---|
采集 | 协议 | Restful API |
|
客户端 | Logstash/Beats/FluentD,生态十分丰富。 |
|
|
配置 | 单元 | 提供Index概念用以区分不同日志。 |
提供两层概念,Project相当于命名空间,可以在Project下建立多个Logstore。 |
属性 | API + Kibana |
|
|
扩容 | 存储 |
|
无需操作 |
计算 | 新增机器 | 无需操作 | |
配置 |
|
控制台/API 操作,无需配管系统。 | |
采集点 | 通过配管系统控制,将配置和Logstash安装到机器组。 | 控制台/API 操作,无需配管系统。 | |
容量 | 不支持动态扩容 | 动态扩容、弹性伸缩。 | |
导出 | 方式 |
|
|
多租户 | 安全 | 商业版 |
|
流控 | 无流控 |
|
|
多租户 | Kibana支持 | 原生提供账号与权限级管理。 |
整体而言:
- ELK有非常多的生态和写入工具、安装、配置等都有较多工具可以使用。
- Log Service是托管服务,从接入、配置、使用上集成度非常高,普通用户5分钟就可以接入。
- Log Service是SaaS化服务,在过程中不需要担心容量、并发等问题。弹性伸缩,免运维。
功能(查询+分析)
查询主要是将符合条件的日志快速命中,分析功能是对数据进行统计与计算。
- 查询到指定结果,对结果进行统计分析。
- 不进行查询,直接对所有日志进行分析。
1. Status in (200,500] and Method:Get* | select count(1) as c, sum(inflow) as sum_inflow, ip group by Ip
2. * | select count(1) as c, sum(inflow) as sum_inflow, ip group by Ip
- 查询基础对比
该对比基于Elastic 6.5 Indices。
类型 子类 ELK Log Service 文本 索引查询 支持 支持 分词 支持 支持 中文分词 支持 支持 前缀 支持 支持 后缀 支持 - 模糊 支持 可通过SQL支持 Wildcard 支持 可通过SQL支持 数值 long 支持 支持 double 支持 支持 Nested Json 支持 - Geo Geo 支持 可通过SQL支持 IP IP查询 支持 可通过SQL支持 对比结论如下:- ES 支持的数据类型丰富度,原生查询能力比Log Service更完整。
- Log Service能够通过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'
- 查询扩展能力
在日志查询场景中,光有检索还不够,需要能够围绕查询做进一步的工作。
- 定位到错误日志后,想通过上下文查看是什么参数引起了错误。
- 定位到错误后,想看看之后有没有类似错误,类似tail -f 原始日志文件,并进行grep。
- 通过关键词搜索到大量日志(例如百万条),其中90%都是已知问题干扰调查线索。
- 上下文查询(Context Lookup):原始上下文翻页,免登服务器。
- LiveTail功能(Tail-f):原始上下文tail-f,更新实时情况。
- 智能聚类(LogReduce):根据日志Pattern动态归类,合并重复模式,洞察异常。
- LiveTail功能
在传统的运维方式中,如果需要对日志文件进行实时监控,需要到服务器上对日志文件执行
tail -f
命令,如果实时监控的日志信息不够直观,可以加上grep
或者grep -v
进行关键词过滤。Log Service在控制台提供了日志数据实时监控的交互功能LiveTail,针对线上日志进行实时监控分析,减轻运维压力。Livetail特点如下:- 智能支持Docker、K8S、服务器、Log4J Appender等来源数据。
- 监控日志的实时信息,标记并过滤关键词。
- 日志字段做分词处理,以便查询包含分词的上下文日志。
- 智能聚类(LogReduce)
随着业务的高速发展,各个系统每天产生大量的日志,存在如下担忧:
- 系统有潜在异常,但被淹没在海量日志中。
- 机器被入侵,有异常登录,却后知后觉。
- 新版本上线,系统行为有变化,却无法感知这些问题,是因为信息太多、太杂,不能良好归类,同时记录信息的日志,往往还都是无主题,格式多样,归类难度更大。Log Service提供实时日志智能聚类(LogReduce)功能根据日志的相似性进行归类,快速掌握日志全貌。
- 支持任意格式日志:Log4J、Json、单行(syslog)。
- 日志经任意条件过滤后再Reduce;对日志Reduce后Pattern,根据signature反查原始数据。
- 不同时间段Pattern比较。
- 动态调整Reduce精度。
- 亿级数据,秒级出结果。
分析能力对比
ES在docvalue之上提供一层聚合(Aggregation)语法,并且在6.x版本中提供SQL语法能够对数据进行分组聚合运算。 Log Service支持完整SQL92标准(提供restful 和 jdbc两种协议),除基本聚合功能外,支持完整的SQL计算,并支持外部数据源联合查询(Join)、机器学习、模式分析等函数。
- 同比和环比函数
同比环比函数能够通过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
- 外部数据源联合查询(Join)
可以在查询分析中关联外部数据源。
- 支持Logstore、MySQL、OSS(CSV)等数据源。
- 支持left、right、full outer join、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
- 地理位置函数
针对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
查询结果: - 安全分析函数
依托全球白帽子共享安全资产库,提供安全检测函数,您只需要将日志中任意的IP、域名或者URL传给安全检测函数,即可检测是否安全。
- security_check_ip
- security_check_domain
- security_check_url
- 机器学习与时序检测函数
新增机器学习与智能诊断系列函数。
- 根据历史自动学习其中规律,并对未来的走势做出预测。
- 实时发现不易察觉的异常变化,并通过分析函数组合推理导致异常的特征。
- 结合环比、告警功能智能发现/巡检。该功能适用在智能运维、安全、运营等领域,帮助更快、更有效、更智能洞察数据。
提供如下功能:- 预测:根据历史数据拟合基线。
- 异常检测\变点检测\折点检测:找到异常点。
- 多周期检测:发现数据访问中的周期规律。
- 时序聚类:找到形态不一样的时序。
- 模式分析函数
模式分析函数能够洞察数据中的特征与规律,帮助快速、准确推断问题。
- 定位频繁集。例如:错误请求中90%由某个用户ID构成。
- 定位两个集合中最大支持因素。
- 延时>10S请求中某个ID构成比例远远大于其他维度组合。
- 并且该ID在对比集合(B)中的比例较低。
- A和B中差异明显。
性能
针对相同数据集,分别对比写入数据及查询,和聚合计算能力。
- 实验环境
- 测试配置
类别 自建ELK Log Service 环境 ECS 4核16GB * 4台 + 高效云盘或SSD - Shard 10 10 拷贝数 2 3 (默认配置,对用户不可见) - 测试数据
- 5列double、5列long、5列text,字典大小分别是256、512、768、1024、1280。
- 以上字段完全随机(测试日志样例如下)。
- 原始数据大小:50 GB。
- 日志行数:162640232 (约为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批量写入,LogSearch/Analytics 用PostLogstoreLogs API批量写入,结果如下。
类型 项目 自建ELK Log Service 延时 平均写入延时 40 ms 14 ms 存储 单拷贝数据量 86G 58G 膨胀率:数据量/原始数据大小 172% 116% 说明 日志服务产生计费的存储量包括压缩的原始数据写入量(23G)和索引流量27G,共50G存储费用。从测试结果来看- 日志服务写入延时好于ES,40ms vs 14 ms。
- 空间:原始数据50G,因为测试数据比较随机,所以存储空间会有膨胀(大部分真实场景下,存储因压缩会比原始数据小)。ES胀到86G,膨胀率为172%,在存储空间超出日志服务 58%。这个数据与ES推荐的存储大小为原始大小2.2倍比较接近。
- 读取(查询+分析)测试
- 测试场景
选取两种比较常见的场景:日志查询和聚合计算。分别统计并发度为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
- 针对全量数据,对任意text列计算group by,计算5列数值的avg/min/max/sum/count,并按照count排序,取前1000个结果,例如:
- 测试结果
类型 并发数 ES延时(单位为秒) 日志服务延时(单位为秒) 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 - 结果分析
- 从结果看,对于1.6亿数据量这个规模,两者都达到了秒级查询与分析能力。
- 针对统计类场景(case 1), ES和日志服务延时处同一量级。ES采用SSD云盘,在读取大量数据时IO优势比较高。
- 针对查询类场景(case 2), LogAnalytics在延时明显优于ES。随着并发的增加,ELK延时对应增加,而LogAnalytics延时保持稳定甚至略有下降。
- 测试场景
规模与成本
- 规模能力
- 日志服务一天可以索引PB级数据,一次查询可以在秒级过几十TB规模数据,在数据规模上可以做到弹性伸缩与水平扩展。
- ES比较适合服务场景为:写入GB-TB/Day、存储在TB级。主要受限于2个原因:
- 单集群规模:比较理想为20台左右,据了解业界比较大为100节点一个集群,为了应对业务往往拆成多个集群。
- 写入扩容:shard创建后便不可再修改,当吞吐率增加时,需要动态扩容节点,最多可使用的节点数便是shard的个数。
- 存储扩容:主shard达到磁盘的上限时,要么迁移到更大的一块磁盘上,要么只能分配更多的shard。一般做法是创建一个新的索引,指定更多shard,并且rebuild旧的数据。
用户案例(规模带来的问题)
客户A是中国的最大资讯类网站之一,有数千台机器与百号开发人员。运维团队原先负责一套ELK集群用来处理Nginx日志,但始终处于无法大规模使用状态:- 一个大Query容易把集群打爆,导致其他用户无法使用。
- 在业务高峰期间,采集与处理能力打满集群,造成数据丢失,查询结果不准确。
- 业务增长到一定规模,因内存设置、心跳同步等节点经常内存失控导致OOM 不能保证可用性与准确性,开发最终没有使用起来,成为一个摆设。
- 使用Logtail来采集线上日志,将采集配置、机器管理等通过API集成进客户自己运维与管控系统。
- 将日志服务查询页面嵌入统一登录与运维平台,进行业务与账户权限隔离。
- 通过控制台内嵌方案满足开发查询日志需求,通过Grafana插件调用日志服务统一业务监控,通过DataV连接日志服务进行大盘搭建。
整体架构如下图:平台上线2个月后:- 每天查询的调用量大幅上升,开发逐步开始习惯在运维平台进行日志查询与分析,提升了研发的效率,运维部门也回收了线上登录的权限。
- 除Nginx日志外,把App日志、移动端日志、容器日志也进行接入,规模是之前10倍。
- 除查询日志外,也衍生出很多新的玩法,例如通过Jaeger插件与控制台基于日志搭建了Trace系统,将线上错误配置成每天的告警与报表进行巡检。
- 通过统一日志接入管理,规范了各平台对接总线,不再有一份数据同时被采集多次的情况,大数据部门Spark、Flink等平台可以直接去订阅实时日志数据进行处理。
- 成本
以上述测试数据为例,一天写入50GB数据(其中23GB 为实际的内容),保存90天,平均一个月的耗费。
- 日志服务(LogSearch/LogAnalytics)计费规则参见按量付费,包括读写流量、索引流量、存储空间等计费项,查询功能免费。
计费项目 值 单价 费用(元) 读写流量 23G * 30 0.2 元/GB 138 存储空间(保存90天) 50G * 90 0.3 元/GB*Month 1350 索引流量 27G * 30 0.35 元/GB 283 总计 - - 1771 - 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) 同样性能,使用LogSearch/Analytics与ELK(SSD)费用比为 13.6%。在测试过程中,我们也尝试把SSD换成SATA以节省费用(LogAnalytics与SATA版费用比为 34%),但测试发现延时会从40ms上升至150ms,在长时间读写下,查询和读写延时变得很高,无法正常工作了。
- 日志服务(LogSearch/LogAnalytics)计费规则参见按量付费,包括读写流量、索引流量、存储空间等计费项,查询功能免费。
- 时间成本(Time to Value)
除硬件成本外,日志服务在新数据接入、搭建新业务、维护与资源扩容成本基本为0。
- 支持各种日志处理生态,可以和Spark、Hadoop、Flink、Grafana等系统无缝对接。
- 在全球化部署(有20+ Region),方便拓展全球化业务。
- 提供30+日志接入SDK,与阿里云产品无缝打通集成。
总结
ES支撑更新、查询、删除等更通用场景,在搜索、数据分析、应用开发等领域有广泛使用,ELK组合在日志分析场景上把ES灵活性与性能发挥到极致;日志服务是纯定位在日志类数据分析场景的服务,在该领域内做了很多定制化开发。一个服务更广,一个场景更具针对性。当然离开了场景纯数字的比较没有意义,找到适合自己场景的才重要。