系统架构与融合
基本构成
系统关联融合
高效运维
小结
数据收集与分析
数据收集
数据录入
数据分析
问题发现与解决
自动化集成测试
数据聚合
数据库
结语
前言在上一篇文章《前端监控SDK开发分享》中，对客户端SDK的实现做了分享。这篇文章将会分成四节（需求背景、系统架构与融合、数据收集与分析、问题发现与解决）分享介绍我们是如何打造前端监控系统的。
一、需求背景 1.1 解决什么问题客户端常常会遇到如下一些问题：
白屏
无响应
卡顿
服务异常
bug无法复现
等等
面对这些运行在用户端的问题，前端常常表示很无奈，解决这些问题之前，我们需要先知道客户端发生了什么，于是我们可以想到：
收集错误，解决报错、兼容性等问题
收集性能，解决慢查询、慢加载等问题
收集接口，发现接口错误、打通服务端监控
收集多方面辅助信息，综合多方面分析
为了实现收集功能，我们需要提供一个前端监控平台，它能够收集数据、处理数据、存储数据、查询数据。其实就有很多现成的平台或者开源项目我们可以直接使用。
1.2 行业通用方案前端技术发展至今，相信大家已经对前端监控的这件事情非常熟悉，或多或少都会在我们的项目中用上它。比如搭建使用开源项目sentry、付费平台阿里的ARMS、甚至小程序配套的前端监控服务。
（1）. sentry
sentry主要提供的功能是收集错误。支持大多流行语言的客户端和服务端，不支持小程序，但是目前有大公司根据sentry的上报数据结构，自己实现了小程序SDK并开源，目前关注度和流行度都偏低。除开错误，它的其它类型的前端监控能力相对来说很弱。
（2）. 阿里ARMS
ARMS提供的功能与支持的客户端比较齐全，小程序也支持。只是需要付费。总体来说提供的功能还是比较全面、符合国内的环境。
（3）. 小程序自带监控
微信小程序不断的在完善内部的监控，各方面的功能也慢慢丰富了起来，但是只能支持小程序本身。
在使用这些开源或者平台前端监控服务的时候，始终有一些不足。比如：
系统分散
很难满足增加一些自定义数据和查询需求
特性一直不更新、BUG解决周期长
二次开发难度大
1.3 定制化早期我们使用sentry，随着公司多方面的发展，已经发现到sentry不能满足好几个方面的需求了。
如果完全从0到1来打造一套前端监控系统，成本也是很高的。甚至在早期，都可能没人愿意用，系统是否能立项或者持续发展下去也是一个问题。于是从一些开源项目中去寻找，去找一个方便改造也有一定功能模块的项目。在2019年底，我们找到了zanePerfor，因为它功能比较丰富，使用node+mongo符合我们前端的技术栈，也配套支持了微信小程序。
之后，我们开始基于它的代码，进行长期的改造和迭代。慢慢的改造成为一个更适合公司内部环境的一个前端监控系统。下一节，聊聊目前的系统基本构成、企业内部系统之间的关联融合、以及运维服务如何保驾护航。
二、系统架构与融合 2.1 基本构成客户端SDK
web
小程序
ios
andriod
服务端 node+EggJs
数据库 Redis Mongo+mongooseJs(orm)
管理台 Vue+ElementUI
为了实现前端监控，第一要素是要收集客户端数据，为了方便客户端集成监控系统、我们需要首先开发封装一个统一的SDK、去帮助我们收集数据。在早期，客户端方面我们优先支持的是web和微信小程序，随着系统的迭代现在也支持了native。
SDK收集了数据，我们还需要通过服务端接口来接收，在服务端，使用node+EggJs，node适合i/o密集型场景，符合前端技术栈。eggjs简单易用、文档友好，大部分使用node的前端程序员都应该能很快上手。
服务端收集到数据并进行一些处理之后，我们需要存储到我们的数据库之中。在数据库方面，使用mongo做持久化存储，mongo 文档模型数据库，数据扩展方便，类json结构方便和node配合使用，天生适合日志系统。使用redis做数据缓存，redis简单易用的高性能key-value数据库，市场上占据主流，被大部分人都熟知。
最后，还需要一个管理台，做数据查询与管理。管理台使用Vue+ElementUI，简单快速。
下图是目前系统技术关系图：
客户端SDK收集数据上报，node服务端获取到数据后，先存在redis中，node服务会根据消费能力去拉取redis数据处理分析后存储到mongo之中，最后我们通过管理后台展示处理好的应用数据。
当初步的实现了我们的前端监控以后，我们还接入了公司内部现有的优质系统，丰富功能、提高了易用性、减少了工作量。
2.2 系统融合与关联SSO系统
加入内部导航黄页
本地日志系统 finder elasticsearch
APM系统 skywalking
告警平台
操作日志平台
SPA平台
（1） 接入内部SSO系统