自动化日志收集及分析在支付宝 App 内的演进

背景

结合《蚂蚁金服面对亿级并发场景的组件体系设计》，我们能够通盘了解支付宝移动端基础组件体系的构建之路和背后的思考，本文基于服务端组建体系的大背景下，着重探讨“自动化日志手机与分析”在支付宝 App 内的演进之路。

支付宝移动端技术服务框架

这是整个支付宝移动端无线基础团队的技术架构图，同时蚂蚁金服体系内的其他业务 口碑、网商银行、香港支付宝、天弘基金等) 通过移动开发平台 mPaaS进行代码开发、打包、灰度发布、上线、问题修复、运营、分析。因此，mPaaS 源自于支付宝移动端的核心技术架构，并在 App 全生命周期的每个环节提供特定的能力支持。接下来，我们将着重分享“日志诊断”和“移动分析”两个能力背后的架构演进和选型思考。

支付宝移动端技术服务框架：数据分析框架

如图所示，即数据分析能力的技术架构图，其中“数据同步”、“埋点SDK”、“日志网关”是移动端专属的能力，其余部分是所有的数据分析平台都必须具备的数据结构。

1. 日志采集

接下来我们重点分析支付宝移动端的日志采集框架，首先第一部分是“日志 SDK”，日志 SDK 会向业务层提供一个埋点接口，使用起来就和 Java 里面的 logger.info 的感觉一样：业务层只需要把想记录的信息传递给日志 SDK。日志 SDK 会在拿到业务日志后，去系统内部获取相关的系统级别的上下文信息，比如机型、操作系统版本、App 版本、手机分辨率、用户ID (如果用户登录了)、设备ID、上一个页面、当前页面等，接着把这些信息与业务日志内容整合成一个埋点，然后记录到设备的硬盘上。对，只是记录到硬盘上，并没有上报到服务端。

日志 SDK 会在合适的时机，去和日志网关交互，判断获取什么样的日志、什么级别的日志可以上报。如果可以上报，是以什么频率上报、在什么网络条件下上报。因此通过日志 SDK 与日志网关的交付，我们可以来实现日志的策略式降级。日志的策略式降级这点对于支付宝特别重要，因为目前支付宝的体量，日常的日志上报量为约 30W 条日志/s；而在大促的时候，日志量会是日常的几十倍！ 所以，如果大促期间不采用任何的日志降级策略的话，我们的带宽会被日志打包，支付宝的正常业务功能就不可用了。

由此，我们可以总结，在大促高并发场景下，我们需要只保留关键日志的上传，其余日志统统降级。即使是日常业务处理，我们也只允许日志在 WIFI 条件下上报，防止发生流量相关的投诉。

埋点网关除了提供日志上报的策略开关能力之外，就是接收客户端的日志。它在接受到客户端日志之后，会对日志内容进行校验，发现无效的日志会丢弃掉。而对有效合法的埋点，会根据客户端上报的公网 IP 地址，反解出城市级别的地址位置信息并添加到埋点中，然后将埋点存放在它自己的硬盘上。

2. 埋点分类

经过多年的实践，支付宝把日志埋点分为了四类。

（1）行为埋点：用于监控业务行为，即业务层传递的日志埋点属于行为埋点，行为埋点属于“手动埋点”，需要业务层开发同学自己开发。不过也不是全部的业务行为都需要业务方手动开发，有一些具备非常通用性的业务事件，支付宝把它们的埋点记录放到了框架层，如报活事件、登录事件。因此，行为埋点也可以叫做 "半自动埋点"。

（2）自动化埋点：属于“全自动化埋点”，用于记录一些通用的页面级别、组件级别的行为，比如页面打开、页面关闭、页面耗时、组件点击等。

（3）性能埋点：属于“全自动化埋点”，用于记录 App 的电量使用情况、流量使用、内存使用、启动速度等。

（4）异常埋点：属于“全自动化埋点”，严格上讲，也算是性能埋点的一种。但是它记录的是最关键的最直接影响用户的性能指标，比如 App 的闪退情况、卡死、卡顿情况等。这类埋点，就属于即时大促期间也不能降级的埋点！

图中的代码示例即为一条行为埋点样例，大家可以看到，埋点实际上就是一条 CSV 文本。我们可以看到里面有日志网关添加进行的地址位置信息内容，也有日志 SDK 给添加的客户端设备信息。

3. 日志处理模型

下面我们来整体了解支付宝内部日志处理的通用流程：

（1）日志切分

我们已经了解到，埋点实际上即为一段 CSV 文本。而所谓日志切分呢，即将 CSV 格式的文本转成 KV，通俗点说就是内存里面的 HASHMAP。这个切分的过程，可以直接根据逗号进行切换，当然也还有很多其他的办法。

（2）日志切换

日志埋点中的内容，并不是直接可以拿来进行分析的。比如客户端启动时间，相关数据是按照毫秒级别的颗粒度进行上报，但实际应用上我们只需要把数据分析到某个特定区间内的个数，所以在处理之前一般会做一个具体启动时间到截止时间范围编码的映射。除了这种转换之外，还会有一些白名单、黑名单之类的过滤转换。

（3）维表影射

因为客户端并不能拿到业务方需要分析的所有数据维度，如用户的性别、职业等内容，因此在真实分析之前，我们可以通过维表映射，将日志埋点中的用户 ID 映射成业务层面的具体属性来进行后续的分析。

（4）UID 的滤重

UID 滤重的指标有两种：一种是 PV 指标，一种是 UV 指标。

UV 指标在做具体的计算之前，要做一步 UID 去重。所谓 UID 去重就是指检查这个 ID 在一定时间范围内有没有出现过，如果出现过，那么这条记录就必须丢弃了。UV 是有时间周期的概念的，比如日 UV、小时 UV、分钟 UV、月 UV 等。

（5）指标聚合

在完成了上述的所有过程后，终于要进行指标的计算了。计算的方式包括求和、平均值、最大值、最小值、95 百分位。

（6）结果写出

就是指把计算的指标的结果输出到各种存储或者通过接口发送给 mPaaS 的客户。目前我们的计算方式有三大类，实时计算、即时计算和离线计算。下面我会介绍这三种计算方式。

• 实时计算

实时计算模式：接收到日志后，模型立即开始进行计算，数据结果将在N分钟(N