关于后端:网易云音乐全链路埋点管理平台建设

图片起源：https://unsplash.com

本文作者：ZYF

一、背景

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

二、平台现状介绍

通过前几期建设，咱们曾经实现了一个适配研发流程的、按版本来治理的埋点数据管理平台，其外围性能为：

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

咱们的研发生命周期如下：

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

• 1、客户端每个大版本需要研发时，BI 对埋点需要进行分类，建设需要组。能够了解为基于 Master CheckOut 出了多个分支。
• 2、BI 在各需要组内，按埋点需要设计埋点。
  平台会计算出埋点的变更列表，如新增对象、血统，批改参数，删除对象、血统等。
• 3、上述变更由 BI 指派到工作，交由开发解决
• 4、通过一个版本迭代开发后，若工作开发测试实现处于可上线状态，会被打上版本的 TAG，并且公布上线，在 Master 产生一个新版本；未实现的工作，则可在后续版本迭代开发结束后再上线。

相比版本控制工具，适配研发流程的版本控制具备以下特点：

• 1、反对局部变更上线：需要内的变更能够自在筛选进去局部上线，能够类比为分支内提交数个文件，能够筛选出几个文件独自合入 Master
• 2、须要走研发流程才可上线：每个埋点变更都领有独立的研发流程管制和校验。这些流程 (设计实现 -> 开发 -> 测试通过) 须要走完后，才准许合入 Master。
• 3、模型更加简单：不是简略的文本，而是简单的层级对象构造。

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

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

• 1、落地品质问题

  • 漏埋：因为波及较多埋点事件、埋点参数的组合，在某些组合下，埋点没有上报。
  • 错埋：埋点参数缺失或格局不正确。
  • 归因谬误：埋点里的归因字段设置谬误、不合理。

• 2、落地效率问题

  • 大量反复埋点代码编写：如果波及大量对象埋点，埋点工作势必成为大量重复劳动，影响研发效率。
  • 埋点进行增量变更时，无奈晓得改变了什么：平台只展现了某个埋点全量信息，并未展现其增量改变（没有相似版本管理工具的 Compare 视图）。

• 3、性能痛点

  • 有一些埋点长期停留在研发阶段未上线（类比于写代码时开发分支没有 pull master），导致这些埋点很可能是过期的
  • 埋点数据是按 APP、端隔离的，但线上存在内嵌状况，如 APP 端可内嵌 WEB 端，这种状况下，须要把 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 等组件都将在近期奉献到开源社区。