Fork me on GitHub

网易云音乐全链路埋点管理平台建设

以下文章来源于网易云音乐技术团队 ,作者ZYF

一、背景

在文章云音乐曙光埋点:还原数据理想国中,我们介绍了曙光埋点项目方案,该方案基于多端一致埋点对象树建设管理,实现了统一自动化埋点和链路追踪,方案高度还原了大前端埋点的理想状态、具备较强通用性和扩展性。我们围绕这套埋点方案研发了配套的埋点管理系统,以承载及埋点规则数据管理、埋点设计、埋点研发、埋点测试、埋点上线等功能,本文主要介绍该平台功能及建设思路。

二、平台现状介绍

经过前几期建设,我们已经实现了一个适配研发流程的、按版本来管理的埋点数据管理平台,其核心功能为:

  • 1、承载埋点研发生命周期
  • 2、承载埋点的元数据管理

我们的研发生命周期如下:图片

平台在埋点元数据管理设计如下,参考和学习了版本管理工具的功能,并且充分考虑了客户端的研发流程特点图片

  • 1、客户端每个大版本需求研发时,BI对埋点需求进行分类,建立需求组。可以理解为基于Master CheckOut出了多个分支。
  • 2、BI在各需求组内,按埋点需求设计埋点。设计完成后,平台会计算出埋点的变更列表,如新增对象、新增血缘关系、修改参数、删除对象、删除血缘关系。
  • 3、上述变更由BI指派到任务,交由开发处理
  • 4、经过一个版本迭代开发后,若任务开发测试完成处于可上线状态,会被打上版本的TAG,并且发布上线,在Master产生一个新版本;未完成的任务,则可在后续版本迭代开发完毕后再上线。

相比版本控制工具,适配研发流程的版本控制具有以下特点:

  • 1、支持部分变更上线:需求内的变更可以自由筛选出来部分上线,可以类比为分支内提交数个文件,可以筛选出几个文件单独合入Master
  • 2、需要走研发流程才可上线:每个埋点变更都拥有独立的研发流程控制和校验。这些流程(设计完成->开发->测试通过)需要走完后,才准许合入Master。
  • 3、模型更加复杂:不是简单的文本,而是复杂的层级对象结构。

三、我们遇到的问题和痛点

在上述研发流程模式的落地过程中,我们发现了以下问题和痛点:

  • 1、落地质量问题

    • 漏埋:因为涉及较多埋点事件、埋点参数的组合,在某些组合下,埋点没有上报。
    • 错埋:埋点参数缺失或格式不正确。
    • 归因错误:埋点里的归因字段设置错误、不合理。
  • 2、落地效率问题

    • 大量重复埋点代码编写:如果涉及大量对象埋点,埋点工作势必成为大量重复劳动,影响研发效率。
    • 埋点进行增量变更时,无法知道改动了什么:平台只展示了某个埋点全量信息,并未展示其增量改动(没有类似版本管理工具的Compare视图)。
  • 3、功能痛点

    • 有一些埋点长期停留在研发阶段未上线(类比于写代码时开发分支落后Master多次提交,没有去Pull Master获取最新的主线代码改动),导致这些埋点很可能是过时的,如果不进行卡点直接上线,就会导致问题
    • 埋点数据是按APP+端两个维度隔离的,但实际运用时存在内嵌情况,如APP端可内嵌WEB端H5页面的功能,这种情况下,需要把原本隔离的数据进行整合,如把部分WEB埋点树挂载在APP端树上。

针对以上问题痛点,平台在近半年内进行了针对性的解决。

四、埋点质量建设

解决该问题的思路为先解决源头防止增量质量问题产生,再解决存量质量问题。

1、建设实时埋点校验功能,从源头解决埋点质量问题

客户端埋点开发完成后,需要进行"实时校验",从而对被指派的埋点任务进行测试覆盖,其步骤如下:

  • 客户端连接到实时校验平台,平台根据该任务需求,生成埋点校验树

  • 客户端上报日志,平台根据埋点校验树进行校验

  • 平台根据测试情况,决定测试是否通过

    • 需求范围内有埋错:不通过,且可以查看日志看到具体为何不通过,如下图所示图片
    • 需求范围内有漏埋:默认不通过,但事实推进落地中,存在部分分支客户端难以复现覆盖的情况,因此我们也支持了勾选某些分支无需测试的功能,如下图所示图片
  • 若测试为不通过,则将卡点阻塞流程,后续无法正常上线

经过实时埋点校验功能的上线后,我们封堵住了大部分埋点错误源头,达到了较好效果。



2、建设线上埋点稽查功能,发现存量埋点问题并推进解决

稽查功能定位为企业日志的统计分析,解决以下问题:

  • 1、分析日志是否按规则正确输出,检测出少参数、参数取值错误、归因错误等问题,并对这类问题进行归类,并可进一步钻取,直至能够看到原始日志的样本。
  • 2、自定义灵活业务统计监控、报表、报警。通过监控、报表中数值变化报警来发现、辅助定位端上发版后一些bug。如:某些点位日志变少、PV/UV比例变化等。

为实现上述功能,需要对日志进行采样分析计算(可以理解为打上各种标签),并且将计算结果存储在能够支持筛选、统计查询功能的数据库中,为典型的OLAP场景,我们选型时,采用了ClickHouse来完成这块功能,其主要考量点如下图所示

图片

经过稽查功能上线和推进,我们的线上埋点错误数已经下降了95%,并且还在逐渐降低中,达到了较好的效果。

五、埋点效率建设

  • 使用模版引擎自动生成代码 上文提到,埋点时涉及大量重复埋点代码编写,我们针对该问题使用模版引擎语言自动生成埋点代码,且支持适配了安卓、iPhone、Web、RN等多套客户端,把代码提前生成好,能自动填写的部分全部自动填写,客户端复制代码后只需要把代码模版里剩余部分补全即可,如下图所示图片
  • 展示埋点DIFF,让开发更容易理解埋点改动点

我们开发了埋点DIFF功能,相比与版本管理软件中的代码文本对比,埋点元数据是一种更加复杂的数据结构,因此在服务端计算DIFF和前端界面展示DIFF上相对来说较复杂一些。如下图所示,我们通过在原有界面上通过背景色来区分变更操作是新增、修改、还是删除。图片

六、研发中埋点自动Rebase到最新Master

前文提到,有一些埋点长期停留在研发阶段未上线,目前没有pull master的功能,导致:

  • 1、这些未上线埋点元数据很可能是过时的,如果直接上线会导致业务问题。
  • 2、无法使用到最新Master下的新增对象,或者还在使用已删除对象

因此我们对在需求池内未上线的研发阶段对象,每次上线后,都自动pull master处理。如下图所示为一个未上线需求从安卓8.8.11 Rebase到 安卓8.8.12的过程,rebase后可能存在部分变更需要删除或重新研发。

图片

rebase算法的核心在于计算出Master和本研发分支对比同一个基线的原子改动列表,并尝试依次合并,并将合并后的变更应用到基线上。其流程图如下:

图片

其中变更合并时的逻辑如下:

图片

人工冲突解决时,我们采用了上文“展示埋点DIFF”的功能,让埋点设计人员同时看到两方改动,并在界面中录入最终合并结果。

七、埋点跨空间打通

云音乐业务存在多个业务线,他们的“埋点空间”是相互独立的。但云音乐存在内嵌业务的情况,如云音乐APP下可内嵌LOOK直播APP、以及WEB端的H5页面等,即使云音乐APP不发版,内嵌的业务的埋点也可能会发生变化。因此需要把内嵌业务对应的的埋点树“桥接”到当前APP埋点中。针对这种诉求,我们研发了“桥梁”模式,如下图所示:图片

  • 桥梁为一类特殊对象,用于衔接父子空间,如图示为衔接云音乐APP和WEB H5两个独立的埋点空间,其中云音乐APP是父空间,WEB为子空间
  • 桥梁在父空间定义
  • 子空间对象可设置挂载在父空间桥梁下
  • 父空间展示埋点树时,只关心到桥梁为止
  • 子空间展示埋点树时,会把桥梁以上所挂载的父空间树也展示出来
  • 内嵌开发完毕后,需要使用父空间APP验证子空间的带桥梁埋点是否正确,其SPM为带父空间的完整路径

此外由于埋点按版本管理,因此埋点树若变化,必须要在平台内产生新版本,因此:

  • 子空间发布,父空间不需要发布新版本,因为子空间埋点树对父空间不可见
  • 父空间发布,若涉及桥梁更改,则会改变子空间埋点树,此时需要在子空间同步发布一个新版本

八、未来规划

在埋点领域中,除了纯客户端埋点,还有服务端埋点,以及双端共同完成的混合埋点,常见的混合埋点包括:

  • 服务端下发的字段,客户端需要打到客户端埋点里
  • 客户端上报的字段,服务端需要打到服务端埋点里

此类需求广泛存在,但未在本平台上进行管控,其流程、效率、效果是不可控、不可监控的,后续平台将把服务端埋点及服务端+客户端混合埋点也平台产品化并进行管控。

图片

此外,网易云音乐全链路埋点管理平台前后端、客户端SDK等组件都将在近期贡献到开源社区,为业界带来更大价值。


本文地址:https://www.6aiq.com/article/1673953869164
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出