今天要说的是一个『静态资源异常监控』的话题。虽然静态资源异常可以非常有效的跟 JavaScript 异常结合起来做有力的分析，但是今天这个话题跟 JavaScript 异常没什么关系。
传说某著名公司的网站监控方案是申请了专利的技术，我有幸看到过，真的是非常牛逼。
这个网站监控方案中提供了网页的访问量、页面访问流向、页面有效点击量、点击热图， 灰度发布（包括 ABTest）等都有完善的支持。
这个方案总体上是用 JavaScript 通过 new Image() 发送监控的数据到日志服务器， 然后由数据仓库做数据清洗。
通过业务系统服务器端的日志分析，这套方案的数据质量有确实有一定的问题， 比如它统计到的访问量要比业务系统服务器端统计到的少，丢失率一般在 5% ~ 10% 左右， 少量特殊页面（比如跳转页）丢失率会高达 50% ~ 60%。
尽管如此我们也基本上可以接受这样的误差，而且部分从理论上讲，『应该』大部分是 无效或无意义的访问（比如爬虫、快速跳转等），丢掉是合理的。
一直以来，我们都认为这个方案的数据是相对比较可靠的，虽然偶尔有些不正常的丢失率 让业务方质疑，但是我们总是用上面的理论和理由解释给对方听，让他们接受我们的现实。
这样过了好多年，他们过着幸福的生活~
直到有个家伙的膝盖被射了一箭，搞出来个静态资源监控系统。
静态资源监控系统是通过分析静态服务器的访问日志，来统计各个资源状态的趋势及其分布情况。
因为静态资源监控是通过静态服务器访问日志来分析的，理论上和业务服务端的日志是一致的。
但是我们惊奇的发现某个静态页面引用了某个不存在的静态资源，异常率理论上应该是 100%， 但是对照网站监控方案统计的数据发现，这个静态资源异常率高达 200%。
我的第一直觉是网站监控丢失率高达 50%。遂跟网站监控相关同学沟通，然后他们第一反映 是质疑我对他们的质疑。
让业务服务端同学统计日志发现他们的访问量确实要大于网站监控访问量，但又小于静态资源异常量。
我虽然毫不怀疑自己的数据，但一时也无法质疑业务服务端的数据。
业务服务端同学随意说了一句：『难道有缓存？』
于是这个疑惑破解了：
- 用户访问页面时，有一部分可能是读取的本地缓存，这部分业务服务端无法统计到。
- 有些读取缓存的场景不会执行初始化 JavaScript，这些场景网站监控没有统计到。
- 外联的 404 资源是不会被缓存的。
因此这些有缓存的静态页面（这个知名公司有不少页面是这种纯静态、伪静态页面）的场景下，使用 JavaScript 发送监控的监控手段目前丢失率是 50% 左右。