自适应网站一般用什么框架做,华强北设计网站建设,jsp网站开发步骤,品牌网站建设策划监控是提高故障处理能力和保障服务质量必需的一环#xff0c;它需要负责的内容包括#xff1a;及时上报错误、收集有效信息、提供故障排查依据。 及时上报错误#xff1a;发生线上问题后#xff0c;经由运营或者产品反馈到开发人员#xff0c;其中流转过程可能是几分钟甚至… 监控是提高故障处理能力和保障服务质量必需的一环它需要负责的内容包括及时上报错误、收集有效信息、提供故障排查依据。 及时上报错误发生线上问题后经由运营或者产品反馈到开发人员其中流转过程可能是几分钟甚至几十分钟这段时间可能直接导致公司的经济损失。如果有一个监控系统在线上出现问题时监控系统能够第一时间报警并且通知到开发人员那开发人员就可以第一时间修复上线使公司损失最小化。收集有效信息特别是移动时代定位一个问题时需要很多用户信息如用户手机版本、网络情况、操作流程等。如果没有监控数据往往只能靠猜又或是来回找产品运营甚至出现问题的用户去沟通定位会花费大量的时间。假如监控系统里记录了设备信息、错误发生时的场景信息和用户的操作流程我们就可以直接根据这些信息进行问题定位在最短时间内完成故障修复减小问题的影响面。提供故障排查依据监控前端SDK所上报的错误信息和其它的记录信息其最终目的都是作为我们排查故障的依据为我们保障服务提供坚实的依靠。监控分类 综上所述我们的监控平台强调实时性和全面性。为了保证实时性错误发生时就尝试上报并且在监控面板可以实时的展现出来以及有及时的告警机制。全面性是指收集的信息全面包括用户信息、环境信息和错误信息等因此监控平台包括记录型监控和捕捉型监控。 记录型监控 页面访问记录用户访问了哪些页面。资源加载记录页面中加载了哪些资源。用户行为记录用户在页面上做了哪些操作目前我们只记录用户的点击行为。接口调用相关记录页面调用了哪些接口。捕捉型监控 DNS劫持页面是否被劫持。资源加载错误哪些资源加载失败了为了捕获跨域JavaScript的错误需要在相应资源标签上添加crossorigin属性。页面错误页面渲染过程中出现的错误。内部逻辑错误用户特定操作出现的错误通过用户行为定位。接口错误调用接口失败。 场景还原法 当捕捉型监控捕捉到错误后我们根据错误信息定位用户再通过记录型监控还原该错误发生的场景从而复现问题并及时定位解决。这个过程我们称之为场景还原法。 本监控平台就是通过收集监控数据使用场景还原法来解决问题。它将支撑系统处理过的所有记录和错误按照时间顺序展示。通过场景还原的列表我们可以还原出指定用户在浏览页面过程中发生的所有事情及其先后顺序从而判断问题发生的时机和环境。 假设以下场景 PMBD反馈用户在购物车刷不出来啦 RD什么我试试我这里可以看到的呀 PM商户反馈店里有的用户可以有的用户不行 RD别急告诉我shopId和打不开的用户的账号我去监控平台上看一下 PMxxx RD在监控面板上使用场景还原功能调出了该用户的所有信息记录。发现该用户是从菜品详情页进入的购物车而再查看正常的用户都不是从这个入口进的定位到是菜品详情页跳购物车的部分有问题并立刻进行了修复 在以上这种用户可能有多种操作的场景中场景还原法可以针对特定用户还原其完整的操作路径和页面上发生的所有事情帮助复现问题。 另外一些非必现的问题常常是由于不同机型或环境引起的也可以在场景还原中复现问题的发生环境予以判断。 本文主要介绍点餐终端技术组监控平台HUNT的前端SDK的实践经验仍有许多需要改进的地方欢迎大家拍砖帮助我们改进。 如图所示我们的监控平台HUNT分为前端SDK、Web层支撑系统和监控面板三大部分。 * 监控前端SDK收集用户端错误和相关信息并进行上报 * 监控Web层支撑系统处理上报的监控信息 * 监控面板提供实时查看上报信息的面板方便监控数据的便捷使用 前端SDK运行在前端页面中收集监控数据上报到支撑系统里作为监控面板上查询的数据源。 就前端SDK来说可以分为数据模块、数据处理模块、上报模块三大部分其中数据模块包括各具体监控数据模块和环境数据模块 * 数据模块 * 各监控模块获取需要上报的具体内容信息EventData或ErrorData * DNS劫持检测 * 资源完整性检查 * 资源加载错误 * API监控 * 全局错误 * 用户交互 * 自定义上报 * 环境模块获取环境数据 * 数据处理模块将环境数据和各内容数据处理成接口对应的格式并返回标准格式数据。 * 上报模块从环境模块获取环境数据再和内容数据一起根据不同监控类型分发到对应的数据处理模块。获取标准数据后发送到Node层。 上报模块先查看本地缓存数据将本地数据和新产生的数据一起上报若上报失败则存入LocalStorage。 SDK里采用单例模式包括各监控模块、环境模块和上报模块。 每个具体监控模块获取上报模块实例进行上报上报模块内部保证同时只会有一个上报请求。 事件的监听都在捕获阶段进行防止因为事件冒泡被阻止而遗漏信息。 环境模块 环境模块收集以下环境信息项目配置信息、Web环境数据、JsBridge环境数据。 其它的一些诸如UA、ISP等Web层可以获取的信息由Web层获取。 该模块暴露init和getEnv方法。 * init接收用户配置的环境参数 * getEnv更新页面URL再返回当前env对象freeze的一个副本 上报模块 采取单请求上报的方式每个用户同时只会有一条上报请求每次将当前记录到的监控信息列表一起上报成功后再继续上报。 上报结束之前的新上报记录都存在Localstorage收到成功消息后删除已上报数据继续上报不成功的记录保留在Localstorage。此处需注意对Localstorage存储的上限做好控制。 在当前没有数据正在上报的情况下触发上报尝试将当前Localstorage的数据和新数据全部上报若上报记录过多则分条发送。全部发送完或上报失败本次上报结束。 各具体监控模块 DNS劫持 HTTPS页面被劫持后页面资源无法获取劫持者无利可图的情况下会降低劫持的动力。 若仍被劫持前端资源未到达本地也无法完成上报只能从网络层去监控。 由于美团点评平台已经全量切了HTTPS因此该模块不在本监控系统中。 不过之前本团队做过对HTTP域下的劫持检测其检测思路为请求Node层指定域名下的样本HTML或JavaScript资源对比返回结果是否符合预期。 资源完整性检查 资源完整性检查模块的任务是记录页面加载了哪些资源并进行上报。 当我们排查问题时可以查看当前页面已经加载成功了哪些资源及其加载顺序排除因为某些资源没有加载或者加载顺序不当而引起错误的情况。 资源加载完整性检查的上报时机分四类每次将开始监听到触发上报之间所有记录到的已加载资源一起上报减少上报请求数 1. onloadwindow.onload时触发 2. onload_timeout: onload超时5秒时触发 3. asyncwindow.onload后一定延时5秒触发上报后停止监听 4. hash_changeonhashchange开始监听一定延时5秒触发上报上报后停止监听 内存中维护一个已加载资源的数组每次上报后删除已上报的资源记录。 资源加载错误监控 Window上error事件代理过滤Window本身的error。 根据标签类型判断资源类型src或href为资源地址。 为了捕获跨域JavaScript的错误需要在相应资源标签上添加crossorigin属性。 API错误监控 同样采用XMLHttpRequest加hook方式实现。 open时记录接口URLsend后根据status判断接口调用失败时进行上报。 XMLHttpRequest.prototype.open function open(method, url, bool) {monitor.originXHR.open.apply(this, [method, url, bool]);// get something...// this.ajaxUrl url;
}XMLHttpRequest.prototype.send function send(_data) {const self this;this.addEventListener(readystatechange, () {if (self.readyState 4) {if (self.status ! 200 self.status ! 304 this.ajaxUrl ! REPORT_URL) { // filter urls// report error info// ...// monitor.reporter.report(dataTypes.API_ERROR, error);}}}, false);monitor.originXHR.send.apply(this, [_data]);
};过滤掉SDK本身的上报地址防止上报失败引起循环上报和一些其它需要忽略的接口地址。 注意接口访问URL时可能是一个相对路径建议补全协议和domain。 全局错误监控 监听Window上的error事件过滤事件代理的error。 用户交互监控 监听Window上捕获阶段的click事件记录点击相关数据。 业务代码中可以为比较关注的元素添加data属性每次点击将会上报被点击元素的指定属性、附加信息和DOMPath帮助定位该元素。 记录用户交互信息可以明确问题发生时该场景下用户的具体操作路径结合环境数据、资源加载记录和错误数据整个问题场景就一目了然了。 接入方式 SDK的接入方式分为以下两种 1. 先加载SDK * 优点可以记录页面加载完成前的情况加载的资源以及发生的错误。 * 缺点影响页面加载速度直接拷贝在head中对业务接入不友好。 2. 后加载SDK * 优点不影响页面性能。 * 缺点只能监控加载成功的页面但我们需要关心页面加载失败的场景。 为了满足功能需要当前监控平台v1的引入方式是将压缩后的SDK代码直接引入到被监控页面的head中并由业务代码初始化配置项目名称等。该步操作可以借助webpack的插件来帮助完成减轻业务组接入的复杂度。 后续改进方向考虑采用核心基础库loaders/plugins 的方式将必须先加载的SDK代码引入在head中其余代码等页面加载完成后再异步添加。 HUNT系统上线后已经完全覆盖点餐终端组的活跃Web项目进行监控数据的多维度上报。接下来工作重点是对收集到的数据进行有效的分析和利用。 目前大部分现有的监控工具只关注捕捉型监控这部分记录型监控是缺失的。相应的以记录型监控作为支撑的场景还原功能也是无法做到的。这类型的监控系统只能做到发现错误但是对于错误定位帮助甚微。 接入本监控系统后不但能在监控面板上实时的看到多种错误信息还能根据错误发生的上下文包括页面加载的过程其中用户做了哪些操作访问了哪些API等按时间顺序排列来完成场景还原。再结合该错误发生的环境数据复现问题和定位问题变的非常容易。 当收到故障反馈后对一些偶发的问题或者用户操作复杂的问题等可以直接通过监控面板了解情况省去了大量的沟通成本我们的故障反馈速度和能力也有极大的提高。 以上就是我们终端团队监控平台前端SDK部分的实践分享欢迎大家批评指正有好的建议也希望能提出来帮助我们改进。我们后续将不断优化也将继续与大家保持讨论。耐心看到这里的读者表示十二万分的感谢
