腾讯 NOW 直播的前端监控体系建设案例

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务，在发生故障时难以准确定位。因此，需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。全链路监控组件就在这样的问题背景下出现了。

腾讯 NOW 直播相比其他直播平台虽然起步较晚，但是成立三年以来， IVWEB 团队在对业务进行优化的同时，在实践中不断沉淀，沉淀出了一套比较完善监控方案。让我们一起来看，IVWEB 团队是如何利用该方案在大前端场景下既提升自身业务问题的解决效率，又降低维护难度的？

腾讯高级 Web 前端工程师何方舟老师将在 12 月 20 日～21 日举行的 GMTC 全球大前端技术大会 (深圳站) 上分享《NOW 直播在大前端时代下的监控体系建设》。InfoQ 在会前采访了何方舟老师，让我们一起来看 IVWEB 团队是如何实现大前端监控解决方案的？希望给正在实践全链路监控的你带来一些参考。

InfoQ：请您简单介绍下自己以及所负责的工作。

何方舟： 我是何方舟，来自腾讯 IVWEB 团队，2016 年加入腾讯，先后参与 NOW 直播 SDK、手机 QQ 附近动态、腾讯直播等与直播相关的泛娱乐产品的 Web 前端开发。除了业务需求开发之外，在团队技术建设上负责团队性能优化、Node 服务建设、监控体系的搭建，以及前沿技术 PWA、WebAssembly 等在实际业务中的落地。

InfoQ：作为前端监控开源项目 Aegis 作者，请您简单介绍下这个项目的背景及意义。

何方舟： Aegis 的含义为宙斯盾，旨在提供一套开源且功能完善的一站式前端监控解决方案，目前团队内有 5 名成员在共同维护。

在聊 Aegis 之前，我想先介绍一下 Aegis 的前身 BadJS。

BadJS 是一款腾讯在 2015 年推出的前端异常监控开源方案，在当时的业务环境下 BadJS 很好地承担了业务中监控异常的任务。但是随着业务发展团队扩张，我们也面临了更加多元化的业务环境。此时，单一的异常监控能力，并不能快速地帮助我们发现和定位问题。我们尝试在业务中引入了其他工具来帮助解决这个问题，这导致我们的监控体系变得越来越臃肿，项目维护难度增大，降低了研发效率。

在调研行业内其他的监控方案后，我们并没有发现符合我们要求的解决方案，在和公司其他团队交流后发现，大家也有遇到同样的困扰。考虑到我们团队本身就有维护 BadJS 的经验，于是我们决定对 BadJS 进行二次开发，提出了 Aegis 前端监控方案。将前端监控中所需要的异常监控、测速服务、性能分析以及流水日志能力等整合到唯一平台，降低接入成本， 提供维度更加丰富的查询手段，帮助开发者快速准确的发现和定位问题。

InfoQ：在 NOW 直播的监控体系建设中遇到的最大的挑战是什么？是如何解决的？

何方舟： 我们遇到的最大挑战应该是监控平台太多。

腾讯针对前端的监控系统非常繁多，但各个平台功能点侧重点又不一致，以前面的提到的 BadJS 为例，它只关注异常错误监控，如果要接入测速，接口成功率等监控，又需要接入其他平台。导致前端监控接入开发成本高，工具使用繁琐。在新人入职、项目交接时，理解这些平台各自存在的意义，开发的同学叫苦不迭。

在腾讯提倡开源协同的背景下，公司层面也开始建设统一的监控平台。我们团队和腾讯云合作，以业务方真实遇到的业务监控痛点出发，统一整合了各种监控平台能力，Aegis 就是其中的一个成果。

InfoQ：在 NOW 直播的监控体系中，目前性能的优化成果有哪些？

何方舟： 第一，我们完成了上报端的 SDK 重构，使用 TypeScript 重写，测试覆盖率 100%。同时 SDK 做到了 Web、小程序、React Native 的三端同构，极大地节省了我们在多端开发效率。

第二，做到了无开发侵入性地上报。通过针对性地分析了技术方案的一些共性，首先统一了我们的上报标准，定义了关键节点的上报，如加载成功率、接口失败率等。同时，我们在团队内推广统一开发脚手架，内置上报埋点，再结合浏览器或其他平台和开发框架提供的 API，减少了开发接入成本。

第三，打通了客户端日志，结合对客户端能力的扩展，做到了 C 端的全链路日志，客户端同学和 Web 同学都可以分析对方日志，提高了问题定位速度。

InfoQ：您认为大前端时代下监控面临的挑战是什么？我们该如何应对？

何方舟： 我认为如何合理地收集到准确的数据，是大前端时代下监控面临的一个挑战。

大前端时代，各团队的业务往往会覆盖移动 Web、Hybird App、PC Web、React Native、小程序以及一些自研的动态框架。单纯平台内的一些数据并不能反映出整个应用上面的情况，开发者应该熟悉全链路的架构，才能制定出正确的数据上报标准。

以首屏时间来说，传统的首屏打点计时，是从页面加载到完成作为标准。但是启动 WebView 以及用户点击后的一些前置操作（如鉴权校验等）也会有明显的耗时，部分低端机型这些部分耗时甚至会超过 3s。这部分耗时浏览器本身是无法获取的，所以我们需要多方协作才能拿到准确数据。

另外，单用户的访问链路往往会横跨多个平台。在追踪还原问题的时候，问题根源可能是由上下游联动产生。各平台本身会有一套监控体系，但是由于平台差异，形成了日志孤岛。其次，由于平台时间的差异，再对跨平台日志进行关联时，存在日志乱序的情况，无法还原用户的真实操作路径，进一步降低了排查效率。所以，打通不同的平台，形成统一的上报标准也是我们需要应对的问题。

InfoQ：在 NOW 直播的监控体系建设中，有没有什么通用的业务场景经验是其他监控可以借鉴的？

何方舟： 总结下来有两个点是可以和大家分享的。

第一，统一全平台的上报标准。结合具体的业务场景下（比如 SSR 场景和非 SSR 场景，SPA 和 多级页面）制定相应的上报点规范，定义关键节点。如打开成功率、渲染成功率以及接口耗时规范等。同时，定期对日志内容进行 Review， 杜绝日志上报中无意义或含义不明。

第二， 降低监控侵入性，避免手动埋点式的上报。这一点非常重要。从我们以往的经验来看，依赖手动上报的监控方式，经常会出现线上问题发生后，才发现忘记上报。其次，由于项目交接、技术方案变更、新维护者对架构不熟悉等问题导致手动上报数据不准确。所以，做到无开发侵入性的上报，让监控在开发层面对使用者透明非常重要。

InfoQ：NOW 直播的监控体系未来有什么发展路径？

何方舟： 总的说来现有的监控体系已经比较完善，我们也在持续深挖监控体系中的一些点。

第一，对于监控系统来说，数据收集、上报行为本身还有进一步的优化空间。例如，最近我们在 HTTP2 的基础上部分灰度了 QUIC 协议，请求延时降低了 10% 左右。

第二，全链路日志建设，目前我们打通了 C 端的日志。接下来，如何结合公司后台服务的全链路日志服务，打通后台服务日志，是我们要解决的问题。

最后一点，提升平台帮助定位问题的效率。我们已经尝试在使用 AI 对线上问题做一些更深维度的分析，做到智能化的问题聚类。

活动推荐

在即将到来的 GMTC 深圳 2019上，何方舟老师还会具体分享到，大前端时代下监控面临的挑战、如何降低开发人员对监控上报的抵触以及 Aegis 监控方案详细介绍。让正在学习全链路监控的你，了解大前端监控体系的内容与作用、预防与排查常见问题。希望腾讯 NOW 直播的监控案例为你提供新的思路。

除了何方舟老师的分享，本次 GMTC 全球大前端技术大会（深圳站）2019 我们还设置了小程序挑战与应对、音视频技术、Serverless 实战、测试与安全、大前端工程化、Flutter 实战、新兴编程语言、团队建设与管理等热门技术专场。