阿里巴巴日志采集

LOG

6.解析渲染

设备标识用户登录唯一标识  但是很多日志行为并不要求用户登录PC 端一般使用Cookie 信息来作为设备的唯一信息APP端阿里巴巴使用UTDID

日志服务器

内部处理过程

5.客户端 -->服务器：Http响应返回已插入日志采集代码的HTML文档

问题可能就会以为第二次去 B页面的来源为C

1.注册需要采集交互日志的业务具体业务场景场景下的具体交互采集点

解决将H5日志采用SDK归到Native日志1.采用采集SDK 可以采集到更多的设备相关数据2.采用采集SDk会先在本地缓存 而后借机上传  在网络状况不佳时延迟上报 保证数据不丢失

特殊场景A ->B -> C ->B  有一个回退效果

解决

事件根据用户的不同行为分成不同事件无线客户端日志行为的最小单位

问题识别流量攻击 网络爬虫 和 流量作弊（虚假流量）数据缺项补正：为了便利后续的日志应用和保证基本的数据统计 口径一致无效数据剔除：因业务变更或配置不当，在采集到的日志中会存在一些无意义、已经失效或者冗余的数据项日志隔离分发：基于数据安全或者业务特性的考虑  某些日志在进入公共数据环境之前需要做隔离

8.日志解析/预处理/存储供后续使用

4.服务器端采集代码部署模块 改写文档在HTMl内插入日志采集代码

考虑到后续的数据处理，以及特殊时期不同日志的保障级别，还对日志进行了分流阿里巴巴用的Adash （无线日志服务器端处理程序）只需要页面事件及控件点击事件即可适当地释放其他类型日志的资源来处理更重要的页面事件及控件点击事件。

H5 & Native日志统一

用户

模板

页面事件通用用户行为 抽象一些通用接口一条日志信息:1.设备及用户的基本信息  2.被访问页面的信息（商品ID 所属店铺）  3.访问基本路径（页面来源）手动埋点  提供的接口: 页面展示:记录状态信息  页面退出:发送日志  页面扩展信息:离开页面前 给页面添加相关参数（店铺ID 店铺类别）SPM（超级位置模型）：把当前页面的某些信息 传递到下一个页面甚至下下页面的日志中  轻松还原用户的行为路径

业务方

纯 NativeApp

页面

日志分流和定制处理（原因：短时间的流量热点爆发）分治策略：以PV为例  阿里 PV 日志的请求位置（ URL ）是随着页面所在业务类型的不同而变化的尽可能靠前布置路由差异，就可以尽可能早点进行分流，降低日志处理过程中 的分支判断消耗降低日志处理过程中 的分支判断消耗并作为后续的计算资源调配的前提，提高资源利用效率阿里的客户端日志采集代码的一个突出特点是实现了非常高的更新频次（以月/年 阿里以天/周）并实现了更新的配置化不仅考虑诸如日志分流处理之类的日志服务器端分布计算方案，而且将分类任务前置到客户端（从某种程度上讲，这才是真正的“分布式” ！）以实现整个系统的效能最大化最后可以在计算后端几乎无感知的情况下，承载更大的业务量并保证处理质量和效率。

2.客户端 -->服务器：Http请求请求用户输入的URL

采集代码和正常业务互动响应代码一起被触发和执行

3.植入目标页面 将采集代码与要监测的交互行为做绑定

解决页面日志的服务器端清晰和预处理

1.用户输入

解决利用页面的生命周期 识别页面的复用 配合栈的深度来识别是否是回退行为

日志采集挑战（面临海量日志的淹没风险）如何实现日志数据的结构化和规范化组织，实现更为高效的下游统计计算，提供符合业务特性的数据展现，以及为算法提供更便捷、灵活的支持等方面

浏览器的页面日志采集

页面浏览（展现）日志采集指当一个页面被浏览器加载呈现时采集的日志互联网的两大指标：PV（网页浏览量） UV（访客数）页面浏览日志采集方案流程框架 -->如下图

控件点击事件和其它事件将交互日志采集从页面事件采集中剥离出来  这就是控件点击事件和其他事件其它事件：自定义事件控件点击事件： 和页面一样  记住了基本的设备信息 和  用户信息  其次 记录了控件所在页面名称  控件名称  控件的业务参数  操作页面上的某个控件

原因：早期对数据汇总 和  归类 是以 URL 路径，继而以URL（正则）规则集为依托来进行日志分类的但是大规模正则适配甚至会将日志计算硬件集群彻底榨干

7.浏览器 执行日志采集代码（脚本）向日志服务器发送日志请求

页面交互日志采集当页面加载和渲染完成之后，用户可以在页面上执行各类操作黄金令箭：是一个开放的基于Http协议的日志服务  解决交互日志的采集问题页面浏览日志采集方案：如下图

大促保障 1.服务器端推送配置到客户端，且做到高到达率 对非重要日志进行适当限流 ，错峰后逐步恢复      2.对日志做分流  结合日志的重要程度及各类日志的大小，实现了日志服务器端的拆分             3.实时处理方面  也做了不少的优化以提高应用的吞吐量一方面 从业务上进行改造，采用端上记录   一方面 在链路各环节做优化，如从采集服务器直接完成解码并调用业务 API 完成业务的计算（省去中间的传输和过多 的处理） 保证稳定的同时扩展功能， 稳定及业务深度之间做到很好的平衡以上策略：日志采集浏览等核心用 户行为日志均实现了100%全量及实时服务，支持天猫所有会场的实时推荐

https://www.baidu.com

HybridAppNativeApp和H5页面结合体Native页面采用SDK日志采集H5页面采用基于浏览器页面日志采集

日志采集Aplus.JS 是Web 端（基于浏览器）日志采集技术方案UserTrack 是 APP 端（无线客户端 ）日志采集技术方案

为什么分类？为了更好地完成数据分析：一般都是某类事件 而不是全部事件处理Hybrid应用  实现H5和Native日志的统一保证同一设备上各应用获取到的设备信息是唯一的解决：如何上传  如何合理处理

3.服务器业务模块 响应用户请求构造 用户请求的文档

日志传输无线客户端产生 日志后，先存储在客户端本地，然后再伺机上传伺机：必须有数据分析的支持和两个考虑：考虑日志的大小及合理性考虑上传时网络的耗时，来决定是否要调整上传机制。

指定行为

黄金令箭

无线客户端的日志采集使用名为 UserTrack（UT）的SDK来进行日志采集

阿里巴巴页面交互日志采集

页面浏览日志采集方案流程框架

如何把数据给下游就是 TT （消息队列）将消息 收集功能部署到日志采集服务器上进行消息的收集，而后续的应用可以是实时的应用实时来订阅 TT 收集到的消息  进行实时计算，也可以是离线的应用定时来获取消息，完成离线的计算

问题采集方式不同 采集内容及采集服务器均分离开需要Native和H5互跳 导致无法还原用户路径  数据丢失严重

2.生成对应的模板

采集与计算一体化设计（两套日志规范和与之对应的元数据中心）1.对应于 PY 日志的解决方案是目前用户可直观感知的 SPM 规范和 SPM 元数据中心通过 SPM 的注册和简单部署用户即可将任意的页面流量进行聚类，不需要进行任何多余的配置就可以在相应的内部数据产品内查询聚合统计得到的流量、转化漏斗、引导交易等数据，以及页面各元素点击数据的可视化视图2.对应于自定义日志的解决方案则是黄金令箭阿里已成功实现规范制定一元数据注册一 日志采集一自动化计算一可视化展现全流程的贯通日志本身不是日志采集的目的，服务于基于日志的后续应用，才是日志采集正确的着眼点。