一个前端项目上线后的各项指标监控是极其重要的。通过各种指标数据，了解项目存在的问题和未来优化的方向，从各个维度监控异常情况。这是必不可少的。通过异常数据可以及时发现用户遇到的问题，异常报告中的各种数据指标可以为解决问题提供参考和方向。本文所有异常上报和异常分析均基于开源异常处理平台Sentry，其他异常处理平台或自建平台可根据实际情况参考。本文主要分为以下几个部分：异常治理的重要性异常数据的早期处理异常的高效发现异常高效高效的解决异常治理的重要性海恩定律指出：每一起严重事故的背后，必定有29起小事故和300起小事故有惊无险的预感和1000起潜在事故。当发生重大事故时，我们在处理事故本身的同时，也要及时排查处理类似问题的“事故征兆”和“事故征兆”，防止类似问题再次发生，杜绝重大事故再次发生。及时处理事故。把事故隐患和问题解决在萌芽状态。这个规则同样适用于前端异常管理。及时发现隐患，及时解决，才能避免重大事故的发生。用户体验前端项目的用户体验是非常重要的一环，尤其是当公司业务面向C端时，良好的用户体验可以进一步推动业务漏斗的转型。加入异常监控后，所有收到的异常数据都是实时的。当出现异常时，我们可以第一时间知道并及时处理。所有异常数据都要主动处理。不能敷衍，不能等待用户反馈。打开异常平台修复问题。当您收到其他渠道的反馈有异常时，说明问题已经大范围扩散。这时候我想起来了，在看异常的平台数据的时候，没有把平台的作用发挥到极致，给用户带来了不好的体验。这里第一时间处理不是随时观察有没有新的异常。我们只需要在关键节点保持警惕，主要是系统发布新功能的时候，但不仅限于此，比如App项目中，H5还没有发布，但是App发布了新版本；后台接口发布新版本；用户升级新系统版本等，需要及时观察数据是否有异常波动。此外，还可能存在设备兼容性、业务操作复杂等问题。此类问题可以通过其他监控手段及时发现，后续文章会详细介绍。本公司费用部分异常，不影响用户使用过程。比如卸载组件时，没有及时移除定时器或者绑定的事件。虽然用户没有察觉，但异常数据会不断上报。如果这是一个日均PV过百万的项目，可想而知每天会产生多少新数据，浪费多少网络流量。因此，需要及时处理异常，尤其是出现频率高且稳定反复出现的问题，减少网络流量和异常平台服务器的压力，及时降低公司的运营成本。在解决问题之前，我们需要确保异常数据是我们需要解决的问题，而不是等待我们处理的无意义或令人不安的问题。此类问题会影响后续的数据分析，降低解决问题的效率，以下大部分解决方案都可以在异常上报SDK中统一处理。规范异常数据的上报，规范异常上报标题的格式，以及其他附加数据，如哨兵中的标签，附加数据等，方便大家在不同项目中快速参考和分析问题。另外，需要规范异常上报的时间，被动上报异常除外。其他用户主动操作行为引起的异常，如界面异常等，应及时上报，逻辑复杂，在特定时间上报异常记录和分析。部分异常过滤，对于一些框架底层异常或者已知业务场景的正常接口异常等，可以直接进行过滤处理，不会在异常平台上展示进一步处理。这种异常过滤过程可以在SDK中进行全局过滤，可以针对不同的项目添加不同的过滤条件，也可以直接在异常平台上过滤一些不太重要的项目。部分自动处理，自动处理分为几种情况：自动删除、自动标记和解决、自动列为忽略异常。上面过滤的异常会被再次过滤。这种处理的异常内容可以是一些业务场景需要上报的接口异常，但不能归结为代码逻辑错误。例如提交订单时，后台还没有添加新机种。异常触发后，操作会立即处理，不会再发生。对于这类异常，可以使用程序自动处理。完善健康度所需的各维度数据。判断一个项目产生的异常不能单看数量，还要看当前项目的用户数量。因此，当前计算健康度所需的所有维度的数据都必须提前计算好，以提高后期健康度计算结果的准确性。异常的高效发现经过以上初步的数据处理，通过SDK上报给异常平台的数据就是我们真正要处理的异常数据。以转转为例，目前接入Sentry的前端项目有**500+**个，每天异常报告次数约为250万次。这么大的体量，如何快速找出哪些异常需要紧急处理呢？异常上报后，需要有针对性的处理。对紧急核心项目和上报数据异常情况优先处理。通过以下方法可以高效地发现异常。这里的异常不是指所有的异常，而是需要紧急处理的异常。项目健康度排名通过一系列维度权重配置，计算出所有项目的健康度得分。通过对分数进行排序，可以获得当前项目质量，并及时通知相应负责人进行处理。相关维度项及解释如下：24小时异常/PV比率：过去24小时发生的异常数量与项目PV数量的比值14天异常数量：项目总值项目14天内发生的异常数量24小时异常数量：项目24小时异常PV数：统计该项目昨天所有页面的PV数核心项目：该项目是否标记为核心项目健康分数计算公式：可以随时调整各个维度的权重比例，调整后会立即重新计算分数和排名，通过维度权重的调整可以提高整体项目的质量要求。Sentry的大规模异常监控监控异常平台所有item上报的汇总值。有2个监测指标。突发异常数量过多，超过了前一个区间数据的增量比例。如果有异常，这种情况可能是短期异常过多导致平台崩溃，或者其他情况导致异常处理无法处理。针对这两种情况，记录异常波动并触发企业微信推送。项目异常监控之后是项目级监控。但是由于大型集团公司的项目太多，需要对一些异常数量极少的项目进行过滤，以减轻服务器压力，提高数据处理速度。我们可以通过Sentry平台Stats中的项目进行监控和处理。这里的项目可以传入查询的时间段。这里的最小时间段是小时级别。返回的是当前条件下新增异常数量的排行榜。我们只针对这个列表进行监控和处理。由于需要更快更准确的监测异常波动，基于这个列表，再次查询每个项目5分钟内新增异常的数量，通过定时任务处理可以得到如下趋势图，可以快速找到某个时间段内的哪个项目有异常的项目数据。针对这部分异常，还进行了异常波动数据存储和企业微信消息推送。以上两种企业微信消息推送的情况，最终都会触发企业微信消息推送，因为消息推送更准确、更快速，但也有一些特殊的项目，比如晚上的定时任务。超时可能太多。PV量大的项目触发的配置值不同。因此，对于推送部分，增加了相关尺寸的配置。推送配置包括推送间隔、多少个时间段触发一次推送、推送时异常起始点个数、增量异常比例、是否开启推送。最终企业微信推送效果如下：超时未处理的提醒。以上项目波动监测是针对项目整体的异常情况。定时推送，在消息推送内容中注明当前异常数量，对于超过3天未处理的异常，@对应负责人，以提高相关人员的警惕性。最终企业微笑推送效果如下：整体流程如下：高效解决异常上一步发现异常后，会采用几种方法更高效的解决异常。此流程是根据公司内部现有情况而定，在不同公司可能不适用，请参照处理。知识库解决方案沉淀目前每个团队都没有解决项目异常问题的具体解决方案，但是大家遇到的问题都是相似的，很多场景下异常问题的解决方案是可以复用的。鉴于此，我们将解题过程沉淀到内部文档知识库中，以便其他同学遇到类似问题时，能够提供一定的解决方案，提高解决异常问题的效率。整体流程如下：如果问题已经提交文档记录，进入异常问题详情页面，右上角会有解决方案的参考地址。点击链接跳转到内部文档查看对应的解决方案。内部文档搜索协会研发同学有记录文档的习惯，但是历史文档与Sentry没有任何关系，所以在Sentry异常详情页面新增了一个跳转到内部文档搜索的按钮。如果存有类似文件，可以直接参考解决。一键开发，内部系统连接Sentry本身是一个独立的开源项目，因此与公司其他系统没有任何关系，导致无法与其他系统进行联动操作，比如创建分支，查询内部项目——相关信息。导致每次解决异常后都需要创建需求和分支，然后再进入开发，整个过程重复且繁琐。基于这样的背景，哨兵异常详情页增加了一键创建需求和分支的功能，可以一目了然的进入开发流程。整个过程如下：调用其他系统涉及到的接口很多，细节就不多说了。核心是根据异常详情中的页面地址，分析出项目的相关内部信息，根据这些数据创建tapd需求，创建项目仓库的开发分支，将记录与当前异常信息进行绑定。接口异常自动分发负责人约占现有项目的80%，需要大量时间沟通、协调和处理异常。处理过程一般是在哨兵监控平台上发现接口异常，然后将对应的接口请求数据和响应数据交给对应的后端进行处理，每次通信繁琐耗时。基于这个背景来优化整个沟通流程，先把异常报告的标题拼凑起来，统一起来，方便后面检索的时候，可以快速的发现问题属于接口层面的问题。然后根据题目中获取的接口地址，从ZAPI（内部接口文档平台）平台获取对应的后端开发者，最后将接口的异常情况推送到群聊@对应的开发者。这里为了方便RD还原当前请求场景，会再次查询哨兵平台异常详情接口，在详情中获取该接口请求的traceid，这样就不需要再提供请求输入输出参数了给后端人员。const=sendTitle=`${sendType}--${requestUrl}--${responseText}`推送效果如下：整体流程如下：总结本文从两个方面阐述了前端异常管理的重要性aspects,然后处理异常前期增加了异常数据精度的过滤过程，对过滤后的数据通过几种方法快速发现有波动的异常情况，最后在需要处理的异常中加入一些方法处理，提高解决异常的效率。异常治理的过程是一条漫长的道路，需要相关同学的努力才能取得更好的结果。比如通过一系列的手段，可以发现很多不正常的情况，然后相应的同学就需要快速的处理，安顿下来。求解的过程供以后其他同学参考。只有沉淀一定量后，才会有更显着的效果。本文异常处理平台基于开源平台Sentry。其他平台的处理逻辑类似。我希望它可以帮助你。
