小东西快快学快快记，大知识按计划学，不拖延
我现在是有参与到团队的日志系统的开发维护，所以今后打算把 前端监控 做成一个系列，把整个前端监控链路给总结一遍
帮助自己巩固知识，也帮助想了解这方面内容的同学
这篇文章将是一个序篇，总览地说一下 前端监控，大概分为5个部分
1、监控典型例子
2、为什么需要监控
3、监控上报什么内容
4、监控上报的完整链路
5、完整的上报系统包含什么
没有监控典型例子
说真的，我之前没怎么看重监控这个东西，只觉得徒增我的工作量，甚至有点抵触，直到我遇到了问题。
有些东西就是这样，不等到问题找上你，你都根本不会重视
下面讲几个真实我碰到的例子
1、偶现bug，无法复现
运营侧反馈说现网有一个偶现的bug，需要我解决一下。我反复排查，就是没复现出来。
代码逻辑没有问题，根本无从下手，但是这个bug的的确确是存在的
偏偏这个项目又没有接监控日志上报，无奈之下，我只好接了监控重新发布，等到有bug 复现的时候，再查看日志从而定位到问题。
最后bug 如愿复现，查看日志，是因为接口失败，从而导致用户操作了产生错误数据的bug
幸好这是管理后台，只是给产品运营同学用，如果是用户使用，估计我都溜溜球了从此我深刻体会到日志的重要性
2、用户白屏怎么办？
面试官
如果用户白屏，你怎么办？？
看服务器的接口日志？看是不是接口报错了。
我
面试官
接口正常，服务器没有错误日志
换个浏览器？
我
面试官
换浏览器也不行，但是换手机可以
啊这....要不把手机寄过来
我
面试官
要不你坐飞机去现场调试
也是个选项，那要怎么办啊
我
大佬笑了笑没有回答，深藏功与名
到现在，我才明白，看前端监控啊，TMD 查监控日志啊
页面白屏肯定是报错啊，错误肯定是要上报的，一查不就知道了
而且前端报错这种东西，服务端哪里会有日志啊，大部分就是页面js 报错
就像这种多级取值操作没有判空导致的 render 错误
如果你没有监控错误上报，谢谢，你可以溜溜球了
为什么需要监控
看了上面的例子，大家应该也体会到 前端监控的重要性了吧，再详细说，就是3个点
1、被动为主动，及时发现问题，以免造成损失
问题是不可避免的，但是我们可以尽早发现尽早解决，而不是等到用户发现
用户一般出现问题的时候，是不会和你反馈的，你也只会白白流失一个用户并收获亲切的问候，“做的什么垃圾东西”
一般如果页面的 bug 频率很高，我们会有一个告警机制，我们就可以紧急处理这个问题
2、清晰了解运营情况，评估运营成本和质量
我们上线一个活动，要知道有多少用户访问，有多少用户参与，沉淀的用户有多少
这样我们才知道活动的价值，是否对我们增长用户有帮助
可以帮助我们的产品同学指明方向
比如我们的日志监控图是这样的
就这样可以很清晰了解上线的活动的数据
3、辅助日志，排查偶现的问题
就像我说的例子，日志重在帮助你排查偶现的问题，有时你可能排查到明年都搞不清楚这个问题的
有可能是用户的问题，有可能是你代码处理的问题，有可能是接口的问题
帮助你定位问题，减轻你排查的压力，少浪费时间做无用功
所以一款合格成熟的应用，一定是可控的，出问题我要知道，流量情况我要知道，成功率我要知道
这样才能把应用越做越好，完善用户体验，把控产品方向。
监控上报什么内容
那么我们前端监控，需要上报什么东西，才能对应用有一个完整的监控呢？
分了两个部分
1、上报的类型
2、上报的具体内容
1上报类型
对于页面，我们通常将监控 分为 3个大类型
1、测速类监控
2、稳定性监控
3、计量类监控
1、测速类监控
顾名思义就是速度，包括 接口请求的响应速度，页面首屏速度，或者自定义测速，比如某段复杂算法代码的执行速度
2、稳定性监控
评估一个应用的稳定性，当然是看 成功率 和 错误率
比如 页面的错误上报，资源加载错误，接口请求计算成功率和失败率
还包括自定义上报数据，比如在代码关键节点手动上报数据，保存用户操作关键的数据，就类似于你在开发时 console 一样，主要是用于定位问题
3、计量类监控
一般是用于运营方面的数据
1、页面的 PV（page view）UV（user view）
2、关键操作的自定义上报。比如视频点击量，视频观看量，分享量 等等从上面这些指标，就可以知道一个活动的有效性，如果pv 和 uv 都很小，说明这个活动推广不够
如果pv 还可以，但是里面点击量 分享 很少，说明这个活动不够吸引用户
2上报的具体内容
我们上报的请求中，具体需要包含哪些内容？
我们团队是制定了一套字段规范，一部分是针对用户端信息的，一部分是针对请求信息，一部分是自定义数据
用户端信息。包括 ip ，手机类型，浏览器，访问的页面链接，日志时间，域名 等
请求信息。就是接口请求一般包含的信息，接口名 cgi，method，query，body，statuscode，response，header
自定义数据。就是给你手动上报的时候保存你需要的数据，比如其中一个字段就是 message
比如你监听了一个按钮点击事件，你想知道这个按钮的点击量，所以就在事件回调中进行了上报
logger({
message:"xxx按钮点击量"
})
然后查询日志的时候，就只要查 message ="xxx按钮点击量" 这个条件，就能知道有多少点击量了
用户操作链路跟踪。我们需要对用户当时所有的操作日志，串成一条链路，这样才知道用户是什么样的操作才会触发bug
所以我们需要一个 链路字段 trace_id，这个id在页面初始化的时候生成存进 sessionStorage，之后每次上报都会读取并加上这个字段。因为 sessionStorage 只会在当前会话中有效，用户关掉之后就会清空
所以我们利用它来进行用户单次访问的日志串联
监控上报的完整链路
来看下我们整个上报的流程
主要分为3个部分，如下图
其中第二步保存日志，我们不仅需要实时上传，还需要保存用户端本地。
其中考虑有网络情况导致关键日志丢失，所以会保存本地一份。如果用户有反馈问题的时候，我们可以引导他上传本地的日志。
比如我们会在页面绑定一些操作，用来给用户上传日志使用
监控系统包含什么
一个完整的上报系统是怎么样的
通过上面这个上报的流程，我们应该可以简单了解到上报系统的组成
大致可以分为 5 个部分
1、页面引入的上报SDK
2、上报数据的存储系统
3、上报数据的查询系统
4、可视化配置系统
5、用户行为追踪系统
所以看起来内容还是挺多的，但是我们当然是以业界现有的工具为主，其次才是自己开发。
下面就来简单说下每个部分都是怎么做的，后面我会对这些部分都做一个详细的文章说明
上报SDK。上报 sdk 是我们自己开发的，具体就是一个npm 包，直接在项目中 import 引入。主要是为了针对业务开发一套上报更加便捷的sdk。最大化减少手动上报，减少代码入侵，做到无感上报，比如请求抓取、 测速，页面错误方面都是 sdk 自动抓取上报的，只有 自定义上报点，才需要手动加入。
存储系统。我们使用了 Elasticsearch 作为日志存储的解决方案，Elasticsearch 是一个开源、分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力
查询系统。采用 Kibana。Kibana 是 Elasticsearch 团队推出的一个搜索，告警的ui工具，配合上面的 Elasticsearch 使用。
可视化配置系统。采用 Grafana。Grafana是一款用Go语言开发的开源数据可视化工具，可以做数据监控和数据统计，带有告警功能。就是对日志数据进行各种可视化预览，柱状图，饼图，曲线图等等，对日志有一个清晰的预览。
用户行为追踪系统。采用 jaeger。前面说了每次用户访问都会初始化生成一个 trace_id，然后日志上报都会带上这个id，然后形成一条完成的用户操作日志链路，方便排查bug。但是我们也只是保存一个 字段而已，直接查出来，并不能很好帮助我们排查，还需要一个系统帮我们把这个日志完美地串起来，让我们方便查看。
最后
如果你没有接触过日志，可能你真的无法体会到日志的重要性，希望我的文章能带给你启发。
可能别人苦口婆心和你说多重要多重要，你没有自己真的踩过坑的时，还是无法深刻体会的。
但是你要记住啊，小坑踩无损失可以，大坑一踩你可能就溜溜球了
鉴于本人能力有限，难免会有疏漏错误的地方，请大家多多包涵， 如果有任何描述不当的地方，欢迎后台联系本人，领取红包
