日志采集的挑战

1 概述

  1. 对于目前的互联网行业,互联网日志早已跨越初级的饥饿阶段(大型互联网企业的日均日志收集量均以亿为单位计量),反而面临海量日志的淹没风险;
  2. 各类采集方案提供者面临的主要挑战已不是日志采集技术本身;
  3. 而是如何实现日志数据的结构化和规范化组织,实现更为高效的下游统计计算,提供符合业务特性的数据展现;
  4. 以及为算法提供更便捷、灵活的支持等方面;

2 典型场景

下面介绍两个最典型的场景和阿里巴巴所采用的解决方案。

1.1 日志分流与定制处理

  1. 大型互联网网站的日志类型和日志规模呈现高速增长的态势,且往往会出现短时间的流量热点大爆发,这使得在日志服务器端采用集中统一的解析处理方案变得不可能;
  2. 要求在日志解析和处理过程中必须考虑业务分流(相互之间不应存在明显的影响,爆发热点不应干扰定常业务日志的处理)、日志优先级控制,以及根据业务特点实现定制处理;
  3. 例如,对电商网站而言,数据分析人员对位于点击流前端的促销页面和位于后端的商品页面的关注点是不一样的,而这两类页面的流量同等重要且庞大,如果统一解析处理方案,需要在资源浪费(尽可能多地进行预处理)和需求覆盖不全(仅对最重要的内容进行预处理)两个选择之间进行取舍,取舍的结果往往不是最优;
  4. 考虑到阿里日志体量的规模和复杂度,分治策略从一开始便是阿里互联网日志采集体系的基本原则;
  5. 与业界通用的第三方日志采集方案的日志请求路径几乎归一不同,阿里PV日志的请求位置(URL)是随着页面所在业务类型的不同而变化的;
  6. 通过尽可能考前地布置路由差异,可以尽可能早地进行分流,降低日志处理过程中的分支判断消耗,并作为后续的计算资源调配的前提,提高资源利用效率;
  7. 不仅考虑诸如日志分流处理之类的日志服务器端分布计算方案,而且将分流任务前置到客户端,以实现整个系统的效能最大化;

1.2 采集与计算一体化设计

  1. 页面PV日志采集之后的一个基础性操作是日志的归类与汇总;
  2. 在早期互联网日志的分析中,是以URL路径,继而以URL(正则)规则集为依托来进行日志分类的;
  3. 在网站规模小时,这种做法可以运转,随着规模变大,URL规则集的维护和使用成本会很快增长到不现实的程度,失控的大规模正则适配甚至会将日志计算硬件集群彻底榨干;
  4. 这就要求日志采集方案必须将采集与计算作为一个系统来考量,进行一体化设计;
  5. 阿里针对此问题给出的是两套日志规范和与之对应的元数据中心;
    1. 对应于PV日志的解决方案是SPM规范和SPM元数据中心。通过SPM的注册和简单部署,用户即可将任意的页面流量进行聚类,不需要进行任何多余的配置就可以在相应的内部数据产品内查询聚合统计得到的流量、转化漏斗、引导交易等数据,以及页面各元素点击数据的可视化视图;
    2. 对应于自定义日志的解决方案则是黄金令箭/APP端的点击或其他日志规范及其配置中心。通过注册一个与所在页面完全独立的令箭实体/控件实体,用户可以一键获得对应的埋点代码,并自动获得实时统计数据和与之对应的可视化视图。通过简单的扩展配置,用户还可以自动获得自定义统计维度下的分量数据。
  6. 当下,互联网日志的规模化采集方案必须具备一个与终端设备的技术特点无关,具有高度扩展弹性和适应性,同时深入契合应用需求的业务逻辑模型,并基于此制定对应的采集规范交由产品开发人员执行,否则就不能保障采集-解析-处理-应用整个流程的通畅;
  7. 目前阿里已实现规范制定-元数据注册-日志采集-自动化计算-可视化展现全流程的贯通;
  8. 日志本身不是日志采集的目的,服务于基于日志的后续应用,才是日志采集正确的着眼点;

3 大促保障

  1. 日志数据在阿里系乃至整个电商系都是体量最大的一类数据,在双十一期间,日志更会暴涨,近万亿的数据量对日志全链路来说,是个挑战;
  2. 从端上埋点采集,到日志服务器收集,经过数据传输,再到日志实时解析、实时分析,任何一个环节出现问题,全链路保障就是失败的;
  3. 考虑到服务器的收集能力、数据传输能力、实时解析的吞吐量、实时业务分析的处理能力,每个环节都需要做工作;
    在这里插入图片描述
  4. 首先,端上实现了服务器端推送配置到客户端,且做到高到达率;其次,对日志做分流,结合日志的重要程度及各类日志的大小,实现了日志服务器端的拆分;最后,在实时处理方面,也做了不少的优化以提高应用的吞吐量;
  5. 在上面几项的基础上,结合实时处理能力,评估峰值数据量,在高峰期通过服务器端推送配置的方式对非重要日志进行适当限流,错峰后逐步恢复,具体实施包括延迟上报、部分采样等;
  6. 对于对实时性要求极高的业务场景,如上链路显然不能满足需求。因此,一方面,从业务上进行改造(采用端上记录),另一方面在链路各环节做优化,如从采集服务器直接完成解码并调用业务API完成业务计算(省去中间的传输和过多的处理);
  7. 在如上策略下,日志采集浏览等核心用户行为日志均实现了100%全量及实时服务,支持天猫所有会场的实时推荐,在双十一中,用户的浏览、点击、滚屏等每个操作行为,都实时影响到后续为其推荐的商品,很好地提高了用户体验;
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

hellosc01

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值