背景
前端监控一般为http://www.Sina.com/(firstmeaningfulpaint、First Contentful Paint等性能指标监控)和http://www.Sina.com/) PV、UV、 包括页面停留时间等三个方面其中前端异常监测主要是监测前端代码执行异常、接口请求异常等导致页面出现异常，达不到预期结果的情况。 从异常问题表现方面看，前端异常监测平台应帮助开发者轻松应对包括但不限于以下问题：
许多业务日益增长、重要但低频度的错误事件不会降低或警告界面成功率，无法及时发现问题。
对于一些故障反馈问题，不能使用测试帐户再现类似的数据。
接口错误事件反映前端参数错误，但与当前请求相关的前端代码没有逻辑问题，需要大量时间来推测可再现场景和确定根本原因。
目前有很多成熟的方案可以覆盖前端异常监测，但这些平台也有一些不利的方面，比如难以定制。
这些平台几乎都是收费的，有的在云服务和套餐上销售，有的单独销售。
这些前端监控平台的体系结构不是开源的，很多用户无法通过二次开发这样的前端监控平台来获得适合当前项目的前端监控平台。
这些前端监控平台大部分不支持私有化部署，用户无法获得监控数据并进行更深入的分析。
即使这些平台的功能定制能力较低，并且是个性化能力较好的平台，但要达到监控效果，也需要进行更复杂的定制或侵入业务项目逻辑。
为此，我们研究了http://www.Sina.com/——3358 www.Sina.com/(Hawkeye )。 目前，该平台已经访问了大部分用于创建、分发和修改ichi内容的平台，通过几个月的使用，帮助业务代表及时发现各个系统的整体运行
本文从设计和实践方面对该平台进行详细阐述。
异常监控、性能监控
漂亮的耳机是前端异常监测平台，其目标是及时发现问题，加快业务项目故障排除。 特别是善于应对业务繁忙的场景，在较低频率下监控重要业务方面非常理想。
美丽的耳机主要有以下三个优点。
提供事件密集型问题列表，支持业务类型隔离监控报警，支持根据异常业务代码配置拦截接口请求错误，使前端开发人员和后端开发人员更容易、及时地发现系统问题。
记录错误事件发生前的用户交互和接口请求，支持在前端生成或记录接口返回的Trace Id并串联前后链接，增加异常故障排除的线索。
访问简单快捷，代码入侵性低。
总体框架如图1-1所示，包括JSSDK收集、后端收集服务和后台监控三部分。
图1-1美丽的耳机整体架构
JSSDK采集负责异常采集和报告，这里可以收集的信息包括： JS运行时异常(在window.addEventListener中监听error事件收集的TypeError、ReferenceError等异常)、 包括在window.addEventListener上监听unhandlerejection在内的采集服务首先检查和清洗数据，然后按照一定的报警策略进行报警，同时将消息传递到监视后台。 监控后台基于公司大数据平台和流媒体计算平台构建实时计算引擎，处理接收到的异常消息，进入监控管理页面、报告统计、报警平台等
接下来，从以下四个方面介绍美丽耳机前端异常监测的设计要点。 这些是实现及时发现问题、加快业务项目障碍两个主要目标的关键。
行为数据监控
在平台类项目页面访问量高、业务复杂的情况下，因某种问题收集的事件会非常大
多，庞大的事件量是不利于开发人员查看和发现问题的。因此我们对事件按照错误类型、错误信息及访问页面地址等按照规则等进行分类，为同一类的事件生成一个错误ID，并存入Redis中。图1-2 问题管理
二. 业务类型隔离监控报警，支持按照异常业务码配置去监听接口请求错误
对于接入了10+业务类型的单页面应用，若只按照项目划分，不利于各业务负责人发现各自关注的问题。因此，我们支持建立业务类型、接口返回错误码以及报警Topic Id等的映射配置，之后在问题收集、监控报警、统计分析等各个过程中可根据配置进行定制化处理，如图1-3示意。
图1-3 按照业务配置监控
具体说明如下：
前端统一拦截Ajax/Fetch接口请求，根据配置传入的业务错误码去采集接口的报错信息。这样的方式对于业务项目逻辑是无侵入的。通过window.addEventListener的方式可以监听到网络请求的异常只能监控到Ajax失败的请求，但无法判断HTTP状态码，并且有的业务接口返回的HTTP状态码CODE是200，业务真正的错误码在Response Body中返回。因此对于Ajax请求监控，采用重写XMLHTTPRequest的方式采集错误。同时为了做到低侵入式的业务隔离监控，我们采用业务错误码配置的方式来监控接口的报错情况。
待办问题列表按照业务配置区分展示，帮助各个业务负责人及时对当天的项目问题进行整体把握。
同一平台项目下，报警按照业务区分，不同业务的报警不会相互影响。
三. 收集错误上下文，利用Trace Id串联前后端链路
有些异常事件的发生并不只涉及一次用户操作或接口请求，而可能是异常发生之前的接口超时引起的或者某个特定的操作系列导致的报错。因此对于当前报错之前的用户操作或请求以及请求耗时也需要进行收集，帮助快速定位问题。
图1-4 错误上下文
对于接口请求异常，美丽的耳机支持记录后端返回的Trace Id串联前后端的链路监控，这样能够在前端监控发现问题时，直接根据Trace Id查看前后端的整个链路，关联业务日志，分析异常环节，快速定位问题。
同时，美丽的耳机也支持前端生成Trace Id，通过设置HTTP请求头实现(如图1-5)，请求头遵从公司Rover全链路追踪系统的数据规范。
图1-5 前端生成Trace Id
四. 基于公司大数据平台与流式计算平台建设监控后台
美丽的耳机异常监控系统构建在公司大数据平台与流式计算平台之上，后台技术架构如图1-6所示。
图1-6 监控后台技术架构
数据源：前端上报的异常事件会首先进入消息队列当中，作为统一的数据源供后续存储和计算使用；同时，使用消息队列也是一种削峰的手段，避免业务高峰时期大量上报的异常事件拖垮服务。
引擎：引擎层分为存储引擎和计算引擎。
存储引擎：根据数据类型与特点，选择合适的数据存储。
使用Redis生成异常事件的错误ID，根据项目、异常类型、异常值等维度生成唯一的错误ID，同一类异常事件将聚合在相同错误下。
使用ES存储异常事件中的部分字段，主要用于美丽的耳机监控平台中检索使用。
使用HBbase存储异常事件的全部字段，因为上报的异常事件中包含了异常堆栈、上下文等信息，数据量较大且并不用于检索，因此选择了适合存储海量数据的HBbase。
MySQL主要存储一些配置信息，例如项目设置、报警配置等。
计算引擎：主要使用流式计算引擎Flink对上报的异常事件进行实时的计算和聚合。
展望
目前美丽的耳机监控已接入了爱奇艺内容创作、分发和变现平台的大部分业务，在日常工作中大幅度辅助提升了运维效率，具体表现如下：
通过查看当前的问题列表（如图1-2）及时发现问题，先于用户报障发现问题。业务开发同学可以选择各自业务的问题查看，后端同学可以设置默认展示Service API Error（接口报错）查看。
通过Stack Trace、用户设备环境信息、Trace Id等快速定位问题, 通过错误上下文快速排查疑难杂症，如图1-4，图1-5。其中利用Trace Id的全链路监控可以显著提升接口报错的排查效率。
通过各种维度的统计，去分析项目的运行状况。美丽的耳机的数据方便接入各种可视化平台统计分析，可分析项目问题发生的趋势，以及各个项目问题解决的情况。比如利用Grafana出色的多数据源支持和报表功能，进行数据报表的开发和展示，如图1-7。
图1-7 统计分析
以上所述，美丽的耳机已经可以很好的满足我们日常业务中的监控需求，但还有几个方向值得我们去思考，例如，在SDK代码体积，需求程度、开发成本等之间做权衡时，可以考虑是否需要实现以下功能：
页面崩溃：页面崩溃后，正常的上报流程就无法走通了，如果需要投递页面崩溃前相关信息，可以通过beforeunload结合sessionStorage，在下次打开页面时上报，如果项目使用PWA(Progress Web Application)，也可以在SserviceWworker实现上报。
合并日志：如果用户访问量大，上报日志多，或用户反复触发同一个错误时，我们考虑是否需要将几次日志合并到一起再上报。
HTTP2.0：HTTP2.0上报头部压缩，多路复用的优点，会使监控投递性能更高。
在未来我们将继续优化扩展美丽的耳机的能力，比如：尽快提供小程序SDK，提供更多WEB框架的支持，帮助更多技术栈的开发者们及时发现问题、快速排障。同时也会尽快将开源提上日程，以便更多有需要的开发团队使用和借鉴。
也许你还想看
移动端APM网络监控与优化实践
干货 | 爱奇艺全链路自动化监控平台的探索与实践扫一扫下方二维码，更多精彩内容陪伴你！