TL:DR; #
本文尝试分析前端场景下的性能监控应该实现的目标，并尝试进行系统设计。本文侧重于架构层面的设计，代码实现方面会另外开一篇文章。
问题 #
目的是监控前端代码在全链路的性能表现情况
是真正的问题吗？ #
探索解决办法 #
前端获取性能数据的方法
对用户体验强相关的数据指标
系统指标。能够支撑多大的并发量、存储成本。
如何设计系统架构 #
初版架构图 #
这里添加一个架构图
SDK 接入方式 #
数据抓取 #
数据上报 #
数据存储、清洗 #
数据分析 #
报表呈现 #
最终的架构图 #
性能评估、优化 #
系统性能评估方法 #
能够承受多大的并发？
能够存储多少用户量的性能、存储时间
优势劣势分析 #
扩展能力 #
跟其他监控系统整合 #
比如和错误监控、埋点日志等整合起来，形成一个统一的用户数据分析大盘。此时能够做到以下系统独立时难以做到的事情：
- 在错误监控系统中排查问题时，能够看到报错时的性能问题，可以更好地观察排查问题。
接入小程序端的性能监控 #
价值。小程序后台中也有性能监控，但是存在以下问题：
- 在维护多个小程序时操作比较繁琐。每个小程序需要逐一扫码登录查看，操作比较繁琐
- 性能指标等不够精细，不能集中体现重点。
注意：
- 可能部分数据只有微信官方才能拿到
- 可能有数据遗失的问题。因为实际上是在小程序运行时内部上报，可能因为运行环境不稳定等问题导致没有上报性能数据。