职业生涯中有幸遇到了一位非常靠谱的领导，除了关心项目进度之外，还会关心员工的成长过程中的通用能力，个人感觉这样的领导是有魅力的，如果是我也会想成为这样的人。领导经常教导我们作为研发者应具备的四方面认知：意识、能力、机制、平台。
监控其实就是这样：要先有监控的意识，认识到监控的重要性，然后通过研发的能力，技术去实现，把功能进行封装，做成通用机制进行推广，用户量达到一定级别后，就要转向平台的思路去看待问题。
本文将结合自身工作中参与监控相关的事情，从这四个方面分别阐述一下web前端监控实践过程中的思路及一些感悟。
意识
什么是监控
监控从字面含义来看包含两方面内容：监，监测的是代码；控，控制的是质量。监控是工具而非目的，绝非为了具有功能而监控，而是要通过监控，真正了解页面运行情况，以达到代码运行质量可控的目的。
监控不同于统计，统计关注的是一段时间内访问情况的一个总和，对于实时性要求并不那么高，可以延迟上报、累计上报；监控则恰恰相反，关注的是页面运行时的情况。
监控的场景
整个大前端角度来讲，监控是有应用场景的。后端监控接口的稳定性和性能；端上监控一些crash和性能；对于web前端来讲，监控页面运行时的报错、性能。
监控对于线上线下来说都是有意义的。线下我们可以支持自动化测试，上线前就发现代码运行时的一些明显错误，也可以做为线下性能防退化的参考。线上场景就更多了，可以监控代码在不同地域、不同设备、不同环境等条件下的运行情况，收集信息会更多。
监控的意义
宏观来讲：
- 公司不断追求盈利，有什么方法保障我们产品稳定？答：监控；
- 投入QA人力日益削减，有什么方法来保障我们线上运行代码的稳定性？答：监控；
- 研发人员对于产品方向控制能力比较有限，但是代码质量方面有话语权，那么怎么来提升话语权呢？答：监控！
具体来讲：
首先是流程闭环，从研发流程上来看（如下图所示），我们的项目不是完成上线就万事大吉。需要监控页面线上运行情况，根据监控的数据及时进行复盘，循环迭代优化，形成持续的研发闭环生态。
其次报警告知。根据我们监控内容，设定不同的阈值，当达到阈值的时候，第一时间有效的通知到对应的研发人员。
然后是报表描述，经过一段时间的沉淀，我们收集过的错误，需要绘制出一个报表，统计出我们某段时间内收集、解决的问题。可
以上这些监控的意义，既是日后流程机制的基础，也是研发同学的行为准则参考，同时也是是老板、同事等关心产品朋友，更加直观的全方位立体化的了解产品的可选工具。某些关键时刻也是上层做决策的参考内容之一。
同类产品分析
同类产品市面上其实已经存在，但是调研发现大多是要收费的，比如：frontjs、arms、岳鹰等。分析主要因为成本问题，收集、存储、分析等这些功能，需要耗费大量的人力和财力。
对于初创公司来讲也许会直接购买来用，但是做到一定规模的的公司，出于安全性等角度，可能就不会这么做了。这时候会考虑自研一些监控，一方面安全，另一方面成本掌握在自己手里。
接着我们来讲一下前端监控系统境的搭建和应用。这个能力在机器和人力允许的情况下可以抽象出来提供给不同公司和产品来使用。
能力
流程设计
在能力级别，来考虑一个监控系统的实现，最基础需要包含以下几方面内容：
首先是收集，监控一定是有网环境下的，要想及时获取页面运行情况的信息，需要及时将收集到的信息反馈回来。反馈方式就是按照约定好的请求，发送给系统服务器。
然后是分析，收到信息后，系统对页面进行分析，需要提供平台展示出来，从众多信息当中筛选出来用户想要的内容，进行汇总展示。
接着是报警，要及时了解页面运行时候产生的异常情况，报警必不可少，报警的方式常见的有：邮件，IM，短信，电话。日常工作中这些报警都有接入，基本也是根据事情优先级的情况，可以配置不同的报警形式。
接着是报表，当沉淀一段时间后的形式，需要形成一个报表对最近的情况做总结，比如同环比、趋势等，这些可作为后续开发的一些参考依据。
技术方案
技术选型
站在巨人肩膀上。要实现一套系统，首先需要对技术进行选型。对于即将搭建的监控系统，如果从0到1开始生撸，可能基础功能还未完成，就面临产品夭折，因为监控系统每个环节麻雀虽小五脏俱全。经评估，选择基于开源的错误监控Sentry和日志收集系统ELK，进行服务搭建。之所以选用Sentry是因为其具有根据sourcemap定位代码错误具体位置的功能，选择ELK是因为日志处理方面表现突出。
根据当下技术潮流选择。具体准备开始动手实施的时候，发现了新大陆：Kuberneters！K8S可以更加简便科学的管理容器化应用。而且恰好Sentry提供了K8S的配置文件。采用K8S让运维起来更加便捷，可以动态扩缩容适应大流量；可以通过针对容器的监控报警来确保服务稳定性；可以用户无感的升级服务迁移数据...真的是太方便了。与此同时，从BAT对云的布局可以看出，云是未来趋势，目前各家云对K8S都有很大程度上的支持，对于这种独立于业务来讲的服务来讲，比较适合单独部署在云上。
架构设计
针对以上技术选型，设计了一套基于云上K8S监控系统架构，如下图：
具体来看：整体从左往右看，错误和性能，覆盖不同的产品形态，通过基础服务，获得页面运行时的数据。基础服务部分，从上往下看，通过JSSDK 传给后台的服务进行数据处理，最终结果存储在云上服务中。
错误监控流程
Sentry在云上的部署情况如下图：
因为某些原因，选择将服务部署在了百度云上。ITM提供DNS域名解析服务，通过BLB和WAF接入Sentry服务，Sentry内部封装，数据存储在独立的PS数据库中，可以通过访问Sentry后台，对错误进行追踪。
性能监控流程
性能监控，一方面明确性能收集指标，通过封装的SDK，将数据直接打到云提供的ES服务中，通过Kibana过滤查找自己想要的内容数据。
后期成本
回头看一下，缕清楚思路之后，站在巨人肩膀上，即可快速搭建出来一套完整的监控系统。通过业务，评估需要的机器，在云服务上进行购买即可。下面列举一下我搭建服务的一个预算表。
机制
第一次跑通流程能的时候，可以看到收集上来的数据非常开，。急迫的去找组内业务线去使用，结果完全出乎我的意料，没人愿意主动使用。思考了好久，得出了结论：没有完全站在用户角度去思考一个产品。
没有考虑集成SDK的难易程度、覆盖面，没有考虑当前报警是否是科学合理的，没有考虑产出的报表是否是大家想要的。于是针对这些问题做了一些改良。
集成机制
SDK集成包含两个内容：便捷性和规范性。
首先是对SDK大小及引用方法进行了优化，原先打包40K的SDK抽离成20K，后面规划抽离到10K以内。原先需要页面找对应位置集成script，现在异步引入一个外链即可。
然后就是针对规范性，提供了官网，这是一个功能的门面，大家认识它的途径，官网包含愿景、介绍、使用文档、联系方式等内容，用户更容易使用，也要让人感觉亲切。
申请流程、使用方法集成于官网，形成使用步骤，进而行程监控平台的集成机制。
报表机制
为什么会有报表这个东西？
一开始认为，研发需要去一个地方看收集上来的数据，默认Sentry的报表和ELK的报表可以满足最最基本的数据展示。
但是实际情况是：研发同学需要看到更直接的结果，我的页面到底有啥问题，领导想看到能客观表现页面运行情况的数据汇总。更深入的，想要看到当前数据与过去数据的对比，想看到未来数据运行的趋势。所以基于官方提供的API和接口，对当前报表进行数据抓取，绘制更贴近使用者的图表。
监控机制
前面在流程设计的时候，说过报警常见的形式有：邮件，IM，短信，电话。而且需要根据不同需求进行配置。实践后才发现与当时设计有些出入，比如Sentry只有邮件可用，ELK默认没有报警。这些出入与妥协，会导致系统用起来总感觉有些不爽。后期也需要基于报表，进行报警形式的丰富。
通过对流程跑通的系统进行推广，才发现一个监控系统至少要有三个机制：集成机制、报警机制、报表机制。说白了就是：官网、大盘、报警，这三个要素是推广一个系统的最基本要素。
不止于此！
一个完整的系统，不仅仅是刚才提到的机制，需要发现更多的机制。比如平台稳定性机制（包含异常容灾、机器监控等）服务升级机制、功能扩展机制。
平台
前面机制完善之后，顺利的情况下，会有新部门新组织的产品接入。一个工具变成了一个平台，变成大家关注的内容。
此时需要对前面做的东西，功能需要更加规范，更加通用，同事扩展性显得更为突出，如何应对某独立产品线单独的额外需求。这时候需要平衡取舍。目前还在实践中，后面有感悟再来补齐。
不是有句名言嘛：任何系统都有一个规律：复杂的事情简单化、简单的事情流程化、流程化的东西自动化、自动化的东西智能化，所以还有很多事情需要去考虑，去落地。
总结
写到后面，大家也许期待的是贴各种代码，详细来讲搭建与应用的过程。但是好像一行代码都没有，一个庞大的系统，涉及的面挺广，不好用某个局部代码来表明，所以索性就说个搭建一个应用需要有的思路吧。
通过这次搭建，体会到了创业的艰辛与不易，从0-1很艰难也很快乐，但是当有人意识到问题，1-n复制的速度就快很多了。ELK还没做完的时候，发现别的具有更强大功能的平台，加之公司内部推广中台，所以先搁浅了。下次在哪儿需要的时候，就可以快速搭建出来了，也算是中台能力的一种潜意识的沉淀。
