导读：随着业务快速迭代发展，系统对业务的监控、优化不再局限于行为、性能监控。前端异常监控更能反应用户端的真实体验。精细化的监控可以及时主动发现问题减少损失，针对性的分析治理甚至能带来业务增益。本文结合广告托管团队异常监控治理的经验，介绍从异常打点收集、报警监控、排查分析、治理优化的实战总结。
全文字，预计阅读时间19分钟。
一、前言行为、性能、异常打点是前端领域的老生常谈，实践层面很多团队对这些打点的应用范围也是：行为性能异常。这不难理解，行为统计从团队收益角度来看，短期内更加直观，甚至有一些打点本身就是业务需求，如功能上线后的PV、UV统计等。一般对于线上服务来说，后端异常监控是必须项，服务异常的主动发现也多从后端来，前端的异常监控能扮演什么样的角色呢？加入这样的投入从管理者角度来看是划算的吗？异常怎么监控能更快的发现并引导止损？面对这些问题，很多业务的前端异常监控工作，还没开始就结束了。我们团队在实践中总结了一些思考和经验，希望能对读者有一点帮助。1.1业务背景介绍我们是百度广告托管业务，承接着众多行业的站点建设工作。这其中包含移动/桌面端的web站点、小程序、HN（百度App的类ReactNative方案）等多种载体，每天有大量的访问流量。对于网民来说我们要保障流畅的阅读、交互体验。对于广告主来说，我们要提供高质量保障。通过前端异常监控与治理，业务团队收获了提前发现问题、及时止损，优化广告效果等诸多收益。1.1.1要解决什么问题如文章一开始介绍，业务发展的相当一段时间内，团队的重心一直在后端的监控和报警完善上。但当我们将服务的稳定性治理达到一定的标准后，发现一些线上问题仍然难以召回，例如页面整体或某些部分渲染异常，影响体验甚至广告转化和成本。可能造成的原因举例：静态资源加载异常，包含script资源、图片素材等API访问异常JS执行异常相较后端异常监控，资源加载、JS执行异常都是前端异常监控带来的增量场景，端到端的接口稳定性更接近用户的真实感知，更能表明网络对稳定性带来的影响。小流量场景提前发现问题产品的发布往往需要小流量、AB测试的验证。或者某些问题仅在一些特定场景下触发，因为流量限制，很难通过服务数据波动发现，随着扩量造成更大负向影响或客户投诉后才被发现。前端异常监控能很好地帮助我们解决这些场景的问题。下面将从异常收集、完善监控报警、异常排查、异常治理几个阶段，介绍我们的主要工作和经验。说明：本文更多从业务应用视角讨论问题，对于通用的埋点接受服务、数据处理、展示平台不做太多探讨，所幸团队已经有这样的专业人员和平台。结合我们的业务场景需求，和平台共同设计并支持了通用监控之外的业务异常监控，后面会介绍。二、异常收集第一步，我们要把异常情况，以打点的形式发送至收集服务。这包含很多文章提到的通过window监听捕获到的error等通用方案，还有一些更加隐蔽，但对业务有很大影响的业务异常。2.1通用异常收集通用异常收集是一种无侵入的异常收集方式，无需业务开发者主动表达，在系统发生异常时，通过事件的冒泡、事件捕获或者一些框架提供的hook函数来进行错误的收集。针对页面中异常进行收集时，主要会涉及两类场景:由于网络请求导致的资源加载型异常，比如图片加载失败、script链接加载失败由于运行时导致的异常，这类异常多数是由于一些代码的兼容性或者未考虑到的边界情况产生的针对资源加载异常，业务中会有以下两种监控方式：使用资源自身的onerror事件，在资源加载失败时将错误上报出去。这种场景一般需要借助打包工具，在代码打包时，针对相关的资源添加onerror的逻辑，例如使用script-ext-html-webpack-plugin针对所有script标签添加onerror属性。利用：window.addEventListener(error,fn,true)针对运行时产生的异常,通常我们使用以下方式进行监控：页面顶层添加如下事件：
window.onerror或window.addEventListener(error,fn)但这种处理方式也有其局限性，针对未catch住的promise产生的异常无法进行捕获，所以在业务使用时，一般是额外再添加一个事件监听方法来捕获未被处理的promise异常。
window.addEventListener(unhandledrejection,fn)针对运行时产生的异常，一些前端框架也给我们提供了配置方法来简化我们的日常开发。React框架：在React16之后，框架支持