欢迎您光临本站,如有问题请及时联系我们。

阿里云10 PB+/天的日志系统设计和实现

  当前日志系统是以数据驱动运维的时代,对数据的需求很大,如何从海量日志里挖掘,需要对日志收集、处理和管理的能力。此文系ArchSummit全球架构师峰会采访文章,旨在通过阿里优秀的技术实践,为读者提供解决问题的思路启发。本文采访嘉宾是阿里高级技术专家孙廷韬(花名:龙悟),负责阿里云日志服务架构设计和实现。

  阿里云日志服务作为阿里集团底层日志平台,提供完善易用的数据采集方案,PB级数据实时索引和分析能力,在阿里集团被广泛应用,数千工程师直接使用日志服务进行日常问题排查,也有大量应用基于日志服务进行二次开发,如阿里集团所有大型Trace系统底层都使用日志服务。


  在此背景下,我们邀请了阿里云高级技术专家孙廷韬(花名:龙悟)老师来7月深圳ArchSummit全球架构师峰会上演讲,他本人重点负责阿里云日志服务架构设计和实现,此次将介绍阿里10PB+/天日志系统设计和实现的话题。


  可以先通过一个大图,看看阿里云日志服务提供的核心功能:


  1.采集:


  Logtail:多年百万级服务器锤炼,简便、可靠、高性能;

  SDK/Producer:java/c/go/ios/android/webtracking;

  全球加速:集成DCDN全球加速


  2.存储&消费:


  ConsumerGroup:自动负载均衡、failover、服务端checkpoint持久化;

  生态集成:支持blink/flink/storm/sparkstreaming等多种流系统,已对接各类监控系统;

  Shipper:支持Oss、MaxCompute数据转存


  3.查询&分析:


  Text、Json、Double、Long;

  支持中文,Json自动展开,全文/键值;

  百亿级规模查询;

  DevOps场景:上下文、livetail、LogReduce、异常检查、预测、根因分析;

  分析功能:SQL92、交互式查询、机器学习、安全特色函数


  4.可视化


  原生Dashboard、十几种图形展示;

  JDBC接口,支持DataV、Grafana、QuickBI展示。


  阿里云生产环境下的日志特点

  在生产环境下,阿里云日志有如下特点:


  规模大:每日产生的各类日志超过数十PB;

  种类杂:包含各类访问日志、系统日志、应用日志等各类日志,种类繁多,格式复杂;

  来源多:服务器端、网络设备、嵌入式、web端、Docker、移动app多种数据源实时产生数据;

  应用广:各条业务线对于日志的使用需求广泛,如监控报警、问题诊断、数据分析和深入挖掘、报表等各类场景,因此使用和消费模式也会多种多样;

  要求高:对于系统的稳定、可用性都有非常苛刻的要求,以满足关键业务的需求;

  峰值大:在双十一等活动,舜时会产生大量日志,如何应对这样的峰值,也是很大的挑战。


  日志服务通过构建统一的系统,来解决不同用户在日志的采集、存储、查询和分析上的一些通用需求,简化用户使用日志的复杂度,使得用户能够更专注于日志数据价值的挖掘。


  阿里云日志系统核心功能

  针对阿里云的日志特点,日志系统需要满足以下这些条件:


  高可靠性:对于一些日志数据不落地的场景,如果后端服务不可用,很可能导致数据丢失;

  资源隔离:能够提供良好的QOS,不因个别用户的异常,影响其他用户;

  高性价比:针对日志的一些特性,进行系统优化,尽可能降低处理海量数据的成本,如每天采集、存储、索引1PB日志,机器资源消耗最大能降低到多少;

  管理能力:如何管理百万级客户端的,如何快速发现、定位日志采集过程的异常;如何进行版本的维护升级;

  快速查询分析:在海量日志中,进行快速的查询和分析,及时返回结果给用户。


  日志系统的设计

  阿里云日志系统主要有以下模块:


  1.负责采集数据的客户端Agent;

  2.提供ResutfulAPI接口的前端模块;

  3.进行数据存储和索引的模块;

  4.查询分析模块;

  5.负责Meta信息管理模块;

  6.负责监控、运维的管理模块


  在日志系统的设计过程中遇到的主要挑战有:


  1.如何在性能、成本之间如何进行平衡以及取舍。现有硬件条件下,每GBSSD磁盘的价格是普通HDD的5倍,在每日数十PB写入量的情况下,全部使用SSD磁盘,成本不可接受,但是HDD的磁盘读取延时、吞吐能力要比SSD差不少,在受限硬件条件下,如何满足海量数据的查询需求?针对这个苛刻的成本和性能问题,我们团队根据日志场景的特点,从0开始打造了一款专门为日志数据存储和索引的分布式引擎:


  a.在倒排索引字典上,使用succincttree进行编码,字典只有FST结构的40~70%;

  b.倒排索引数据使用自研的混合bitmap结构,可以直接在encoding后bitmap上进行and、not、or操作,无需对bitmap进行反序列化;

  c.使用改进的BKD-Tree对数值进行索引,配合高效的压缩算法,读写速度是开源版本的1.4~2倍,压缩率提高50%,部分distinct值个数较少场景压缩率提高10倍;

  d.大量使用SIMD指令来提高数值压缩、解压速度。


  2.在大规模分布式集群,如何打造Alwaysavailable的服务。系统要有良好的抗压和异常自我恢复能力,在各种高压情况下(如应用出错、代码bug等情况,流量可能成百、上千倍放大),系统要通过自身技术手段,自动、快速、准确定位异常流量,拦截在系统最外层,保证内部不被打垮。在分布式系统中,软硬件的异常时常发生,系统需要能进行自动迁移和隔离,最终保障系统的可用性。同时,为了最大程度提高资源使用效率,我们采用多租户共享集群资源的方式,但是应用场景多样,每个应用对日志使用模式并不相同,资源的消耗也有差异,例如,部分应用查询分析特别频繁,属于CPU密集型;部分应用流量特别大,是网络密集型;部分应用则周期性出现峰值等。如何在有限的资源下,提供良好的QOS,满足各应用需求的同时,提高资源使用效率,也是一个不小挑战。


  3.如何挖掘日志特性,设计适合日志数据的存储和索引结构,使其能在十亿、百亿级场景下,进行快速查询分析。在阿里的场景下,单一应用每天产生上百TB日志是很常见,单次查询,覆盖十亿、百亿行日志也是是一个非常普遍的情况。在这样的规模下,如何进行加速,在设计上有不小挑战,分布式查询是一个必选项,一次查询可能会在数百节点之间同时进行。我们在设计时候,通过尽可能减少节点之间数据交互量;采用多层Cache结构,来复用索引、原始数据、临时计算结果;使用协程进行计算、IO分离等;智能调节数后台索引Compaction速度等多种方式,来实现超大规模快速查询分析。


  4.可靠、高效管理数百万台服务器的采集配置也是一个难点。特别是在双十一等特殊时期,需要系统能进行精准、快速的流控,确保高优先级数据及时采集,低优先级任务不因过多资源消耗而影响业务性能。为此,我们设计前端采集Agent和后端管理模块时,加入一套可靠的管理协议,所有的配置可以在控制台进行操作,由后端管理模块同步前端采集Agent,无需登陆机器进行配置管理。同时,在双十一等特殊时期,可以动态修改每个日志源不同的采集上限,进行优先级控制。


  日志系统的稳定性如何保障

  关于日志系统的稳定性,所有的模块需要做到可以水平扩展。无论是接收流量的前端模块,数据存储索引和查询模块,或是管理百万服务器配置管理模块,都需要做到水平扩展,才能撑起每日数十PB的日志量。


  异常流量和请求在前端模块被拦截,防止穿透至后端。我们在设计系统的时候,为每个模块定义了标准处理能力,如负责数据索引的模块,确定每个shard读写能力标准,当实际流量超过标准,机器在还有富余资源时,会继续提供服务,而资源不够,并且shard未开启自动分裂的情况下,触发限流操作,系统内部的反馈机制,能够在毫秒级别延时内,将该shard流控信息,同步到所有上千个前端进程,各前端在一定时间内,可直接拒绝该shard流量。通过这样的机制,异常流量在系统最前端被拦截,防止后端单点被打爆,经线上实测,穿透到后端的异常流量只有正常流量的1%~3%。


  模块内部进行自动调度和负载均衡。系统内部,会实时统计各应用日志的流量和资源消耗,进行中心汇总,系统在分钟级别可发现集群中存在的热点和类型,并确定导致热点的日志源,根据热点的类型,匹配合适的迁移目标,将热点流量迁移至可以到合适的机器上,进行资源消耗互补。


  资源隔离,自动根据负载调节资源使用限制。日志场景下,数据都带有时间信息,在进行日志查询和分析的时候,也限定了时间窗口。每次查询,后端根据当前负载以及应用之前资源消耗等信息,限定这次查询执行并发数、磁盘读取量、执行时间、内存消耗等资源上限,查询的中间结果被缓存在内存中,后续查询可复用cache中的结果加快查询速度。


  完善的监控体系。监控对于一个系统来说至关重要,我们在覆盖系统的关键指标、硬件状态、外部访问监控的基础上,也使用系统自身提供的异常检查功能进行对自己进行异常检查。


  日志数据的处理

  在Sec/Dev/ITOps领域,日志数据发挥了重要的作用,主要包括以下几个方面:


  实时查询和分析:日志服务本身提供海量日志实时检索和SQL分析、上下文查询(Context),实时Tail(liveTail)、日志数据智能聚类(LogReduce)、异常检查和根因分析等能力,用户可直接在日志服务上进行问题排查、异常定位、深入挖掘日志数据价值;

  可视化分析:通过自定义画布(Canvas),配合数十种图形和DrillDown/Rollup,非常方便地构建交互式可视分析仪表盘,数据所见即所得;

  告警:日志服务原生提供日志分析结果告警功能,对于告警消息的投递,除了传统的短信、邮件外,也支持webhook,如投递给钉钉机器人,或自定义链接进行自动报警处理逻辑触发;

  二次开发:不少团队基于日志服务,根据其业务特点进行二次开发,如各类Tracing系统、客服系统等。


  日志系统和其他系统的对接

  下图展示了阿里云日志系统可以跟哪些系统对接:


  各类流式系统:Flink/Blink,Storm(jstorm),Sparkstreaming。日志服务提供各流式系统提供日志消费消费lib,屏蔽数据拉取、checkpoint保存、failover等细节,只需关注数据流的处理逻辑即可,简化各类流系统实时消费日志的复杂度,完成数据实时ETL、监控等场景;

  离线系统:对数据有更深入分析的场景,如用户画像、关联分析等场景,可以使用日志服务的归档功能,将数据保留至阿里云对象存储(OSS),或MaxCompute这样的系统,进行后续分析;

  DataWorks:对数据外部存储还有更多需求的用户,可以使用DataWorks实时消费日志日志,导入到各类其他系统,如Mysql等数据库;

  Severless:对于不想自己运维流式系统,但是又有自定义分析需求的场景,也可以使用Serverless的模式来消费日志,如阿里云函数计算FC,只需要编写日志处理函数,运行由函数计算进行托管。


来源:本文由E8运维原创撰写,欢迎分享本文,转载请保留出处和链接!