感觉已经好久没有写博客了，也是一直在开发新的项目，眼看项目逐渐进入尾声。趁热整理一下，近期做的有关广告页面监控的项目。
看过我前几篇文章的话，应该了解我一直在开发、维护，我部门广告的前端展示。但是既然是人写的的代码，又怎么会一点错都不犯呢？尽管有自动化测试、测试人员的功能性测试也难免在实际使用中，数据不匹配造成的浏览器端的抛出异常、资源不展示等一系列的页面广告异常。那么我们平常是怎么发现并处理这些异常的呢？在没有监控的时候，往往是投放和业务同事，甚至是客户发现的。业务同事发现的会发邮件，客户发现，就会投诉，如果问题比较不好修复或处理的不及时，就会造成退款等一系列严重的后果。这样我们显得很被动。
如何应对这样一种被动的处境。首先我们先分析一下，这种处境是怎么造成的？首先广告异常的出现是无规律的，我们可以优化处理问题的反馈流程。我们看一下原来的反馈流程（如图1）：
可以看出，在客户（或业务同事）发现，反馈到解决问题重新上线这段时间是很短很仓促的，我们在修改的过程中很容易造成二次bug。而在上线到客户（或业务同事）发现问题这段时间有比较充足的时间，我们利用后者的时间段修改bug要比前者要时间充足并且可靠的多。我们可以利用大段的时间来用于修改问题，甚至提前与客户发现问题，而在客户发现问题前修复上线，并减少问题在线上停留的时间。所以我想出了下图的处理问题的机制，新的机制主要在于利用主动监控来缩短问题暴露的时间，加快处理问题的进程。
接下来要做的事情就是开发这样一套监控报警机制。
客户端想要记录报警日志，就必须向后台发送异步请求。整套系统分为前台和后台两大部分。
我主要负责前台这方面的开发，而在前端的工程中有两个大的模块。监控与报警。下面分别针对这两个方面来分析一下开发时的注意点。
一、监控
说到监控就是发现问题，整理封装成一定的格式，并发送给报警模块，交由报警模块来处理。要监控的方向主要分几个维度：业务、技术、主动层中间件、被动监听等。广告的展示逻辑是由我们写的我们只要编写好一个相关模块，暴露出api在各个监控的代码逻辑中调用即可。
1、主动层中间件，我们在自己的js代码中加入中间层的验证，其实是很方便的，我们自己是很了解这一段js写的是什么，入口数据应该满足那些验证、期望出口得出哪些数据我们应该主动在容易出现问题的关键节点，加入我们的验证判断。这样也能跟好的定位问题是来自上游数据还是自身逻辑。要注意的是中间件的处理不能阻碍正常的js逻辑。所以建议将这一层做成异步的。对于监控来说，数据验证的结果，并不应该影响后续的正常逻辑，也不能作为其依据。
2、被动监听，这种主要是依赖浏览器提供的错误事件以及对有危险的js进行try catch。相应的api主要有window.onerror <img>的error事件和 try catch 等。
3、以上的都是技术层面的监控。但是很多的问题其实是来自以于业务需求的，结合需求找到对应的点，进行业务逻辑的验证，看看是否符合需求。
二、报警
简单来说报警是对监控所得的数据的提交。我们很容易想象到要通过异步接口的方式来实现。要注意以下几点：
1、是公司的页面不一定都在同一个域名下面，所以要做跨域处理。这个不难，jsonp就可以了。
2、有监控层面来的数据五花八门，这是一个提交数据的写入接口，对于安全性的要求我们自然要注意，安全起见，我们采用参数绑定的方法，将错误分为几类（我的项目中错误一共分为10类）约定了不同的替代参数。上面的错误类型只是大体上的划分，并不能准确的描述问题，我加入了补充说明的参数，当然补充说明的字段也是和后台约定好的，超出这个范围的值，都认为是不合法的请求，不会记入数据库。
3、由于我们的参数有限定，那么重复的请求（除了时间以外的所有参数都一样）将在一定时间段内不会记入。基本策略参考了debounce的思路，相同请求的最后一次开始一段时间内，不在处理相同的请求。
总结，以上就是我最近开发广告页面监控的大体思路，没有粘出具体的代码实现怕限制了大家的实现，相信也不难理解。在这条持续集成的路上，很高兴可以不断的将更深层次的需求，结合技术实现的挑战。