监控不同于统计，统计关注的是一段韶光内访问情形的一个总和，对付实时性哀求并不那么高，可以延迟上报、累计上报；监控则正好相反，关注的是页面运行时的情形。
全体大前端角度来讲，监控的场景很多。比如：做事端监控接口的稳定性和性能；客户端监控crash和APP性能；对Web前端来讲，更加关注线上运行时的性能和报错。
监控对付线上线下来说都是故意义的，线下我们可以支持自动化测试，上线前就创造代码运行时的一些明显缺点，这个可以做为线下防退化的参考依据。线上环境则更加繁芜，不同的地域、设备、网络、浏览框架等诸多成分，导致同样的代码不同环境中运行时，结果可能会良莠不齐。我们希望理解这些情形，评估页面哪里须要优化。
公司内部现有统计平台，如thunder，spy等通用的平台，即可以网络性能指标，也可以网络前端非常信息，但是网络的非常信息大多做统计用场，关注有多少报错信息，或者某类缺点有多少种别，一样平常不会包含详细报错的详细信息。
前端还有一个特点，静态资源会稠浊后压缩，如果运行缺点，拿到的报错堆栈信息没有太大含义，只会报第一行报了xx缺点，假设有sourcemap，我们也只能借助Chrome Devtools来看详细是哪儿缺点，但每每线上的报错，我们很难复现。
通过前面提到的两个问题的网络：统计平台报错信息网络不足详细，无法根据报错反解源码缺点行数，我们选择基于开源Sentry在百度云上搭建了一套前端非常监控做事。
设计方案选择先来先容一下Sentry功能。Sentry是一个集中式日志管理系统。可以做以下事情，而且是比较于其他系统做的不错的地方。
丰富的SDK。不同措辞、不同项目通过集成SDK。拿JS举例，不仅仅网络详细的用户设备信息，而且记录了用户的操作行为，通过点击了XX按钮，导致的报错根据网络的数据，进行报警配置，进而实现监控的闭环。支持标签功能，比如我们可以通过给缺点统一拦截，增加标记CUID，后期在后台平台中同过CUID进行缺点过滤易于操作的后台。Sentry供应了一套后台管理系统，大略易行API支持。所有操作接口都供应了API做事，用户可以基于API进行界面自定义生动的社区。Sentry小组在Github上非常生动，之条件Issuse 基本都是当天回答办理的。再来看下K8S首先提一下当下流行的Docker（是一个开源的运用容器引擎），Docker有一句口号：Build Once , Run Anywhere. 也便是说一个环境可以通过一次编译发布，在任何支持Docker的环境中可以快速跑起来，这办理我们日常支配环境的痛楚。但是大家实践的时候创造，如果想要将Docker运用于详细的业务实现，是存在困难的——编排、管理和调度等各个方面，都不随意马虎。以是K8S（全称：kubernetes，基于容器的集群管理平台）应运而生，运用于广大的实际项目中
先容一下百度云。广告一波自家的供应的云做事平台：百度云。百度云供应了丰富的根本做事支持，比如强大的容器做事CCE，域名解析分发做事ITM，数据剖析做事Sugar等。我们可以基于百度云供应的做事快速达成想要实现的内容。
CCE供应根本的K8S容器环境ITM 智能域名解析调度，支持根据不同地域、网络选择不同机房机器Sugar 可以根据数据库数据，进行定制化报表拖拽式构建整体架构本身Sentry支持源码支配和容器（Docker、K8S）支配两种办法，考虑到稳定性，想要实现多机器多机房支配、负载均衡、智能调度等实际问题，基于百度云供应的K8S做事，容器化支配了Sentry，如图1。
图1 ：Sentry 百度云支配架构
结合业务，连续看一下Senty在整体项目中地位置，如图2。
图2 ：项目整体架构图
这种架构下的Sentry做事，有几个上风：
节省大量人力。基于百度云K8S运维省去了 日常机器运维、数据库、流量调度等人力本钱；节省大量机器。K8S运维，可以机器动态根据业务运行的情形，进行扩缩容；基于开源项目，社区丰富，问题有群体谈论，问题办理迅速；覆盖业务广，核心的做事供应了数据网络和剖析的能力，接入层可以自定义实现。实现平台在梳理清楚了上面流程的根本上，很快就搭建了起来。但是在平台试运行活成中，监控的每个环节，不同程度的暴露除了一些问题。针对监控的每个流程环节，再次做了进一步的剖析和优化。下面针对紧张环节进行解释。
打点上报监控信息上报，紧张依赖于SDK。以前端为例，Sentry本身供应了一个SDK，须要在页面加载过程中，优先加载，进而实现尽可能多的缺点捕获。
<html><head><title>监控报警</title><script src="https://xx/sentry.js"></script></head><div>......<div></html>复制代码
实践过程中，创造打包后的sentry.js 有20K旁边，如果放到顶部，对付追求页面性能的页面来讲，是灾害性的，由于JS放在顶部加载会壅塞页面的渲染。于是这对这种情形，进行了SDK后置优化。
<html><head><title>监控报警</title><script>let estack = err => {return win[ers].length < 10 ? win[ers].push(err) : false;};win.onerror = (a, b, c, d, error) => {estack(error);return true;};win.addEventListener('unhandledrejection', error => {error.preventDefault();estack(error);return true;});<script></head><div><script src="https://xx/sentry.plus.js" async ></script><div></html>复制代码自定义拦截error和promise缺点，页面加载结束后，统一进行缺点上报扩展sentry.js，升级为sentry.plus.js ，支持创造原有缺点的网络，进行数据详细上报。
通过SDK的改造，大大减少了页面对于性能方面的担忧，更加放心的利用Sentry做事。
日志采集SDK集成之后，日志采集通过一个POST接口要求实现。页面运行时，如果报错，会自动触发通过接口发送数据。
这时候是否须要支持采样，成了一个须要考虑的问题。由于如果没有采样，同时遇上较大的业务量，极大概率触发日志采集功能，大量日志上报，而有用信息较少。这时候采样就办理了这个问题。SDK本身是支持采样的，初始化的时候，只须要进行大略的配置
Sentry.init({dsn:'xxx',sample: 0.5 });复制代码
这个抽样，指的是项目运行时，每次触发报错后，是否要进行缺点上报的一个概率。但是对付追求页面性能的页面来讲，常日每每希望的是，SDK小流量接入。尽可能少的去影响所有页面。我们目前页面基于Php的Smarty模板进行的首屏渲染，以是改造了上报采集的方法：
{%assign var="random" value="{%math equation=rand(1,100)/100%}"|string_format:"%.2f"%}{%assign var="sample" value="0.5"|string_format:"%.2f"%}{%if $random < $sample%}<script type="text/javascript" src="https://xx/sentry.plus.js?v={%$smarty.now%}" crossorigin="anonymous"></script>{%/if%}复制代码
通过改造，又跟进一步减少了监控代码对业务的影响，业务更加方便的接入。
日志存储本身Sentry利用的是PostgreSQL，K8S支配时，数据库这里通过配置，利用百度云供应的数据库做事。
postgresql: enabled: false nameOverride: sentry-postgresql postgresqlDatabase: sentry postgresqlHost: 192.168.1.1 postgresqlPassword: xxx123 postgresqlPort: 3306 postgresqlUsername: sentrydb复制代码
数据库的用度也是挺贵的，霸占了整体1/3资源的消费。业务接入的越多，存储数据量越大，一开始买的50G空间，很快就满了。
数据到底要不要，我剖析了一下：对付报错本身的数据，尤其是每个缺点的详细信息，没必要存储那么久，但是对付报表性子的内容，如报错总体情形的同环比，须要存储更早以前结果的。
第一种方法，土豪的做法：数据库扩容，连续增加投入购买。这种便是资金预算投入；
第二种做法：根据现有，网络缺点的内容，把须要做报表的结果打算后单独存储，然后定期数据库清理，比如可以起一个脚本，进行定期请里10天前数据。
这里有一个小插曲，Sentry官方实在供应了清理数据库的API，可以通过命令进行清理：
// 进入容器docker exec -ti xxxx /bin/bash// 清理sentry cleanup --days 0复制代码
数据虽然清理了，但是创造PG数据库的容量没有开释，这是由于cleanup的利用delete命令删除postgresql数据，但postgrdsql对付delete, update等操作，只是将对应行标志为DEAD，并没有真正开释磁盘空间。通过以下命令，彻底清空。
sudo -u postgres vacuumdb -U postgres -d sentry -t nodestore_node -v -f --analyze复制代码报表展现
前面也提到过，Sentry供应了大略友好的后台管理系统。项目概况中，可以表示数据的报表展现。如图3。
图3：大盘展现
实践过程中，尤其是给老板申报请示的时候，创造只有这样的一个展现报表是不足的。经由调研创造百度云供应Sugar做事。可以直接链接数据库，对想要的数据自定义进行数据聚合，产出对应报表。这个产出需求还在调研中，不过产出的效果是非常令人期待的。配置内容如图4，预期效果如图5。
图4：配置内容
图5：预期效果
监控报警做为监控的闭环，我们可以在Sentry后台中，根据不同的规则，设置邮件报警。Sentry官方建议的邮件做事也一直在变更，最初的Exim4改为了mailgun，综合考虑用度的问题，我们终极还是选择docker搭建Exim4，然后邮件内容通过申请公司邮件安全组，白名单放开发送邮件的机器。终极实现了缺点信息及时关照业务的功能。效果如图6。
图6：监控效果
以上便是在详细实践过程中，关键路径碰着的一些问题，分享给大家。
思考监控的意义盈利公司的目的是盈利。一方面公司要掌握本钱，我们可以看到投入QA人力日益减少，另一方面又须要我们线上运行的代码更加稳定，有什么办法可以做到呢？一个高效的方法便是加强监控。
效率通过监控，可以快速自主地创造问题。
可以将网络上来的数据进行分类筛选，然后设置报警奉告。根据我们监控内容，设定不同的阈值，当达到阈值的时候，第一韶光有效的关照到对应的研发职员，进行剖析和修复。
通过监控，可以全方位理解页面运行情形。
通过信息网络，可以获取到用户访问的区域、机型、APP版本等根本用户信息，同时也可网络到页面运行时的性能，要知道性能便是金钱（打开速率一定程度上会影响用户的去留）。
通过监控，可以辅导后期项目开拓。
经由一段韶光的沉淀，我们网络过的缺点，可以绘制出一个报表，统计出我们某段韶光内问题产生的缘故原由、报错、办理方案。
规范从研发流程上来看（如下图所示），我们的项目不是完成上线就万事大吉。须要监控页面线上运行情形，根据监控的数据及时进行复盘，循环迭代优化，形成持续的研发闭环生态。
以上这些监控的意义，这天后流程机制的指南，是研发同学的行为准则，也是老板、高工某些关键时候做决策的参考内容之一。通过监控，更加直不雅观地、全方位立体化地理解产品。
中台计策中台是公司内部最近技能方面的计策方向。在我看来：监控可以输出一个中台的方案，各部门基于中台做事进行定制化扩展。
实在我们这里分享的Sentry系统，就可以作为公司内部的一个中台做事进行输出。各部门可以根据业务去定制SDK，也可以根据数据需求，自定义报表和报警。全体Sentry黑盒对外供应API做事，由于K8S带来的便利性，只须要对应部门供应预算，申请机器，往K8S上面增加缩减即可。
市情上实在已经存在很多不同种类的监控工具。比如：frontjs、arms、岳鹰等，但是很遗憾，创造大多是收费的。公司层面的产品，数据体量相对较大（但这方面的投入每每是值得的），有时数据产出较慢，结果每每阶段性地被新产品替代，厂内现在有一些针对前真个监控平台，诸如：天幕等，可能数据的采集、存储、过滤、展现、报警等监控过程中的每个环节，都须要须要耗费的人力和财力，这些都还短缺一些中台的思路。
总结通过搭建和实现监控的全体过程，一方面充分体会到了云做事供应的技能给产品带来的便利，一定是未来的方向；另一方面，分开业务的技能是不靠谱的，技能做事于业务，我们实现的技能一定要在业务中进行验证，才会促进技能更加完善，更加办理业务的实际问题。
本文转载于掘金，出处不详，如有侵权联系删除。
