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

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

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


  1. 采集:
  • Logtail: 多年百万级服务器锤炼,简便、可靠、高性能 ;
  • SDK/Producer: Java/C/Go/iOS/Android/web tracking;
  • 全球加速: 集成 DCDN 全球加速
  1. 存储 & 消费 :
  • ConsumerGroup: 自动负载均衡、failover、服务端 checkpoint 持久化 ;
  • 生态集成:支持 Blink/Flink/Storm/Spark Streaming 等多种流系统,已对接各类监控系统 ;
  • Shipper:支持 Oss、MaxCompute 数据转存
  1. 查询 & 分析:
  • Text、Json、Double、Long;
  • 支持中文,Json 自动展开,全文 / 键值 ;
  • 百亿级规模查询 ;
  • DevOps 场景:上下文、Live Tail、LogReduce、异常检查、预测、根因分析 ;
  • 分析功能:SQL92、交互式查询、机器学习、安全特色函数
  1. 可视化
  • 原生 Dashboard、十几种图形展示 ;
  • JDBC 接口,支持 DataV、Grafana、QuickBI 展示。

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

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

  • 规模大: 每日产生的各类日志超过数十 PB;
  • 种类杂:包含各类访问日志、系统日志、应用日志等各类日志,种类繁多,格式复杂 ;
  • 来源多:服务器端、网络设备、嵌入式、web 端、Docker、移动 app 多种数据源实时产生数据 ;
  • 应用广:各条业务线对于日志的使用需求广泛,如监控报警、问题诊断、数据分析和深入挖掘、报表等各类场景,因此使用和消费模式也会多种多样 ;
  • 要求高:对于系统的稳定、可用性都有非常苛刻的要求,以满足关键业务的需求 ;
  • 峰值大:在双十一等活动,舜时会产生大量日志,如何应对这样的峰值,也是很大的挑战。

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

阿里云日志系统核心功能

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

  • 高可靠性:对于一些日志数据不落地的场景,如果后端服务不可用,很可能导致数据丢失 ;
  • 资源隔离:能够提供良好的 QOS,不因个别用户的异常,影响其他用户 ;
  • 高性价比:针对日志的一些特性,进行系统优化,尽可能降低处理海量数据的成本,如每天采集、存储、索引 1PB 日志,机器资源消耗最大能降低到多少 ;
  • 管理能力:如何管理百万级客户端的,如何快速发现、定位日志采集过程的异常;如何进行版本的维护升级 ;
  • 快速查询分析:在海量日志中,进行快速的查询和分析,及时返回结果给用户。

日志系统的设计

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

  1. 负责采集数据的客户端 Agent;
  2. 提供 Resutful API 接口的前端模块 ;
  3. 进行数据存储和索引的模块 ;
  4. 查询分析模块 ;
  5. 负责 Meta 信息管理模块 ;
  6. 负责监控、运维的管理模块

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

  1. 如何在性能、成本之间如何进行平衡以及取舍。现有硬件条件下, 每 GB SSD 磁盘的价格是普通 HDD 的 5 倍,在每日数十 PB 写入量的情况下,全部使用 SSD 磁盘,成本不可接受,但是 HDD 的磁盘读取延时、吞吐能力要比 SSD 差不少,在受限硬件条件下,如何满足海量数据的查询需求?针对这个苛刻的成本和性能问题,我们团队根据日志场景的特点,从 0 开始打造了一款专门为日志数据存储和索引的分布式引擎:
  2. a. 在倒排索引字典上,使用 succinct tree 进行编码,字典只有 FST 结构的 40~70%;
  3. b. 倒排索引数据使用自研的混合 Bitmap 结构,可以直接在 encoding 后 Bitmap 上进行 and、not、or 操作,无需对 bitmap 进行反序列化;
  4. c. 使用改进的 BKD-Tree 对数值进行索引,配合高效的压缩算法,读写速度是开源版本的 1.4~2 倍,压缩率提高 50%,部分 distinct 值个数较少场景压缩率提高 10 倍;
  5. d. 大量使用 SIMD 指令来提高数值压缩、解压速度。
  6. 在大规模分布式集群,如何打造 always available 的服务。系统要有良好的抗压和异常自我恢复能力,在各种高压情况下(如应用出错、代码 bug 等情况,流量可能成百、上千倍放大),系统要通过自身技术手段,自动、快速、准确定位异常流量,拦截在系统最外层,保证内部不被打垮。在分布式系统中,软硬件的异常时常发生,系统需要能进行自动迁移和隔离,最终保障系统的可用性。同时,为了最大程度提高资源使用效率,我们采用多租户共享集群资源的方式,但是应用场景多样,每个应用对日志使用模式并不相同,资源的消耗也有差异,例如,部分应用查询分析特别频繁,属于 CPU 密集型;部分应用流量特别大,是网络密集型;部分应用则周期性出现峰值等。如何在有限的资源下,提供良好的 QOS,满足各应用需求的同时,提高资源使用效率,也是一个不小挑战。
  7. 如何挖掘日志特性,设计适合日志数据的存储和索引结构,使其能在十 亿、百亿级场景下,进行快速查询分析。在阿里的场景下,单一应用每天产生上百 TB 日志是很常见,单次查询,覆盖十亿、百亿行日志也是是一个非常普遍的情况。在这样的规模下,如何进行加速,在设计上有不小挑战,分布式查询是一个必选项,一次查询可能会在数百节点之间同时进行。我们在设计时候,通过尽可能减少节点之间数据交互量;采用多层 Cache 结构,来复用索引、原始数据、临时计算结果;使用协程进行计算、IO 分离等;智能调节数后台索引 Compaction 速度等多种方式,来实现超大规模快速查询分析。
  8. 可靠、高效管理数百万台服务器的采集配置也是一个难点。特别是在双十一等特殊时期,需要系统能进行精准、快速的流控,确保高优先级数据及时采集,低优先级任务不因过多资源消耗而影响业务性能。为此,我们设计前端采集 Agent 和后端管理模块时,加入一套可靠的管理协议,所有的配置可以在控制台进行操作,由后端管理模块同步前端采集 Agent,无需登陆机器进行配置管理。同时,在双十一等特殊时期,可以动态修改每个日志源不同的采集上限,进行优先级控制。

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

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

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

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

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

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

日志数据的处理

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


  • 实时查询和分析:日志服务本身提供海量日志实时检索和 SQL 分析、上下文查询(Context),实时 Tail(Live Tail)、日志数据智能聚类 (LogReduce)、异常检查和根因分析等能力,用户可直接在日志服务上进行问题排查、异常定位、深入挖掘日志数据价值 ;
  • 可视化分析:通过自定义画布 (Canvas),配合数十种图形和 Drill down/Roll up,非常方便地构建交互式可视分析仪表盘,数据所见即所得 ;
  • 告警:日志服务原生提供日志分析结果告警功能,对于告警消息的投递,除了传统的短信、邮件外,也支持 webhook,如投递给钉钉机器人,或自定义链接进行自动报警处理逻辑触发 ;
  • 二次开发:不少团队基于日志服务,根据其业务特点进行二次开发,如各类 Tracing 系统、客服系统等。

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

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


  • 各类流式系统:Flink/Blink, Storm (JStorm),Spark Streaming。日志服务提供各流式系统提供日志消费消费 lib,屏蔽数据拉取、checkpoint 保存、failover 等细节,只需关注数据流的处理逻辑即可,简化各类流系统实时消费日志的复杂度,完成数据实时 ETL、监控等场景 ;
  • 离线系统:对数据有更深入分析的场景,如用户画像、关联分析等场景,可以使用日志服务的归档功能,将数据保留至阿里云对象存储 (OSS), 或 MaxCompute 这样的系统,进行后续分析 ;
  • DataWorks: 对数据外部存储还有更多需求的用户,可以使用 DataWorks 实时消费日志日志,导入到各类其他系统,如 MySQL 等数据库 ;
  • Serverless:对于不想自己运维流式系统,但是又有自定义分析需求的场景,也可以使用 Serverless 的模式来消费日志,如阿里云函数计算 FC,只需要编写日志处理函数,运行由函数计算进行托管。

转自:

1.《(日志数据如何设计与实现)如何获取游戏日志数据?》援引自互联网,旨在传递更多网络信息知识,仅代表作者本人观点,与本网站无关,侵删请联系页脚下方联系方式。

2.《(日志数据如何设计与实现)如何获取游戏日志数据?》仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。

3.文章转载时请保留本站内容来源地址,https://www.lu-xu.com/keji/3298388.html