基于Sentry高效治理前端异常

一个前端项目上线后的各种指标监控是极其重要的，通过各种指标数据可以知道项目存在的问题及未来优化的方向，在各种维度监控中的异常监控是必不可少的，通过异常数据可以及时发现用户遇到的问题，而异常上报中的各种数据指标可以给解决问题提供参考及方向。

文章内所有异常上报及异常分析都是基于异常处理开源平台 Sentry ，其他异常处理平台或自建平台可根据实际情况参考。本文主要分为以下几个部分：

• 异常治理的重要性

• 前期异常数据处理

• 高效发现异常

• 高效解决异常

异常治理重要性

海恩法则指出: 每一起严重事故的背后，必然有 29 次轻微事故和 300 起未遂先兆以及 1000 起事故隐患。当一件重大事故发生后，我们在处理事故本身的同时，还要及时对同类问题的 “事故征兆” 和 “事故苗头” 进行排查处理，以此防止类似问题的重复发生，及时消除再次发生重大事故的隐患，把问题解决在萌芽状态。这个法则放在前端异常治理中同样适用，通过及时发现存在隐患的异常并及时解决，避免酿成重大事故。

用户体验

前端项目的用户体验是很重要的一环，特别是公司业务面向C端的时候，一个好的用户体验可以更高的促进业务漏斗的转化。

新增异常监控后，所有收到的异常数据都是实时的，异常发生时我们可以第一时间知晓且及时处理，对所有异常数据都要积极处理，不可敷衍了事，不能等到用户反馈时才打开异常平台修复问题，当你已经从其他渠道得到反馈有异常时，说明问题已经扩散到很大的范围了，这个时候才想起去看异常平台数据时没有将平台的作用最大化，也给用户带来了不好的体验。

这里说的第一时间及时处理，并不是随时都在观察是否有新的异常产生，我们只需要在关键的节点提高警惕即可，主要是系统发布新的功能时，但这并不局限于本系统，比如 App 项目中 H5 未发布，但是App发布了新的版本；后端接口发布了新的版本；用户升级了新的系统版本等会需要及时观察是否存在异常数据波动。除此之外可能还有设备兼容性问题，复杂业务操作等产生的问题，这类问题可通过其他手段监测及时发现，后面的文章会说明。

公司成本

某些异常是不影响用户使用的过程，比如组件卸载时未及时移除定时器或绑定的事件，虽然用户是无感知的，但是异常数据会源源不断的上报，如果这是一个日均PV上百万的项目，可想而知每天会产生多少新的数据，会造成多少网络流量的浪费。所以要及时处理异常，特别是高频发生，稳定复现的问题，减少网络流量及异常平台服务器的压力，及时减轻公司的运营成本。

前期异常数据处理

在解决问题之前需保证该异常数据是我们需要解决的问题，而不是无意义或干扰性的问题等着我们去处理，此类问题会影响后续的数据分析及降低解决问题的效率，以下处理方案大都可以在异常上报SDK中统一处理。

• 规范上报异常数据，规范上报异常标题格式，以及其他附加数据，如 sentry 中的 tag，additional 数据等，以便于在不同的项目中都可以快速参考分析问题，另外就是要规范异常上报的时机，除开被动上报异常，其他用户主动操作行为产生的异常要及时上报，如接口异常，复杂逻辑中特定时机上报异常记录分析。

• 部分异常过滤，针对某些框架底层异常或是已知业务场景正常接口异常等，可直接过滤处理，不再显示到异常平台中再次处理。这类异常过滤的过程可以在 SDK 全局进行过滤处理，针对不同的项目可额外增加不同的过滤条件，也可在异常平台针对某些重要性较低的项目直接过滤处理。

• 部分自动处理，自动处理分为几个情况：自动删除，自动标记解决，自动列为忽略异常。经过上面的过滤后的异常，会再一次过滤处理，这类处理的异常内容可以是某些业务场景需要上报的接口异常但不能归属于代码逻辑错误，比如提交订单时，某个新出的机型未在后台新增，触发这个异常后运营会立即处理，后续不会再发生。针对这类型的异常可以使用程序自动处理。

• 完善健康度所需各维度数据，判断一个项目产生的异常不能单纯的以数量为依据，还要根据当前项目的用户量结合计算，所以要把当前计算健康度所需的各维度数据都要提前准备好，提高后期健康度计算结果的准确性。

高效发现异常

经过以上的前期数据处理，接下来经过 SDK 上报到异常平台显示的数据就是我们要真正处理的异常数据。以转转举例，目前已经接入 Sentry 的前端项目有 **500+**，每天上报的异常数量约 250 万次，在如此大的体量下如何快速发现哪些才是目前紧急需处理的异常呢？

异常上报后需要针对性的处理，优先处理紧急核心项目及上报数据不正常的异常，可通过以下几个方式高效发现异常，这里的异常并不是指全部的异常，而是值急需处理的异常。

项目健康度排名

通过一系列维度权重配置，给所有项目计算出一个健康度得分，通过得分排序即可得出当前项目质量的好坏程度，通知对应的负责人及时处理。相关维度项及解释如下：

• 24小时异常/PV比例：近24小时发生异常数量与该项目PV数量占比情况

• 14天异常数量：该项目14天发生异常数量总计数值

• 24小时异常数量：该项目24小时发生异常数量

• PV：统计该项目昨日所有页面PV数量

• 是否核心项目：该项目是否标记为核心项目

健康度得分计算公式：每个维度权重占比可随时调整，调整后会立即重新计算得分并排名，可通过维度权重的调整来提高整体项目的质量要求。

sentry大盘异常监控

对异常平台内所有项目上报的汇总值监控，监控的指标有2个，突发异常数量过高，超出上一个区间数据的增量比例，另一个就是异常数据归零，没有收到任何异常，这种情况可能是短期异常太多导致平台崩溃或其他情况导致无法处理异常处理，针对这两个情况进行异常波动记录并触发企业微信推送。

项目异常监控

接下来就是针对项目级别的监控，但是作为一个集团大公司下的项目太多，对于一些异常数量极低的项目需要过滤处理，减小服务器的压力以及可以提升数据处理的速度。我们可以通过 Sentry 平台 Stats 中的项目进行监控处理，这里的项目可传入查询的时间段，这里最小时间段是小时级别，返回的是当前条件下新增的异常数量排名列表，我们只针对这个列表进行监控处理，由于需要更快速更准确的监控异常波动，基于这个列表再次查询每个项目5分钟内的新增异常数量，通过定时任务处理即可得出以下走势图，可快速发现某个时间段中的哪个项目出现了项目数据不正常的情况。针对这部分异常同样的也是进行异常波动数据存储及企业微信消息推送。

企微消息推送

以上2种情况最终都会触发到企业微信消息推送，因为消息推送的触达更为精准和迅速，但是也存在一些特殊的项目，比如夜间会定时任务可能存在过多的超时，本身 PV 量较高的项目所触发的配置数值有所不同。所以针对推送的部分增加了相关维度的配置，推送配置有推送区间，多少时间段内触发一次推送，推送时异常起点数量，增量异常比例以及是否开启推送。最终企业微信推送效果如下：

超时未处理提醒

上面的项目波动监控是针对项目整体异常情况的，除此之外还增加了针对项目内部具体异常解决情况的监控并推送，获取到项目内部所有异常，定期执行推送，在消息推送内容中标明当前存在的异常数量，针对超过3日还未处理的异常@对应负责人，以提高相关人员警觉。最终企业微笑推送效果如下：整体流程如下：

高效解决异常

经过上一步的发现异常，接下来将通过几个手段更加高效的解决异常，这个过程是基于公司内部现有情况处理，在不同的公司内部可能不一定适用，可参考处理。

知识库解决方案沉淀

目前各小组解决项目异常问题都没有沉淀具体的解决方案，但是大家所遇到的问题都是大同小异，很多场景下的异常问题其解决方案都是可以复用的。鉴于此，我们把解决问题的过程沉淀到内部文档知识库中，以供其他同学遇到类似的问题时，提供一定的解决思路，提高异常问题的解决效率。整体流程如下：

如该问题已有提交的文档记录，则进入异常问题详情页面时，右上角会有提示已解决方案参考地址，点击链接跳转到内部文档查看对应的解决方案。

内部文档搜索关联

研发同学都有记录文档的习惯，但是历史文档和 Sentry 并没有任何关联关系，所以在 Sentry 异常详情页面中新增按钮跳转到内部文档搜索，如有类似文档沉淀，则可以直接参考解决。

一键进入开发，内部系统打通

Sentry 本身是一套独立的开源项目，所以和公司内部其他的系统没有任何关联关系，导致无法和其他系统进行联动操作，比如创建分支，查询内部项目相关信息等。导致每次解决异常时都需要创建需求和分支才能进入到开发中，整个流程重复且繁琐。

基于这个背景在 Sentry 异常详情页面中增加一键创建需求和分支的能力，可快递进入到开发过程中。整个流程如下：涉及调用其他系统的接口较多，细节就不过多说明。核心就是基于异常详情中的页面地址解析出项目内部相关信息，基于这个数据创建tapd需求，创建项目仓库开发分支并和当前异常信息绑定记录。

自动分发接口异常责任人

现有项目中的接口异常占比约 80% ，导致需要花费大量的时间去沟通协调处理异常，处理的过程一般都是在 Sentry 监控平台发现是接口异常，再发送相应的接口请求数据及响应数据给到对应的后端处理，每次的沟通繁琐且耗费时间。基于这个背景优化整个沟通的过程，首先对异常上报的标题进行组装统一，以便后期可以检索时可以快速发现该问题属于接口层面问题。然后根据标题中获取到的接口地址从ZAPI(内部接口文档平台)平台获取到对应的后端开发人员，最后就是推送该接口异常情况到群聊@对应的开发人员。这里为了方便RD还原当前的请求场景，会再查询一次 Sentry 平台异常详情接口，在详情中获取到接口请求时的traceid，这样就不用再提供请求出入参数给后端人员了。

const = sendTitle = `${sendType}--${requestUrl}--${responseText}`

推送效果如下：整体流程如下：

总结

针对前端异常治理本文从两个方面说明了其重要性，然后在处理异常的前期增加了对异常数据的准确度的过滤处理，对过滤后的数据通过几个方式快速发现存在波动的异常情况，最后对需处理的异常增加了一些手段提高解决异常的效率。

异常治理的过程是一条漫漫长路，需要相关的同学一起努力才能有一个较好的结果，比如经过一系列手段可以发现很多不正常的异常情况，接下来就需要对应的同学快速处理且沉淀下来解决的过程以供后续其他同学参考，只有沉淀到一定的量后才会有比较显著的效果。

本文异常处理平台基于开源平台Sentry，其他平台处理逻辑类似，希望能给你带来帮助。

想了解更多转转公司的业务实践，点击关注下方的公众号吧！