关于前端:网易云音乐大前端监控体系Corona建设实践开篇

本文作者：轻山

网易云音乐大前端监控产品（代号：Corona）反对 Web、React Native、Node.js、Flutter、Android、iOS、Windows CEF 多种利用类型。以后已接入了网易团体包含云音乐在内数十个事业部的大前端利用，为业务提供异样、性能监控、问题排查、实时告警等能力。

背景介绍

Corona 异样监控局部的产品研发是从 2020 年初开始的，过后云音乐大前端团队内不同的职能应用着不同的开源 or 商用监控产品。

前端团队私有化部署了 Sentry；Android 团队同时接入了网易团体的云捕和腾讯的 bugly；iOS 团队次要应用 Google 的 Firebase Crashlytics；桌面端团队（Window CEF 利用）则没有平台型的监控产品，上报异样日志后再应用 breakpad 工具解析日志来排查问题。

这些割裂的产品在理论业务应用中存在如下问题，导致未能无效的度量利用品质、发现和治理线上问题：

1. 有效日志问题，大前端 – 特地是 Web 利用运行环境简单，有很多异样日志都是运行环境导致的而非代码逻辑 bug，并不影响用户，比方各种第三方浏览器注入的代码、插件注入的代码、弱网导致的申请失败、爬虫引发的报错等，这些日志重大烦扰了开发者排查问题的效率；
2. 告警问题，不同产品告警性能的设计差别很大，有的是利用整体基线类告警，有的是单问题视角的趋势告警等等，无奈制订对立的告警闭环策略；
3. 流程闭环问题，团队规模大了之后，依赖简单的研发流程能力高效运行，离散的监控产品凋谢能力参差不一，成为了流程中的断点；
4. 查问剖析能力，在排查疑难问题时，须要特定维度下准确的事件数和影响用户数、工夫趋势，以及此维度下其余特色维度的散布状况，这一能力在其余产品中都是缺失的；
5. 自定义上报能力，业务非凡的运行状态须要被动上报自定义日志进行监控，并给出趋势、维度散布等统计数据，并具备告警能力，这在其余产品中都比拟单薄；
6. 简单问题的排查，须要联动其余业务埋点、网络日志等跨平台组合上下文进行剖析；
7. 业务视角的品质、体验度量，须要跨利用类型、综合多平台的日志做大数据分析，这和以上「简单问题的排查」都须要原始日志成为团队可齐全掌控的数据资产；

而且随着云音乐开始推动 React Native 跨端技术栈后，不同职能角色的边界被突破了，大前端团队也做了合并，割裂的监控产品对职能角色交融、单干、研发流程的收敛造成了很大的妨碍。于是建设一个跨多职能角色的、笼罩所有业务状态的、产品能力和数据资产把握在团队本人手中的监控产品就此开展。

非功能设计

监控产品的价值是疾速发现异常、疾速定位问题以及辅助利用修复故障、晋升品质与性能。同时思考到团体内事业部泛滥，在通用性根底上也要具备肯定的业务数据定制化解决。为了做到这些，咱们对 Corona 的非功能设计做了如下要求：

• 实时性高：在异样发现、处理过程中，信息的价值会随着工夫锐减；
• 全量数据：产品定位是从异样监控畛域切入，不放过每一条异样日志；
• 高可用：必须比被监控的利用更稳固，能力在利用无奈失常运行时通知开发者产生了什么；
• 高吞吐：要有超强的日志解决吞吐能力；
• 故障容忍：Corona 自身的 SDK 以及服务不应该影响业务失常运行；
• 可扩大：非凡服务节点可插拔、可替换设计；

为了达到以上技术指标，咱们对整个零碎的架构设计如下：

其中：

① 是日志上报、接管、采集的链路。云音乐的日志上报服务对接了外部其余中台服务，能够依据日志携带的 cookie 解析出用户 id 等业务属性的信息，这对后续排查具体问题很有帮忙。因而这个服务节点也被设计为可替换的，替换为其余事业部的中台服务从而在日志中主动塞入更多业务属性的信息。

② 是在屡次突发大流量导致系统解体后退出的分流服务。该服务会辨认异样、性能、流量日志而后分流到不同的应用层生产服务中去，其中异样日志生产服务实时性最高、日志流量最小；性能日志生产服务流量最大、对实时性要求最低；利用流量计算服务实时性高、日志流量居中。分流后能够确保 3 种日志生产服务相互解耦，不会因为一种日志突增而导致所有服务都挂掉，也能依据不同的日志的流量大小、生产老本配置正当的服务器资源，达到降本的目标。

③ 是针对异样日志生产服务的设计。异样日志生产服务是一个近似实时的批处理工作，设计有等同于上游音讯队列分区数的生产过程，每一个过程会积攒 30s 的日志量或者 3000 条日志后进行批量生产（30s 和 3000 条是由配置核心下发的），这个配置能够随着日志流量的变动调整，在实时性与服务器负载之间取舍。将生产服务设计为近似实时的批工作也是为了升高数据库操作的 TPS，晋升日志生产服务的稳定性，极其状况下即便日志流量突增百倍，MySQL 和 ES 的写入 TPS 只会减少数倍。

④ 是中心化的日志过滤性能，目标有两个，一是紧急应答忽然呈现的流量顶峰，保障稳定性；二是为用户提供过滤服务，使用户能够很便捷的抛弃噪声数据。过滤配置在应用层的生产服务节点和数据链路层的日志分流服务节点均能够失效。生产过程从 kafka 订阅到日志后，会读取配置并判断是否要抛弃，然而当线上日志量突增了百倍千倍后，曾经达到并发生产能力的下限，仅仅执行过滤计算都曾经变成了 cpu 密集型操作，这个时候就能够在更前置的分流服务节点配置抛弃日志，保障应用层服务稳固。

⑤ 是将能异步实现的性能都通过定时工作来实现，比方告警检测、日志的谬误类型剖析、反混同等等，使得同步解决链路最精简，同时及时这些异步工作挂了，也不会影响监控主流程的服务，只是局部性能缺失。

⑥ 将原始日志存储到 HBase，作为数据资产备份，同时凋谢给业务自助剖析、或者其余平台进行用户链路剖析。其余存储中间件的数据作为 Corona 的公有资产，为具体产品性能提供服务，只通过凋谢接口进行查问。

Corona 与其余开源 or 商业化产品在架构设计上的外围差别可总结为以下两点：

1. 加强存储层的能力，多数据引擎 + 冗余存储，为应用层简单功能设计和数据凋谢提供撑持；
2. 轻量化数据采集，重数据链路和消费层的设计，比方不同类型日志的分流、独立生产链路、日志过滤、特色信息提取、堆栈解析等，使得大部分新性能的上线、变更无需接入的利用降级 SDK；

篇幅无限，对于 Corona 平台的整体架构就介绍到这里，将来会对具体节点独自写文章开展介绍，敬请期待。

适配多端的日志协定

Corona 定义了适配多端的、可扩大的日志协定，各端 SDK 采集并生成合乎该协定的日志。

Corona 定位是适配大前端多端技术栈的监控产品，不同技术栈利用的编程语言、研发流程、运行形式等等都有很大的差别，对于线上异样的剖析、解决流程也不尽相同。Corona 设计了可扩大的日志协定，配合多态设计模式的软件架构，实现对不同技术栈的适配以及新利用类型的疾速接入。

不同技术栈的利用对一个异样事件形容的差别，实质上是数据结构的差别，大前端畛域编程语言的不同并不会导致监控性能的变动。Corona 的日志协定解构如下：

异样对象 是一条异样日志的最小外围单元，多端统一，由异样类型、异样形容和异样堆栈 3 局部组成，生产服务的主链路即是对异样对象做解析、聚合解决。同时应用层查问服务会提供此最小外围单元 准确搜寻 和 含糊搜寻 两种查问能力。

特色维度数据 用于残缺形容异样产生时的环境信息，例如图中所示的日志工夫、设施型号、利用版本、操作系统等等根底信息，同时也会针对不同技术栈的利用采集独有的特色信息，比方：

• React Native 利用，bundle 包版本，RN 框架版本等
• Android 利用，是否 root，利用下载渠道等
• Node.js 利用，Node 版本，主机名等

应用层的查问服务会提供所有特色维度数据 准确搜寻 和 散布统计 两种查问能力。

上下文扩大数据 用于补充形容异样产生时的上下文信息，帮忙开发者还原现场、定位问题。包含但不局限于：

• Web 利用，异样产生前的用户行为数据，点击、申请、页面跳转、控制台输入等信息；
• Android 利用，异样产生时的零碎运行状态，内存占用、CPU 负载等；
• iOS 利用，异样产生时的系统日志；

这部分数据反对用户侧高度自定义，追随异样日志上报，平台侧只做关联展现，查问服务不提供针对其内容的含糊搜寻能力。

可扩大的日志协定配合多态模式的软件架构，使同一个性能在不同技术栈利用上有差异化实现形式，最终使用户在产品侧体验统一。

例如异样堆栈的源码还原性能，用户在平台侧能够体验到 Corona 在 Web、Node.js、React Native 利用中均提供了如右图统一的源码还原性能，但实际上在整个零碎的 Client 层和 Server 层，针对不同利用类型对源码还原的实现是齐全差异化的。

Web 利用在构建时由打包工具产出 SourceMap 文件上传至 CDN，同时在打包后的资源中记录该文件和对应的 SourceMap 文件的映射关系，JS SDK 捕捉异样日志上报后，生产服务会解析堆栈并下载线上 js 文件，而后依据映射关系下载 SourceMap 文件，最初依据堆栈记录的行列号找出对应的源码，存储后提供后前端展现。

Node.js 利用的 SDK 在捕捉到异样时，会间接解析堆栈并读取堆栈中关联的、产生异样的文件，依据行列号截取源码片段，作为附加信息携带在异样日志中上报。生产服务仅做存储后提供给前端展现。

React Native 利用的源码还原过程相似 Web 利用，在生产服务中下载 bundle 文件后依据异样堆栈记录的行列号查找源码片段。

各端 SDK 的设计将来会独自写文章开展介绍，敬请期待。

功能设计

在面向用户的功能设计上，把指标形象如下：

1. 具备一个监控产品外围的能力，比方异样捕捉、异样剖析、可视化界面、告警等；
2. 能反对云音乐所有大前端技术栈的利用；
3. 能满足大型研发团队协同应用；

在综合了各职能团队应用不同监控产品中积攒的问题后，以异样监控为例，咱们为 Corona 划分了如下 10 大功能模块进行具象化的设计。

这些功能模块都曾经产品中上线，接下来从用户视角做简略预览：

1. 利用实时质量指标、趋势

数据提早约 1 分钟，提供利用维度整体的质量指标以及工夫维度的趋势数据。

2. 异样精准聚合

• 解析上报堆栈，辨认要害信息，聚合；
• 主动计算聚合后异样的趋势、工夫范畴、版本范畴、影响用户数等要害信息；

3. 中心化数据去噪

误上报的日志，不影响利用性能的、由环境导致的异样等，可在平台上中心化的自定义过滤规定，作用粒度可达到单条日志级别；

过滤规定实时失效，无需下发至利用。

4. 特色信息提取及散布统计

帮忙用户在大量异样日志中疾速找到共性的特色。

5. 准确搜寻能力

Corona 提供多种特征值的准确搜寻能力和针对堆栈信息的含糊搜寻能力。

相比 firebase、bugly、Sentry 等同类产品，Corona 的准确搜寻能力体现在，无论是利用还是聚合 issue 维度的指标、趋势，都会随着搜寻条件准确计算。

6. 堆栈解析

无论哪种利用，Corona 均反对对堆栈进行解析使之成为可读堆栈，或是采纳 SourceMap 计划，或是反对反混同，或是符号化解析。

所有的解析过程均提供自动化的流程，诸如 mapping 文件、符号表等对接一次即可。

7. 多维、多通道告警以及告警克制

• 多维告警

  • 阈值告警模型：作用于单条异样 issue，间断工夫内数量超过肯定值时触发；
  • 环比告警模型：作用于单条异样 issue，数量突增触发；
  • 基线模型：利用 or 利用版本的异样率超过基线时触发；

• 多通道

  • 邮件
  • popo
  • 短信

• 告警克制

  • 高频克制
  • 梯度克制

8. 自定义上报

依照上文数据传输协定，Corona 对所有利用类型均凋谢自定义上报的能力，用户可用于新增埋点辅助剖析疑难问题，也能够用于减少业务属性的指标。

9. 状态流转、用户交互、工单机制

Corona 具备 gitlab issue 的调配、评论性能，评论反对 markdown 格局书写，小型团队可应用此性能实现异样的闭环解决。

大型研发团队，Corona 反对对接工单零碎进行建单。

10. 前沿摸索型性能 -AI 剖析

Corona 会跟进业界一些具备实用价值的技术热点，比方 ChatGPT，为用户带来更快捷的堆栈剖析、信息检索。

后记

Corona 上线已有 3 年工夫，这期间除了不断完善产品性能，也在云音乐的大前端业务治理中施展着重要的作用，并陆续为网易团体多个事业部提供了服务，是通过简单业务验证过的一款监控产品。
本文作为云音乐大前端监控体系建设的开篇，以宏观的视角、从异样监控畛域切入对整个产品做了一次综述类的介绍，之后会围绕这个产品写一个系列专题，由粗到细进行开展，如有想法能够多多交换。

本文公布自网易云音乐技术团队，文章未经受权禁止任何模式的转载。咱们长年招收各类技术岗位，如果你筹备换工作，又恰好喜爱云音乐，那就退出咱们 grp.music-fe(at)corp.netease.com！