前端监控系统

前端的监控主要分为三个方面： 性能监控

• 白屏时间；
• 首屏时间；
• 用户可交互时间；
• 总下载时间；
• TCP连接时间；
• HTTP请求时间；
• HTTP响应时间；

异常监控 监控客户端脚本发生的报错，前端报错受网络，机型，业务逻辑影响而且大部分错误难以还原现场

需要对客户端服务进行基于用户行为的监控 数据监控做精益的数据分析

1. 页面PV,UV可能直接影响转化率
2. 从用户访问页面的顺序挖掘使用习惯（等等）

传统解决方案及缺陷
传统前端监控解决方案：Sentry,Badjs,jsTracker,GrowingIo

要实现监控，首先要采集指标

性能指标

这里要针对的主要是白屏时间、首屏时间、用户可操作、总下载时间。 不要使用setTimeout和setInterval方法，因为在单线程执行引擎中，异步队列的执行是不能确保执行时间推荐

****

****

另一种优雅的解决方案是直接使用window.performance接口：

异常指标主动捕获异常方案主要是 onError 和 addEventListener，onError 在 IE6 开始就支持了，所以 大部分系统的主动采集是使用的 onError。这里注意浏览器的同源性策略（CORS），在高级浏览器中如果浏览器捕获到了错误信息，如果 JS 文件所在的域名（如：meituan.com）和当前的页面地址（如：dianping.com)是跨域的，那么引擎会自动把onError 中的参数 替换为 script error，此时无法获取行列数以及报错详细信息。解决方案是在标签引入时加上crossorigin字段。

虽然传统方法能够自动catch大部分错误，但是也伴随着以下缺陷：

1. 部分应用在不同网络，机型上表现不同，开发人员需要获取到更详细的分类信息，传统系统很难做分类聚合，开发面对几十页分类的table无从下手。
2. 错误与错误之间往往成相关性，但是在传统系统中catch到的错误都是孤立的，没有基于用户行为的分析。
3. 针对异常的告警配置不够灵活，无法满足开发需求：大部分异常告警指标伴随高低峰期波动，没有一成不变的指标，而传统告警平台都是采用绝对阈值的告警方案，要么高峰期误报太多，要么低峰期错误无法发现。

数据指标

新解决方案

伴随着上面讨论的问题，我们寻求新的解决方案，一种高可用的监控方案。它应该具有如下特征：

1. 全量采集：监控指标健全，端到端采集全量的性能指标，关键执行方法，业务指标，覆盖率做到2个9以上。
2. 无需埋点：全量上报，无需开发人员手动埋点，从根本上杜绝错埋和漏埋
3. 查询便捷：能够按照地域，机型，操作系统，浏览器版本，网络状况等多个维度进行数据查询，最好支持全文搜索，分类聚合。
4. 场景还原：根据打点信息，还原用户从登陆开始一系列操作，建立基于用户行为的时序图。
5. 实时性强：秒级查询，上线后能立即看到优化效果并指导下一步优化。
6. 智能告警：采用静态阈值和动态阈值结合的方式，兼顾高低峰，减少误报漏报。并针对业务数据建立告警指标，发现系统深层次问题。

根据这些需求，我们团队打造了一套全新的监控体系，新系统采用了无埋点SDK（小程序），ELK做本地化日志存储，并使用了基于动态阈值的告警策略。下面是系统架构图：

目前监控平台：实时数据监控平台prajna，实时错误日志平台CAT和 打点日志平台GALAXY。

prajna上实时可查数据，理想情况下有对各个指标有相关域值，可查看当日异常数据情况

CAT上可以观测到当天的异常报错数据，对比前一天和上周同一天同事间段的数据，是否错误异常。

GALAXY上可以收集到当日之前的打点数据，可以拉取前一天和上周同一天同事间段的数据来模拟当日的数据。

document渲染完成最准确的是chrome.debugger提供的timeline-Layout接口,详细可以参考官方文档 https://link.juejin.im/?target=https%3A%2F%2Fdevelopers.google.com%2Fweb%2Ftools%2Fchrome-devtools%2Fevaluate-performance%2Fperformance-reference