前端埋点大量丢失的总结

问题背景：前段时间通过大数据的反馈啊，发现前端的log埋点存在大量丢失的情况，从被反馈业务来看，丢失率应该在百分之10-15之间！

分析过程：
1、通过对比大数据给过来一天的订单记录，和我们本身记录的log埋点中打入的订单记录对比发现的确存在丢失情况。
2、通过日志对比发现所有丢失的全部都是采用的https。
3、联想到我们埋点的方式用的是nginx的插件empty.gif，大意原理是发送一个空图片，再加上我们现在大量连接采用了https，在某些机型（安卓7.0）上https打开的页面内部不允许访问http的图片，故定位问题和https有关。

尝试解决：
将埋点的域名增加一个https域名，在连接为https时埋点也走https，连接为http时保持原来的http域名，原因是https虽安全但响应时间会稍慢，而且对服务器资源消耗也要大一些，所以没有必要走的时候就不走了！

观察验证：
增加https后在线上跑了几天后验证日志是否有丢失，从大数据拿过来一天的订单再次和我们的log对比，发现完全匹配成功！

结论：
基本上可以断定了之前log丢失和https连接，但我们埋点采用的图片是http有关！

小补充：

1、根据域名判断埋点域名：

var logHost = location.protocol.indexOf('https') > -1 ? 'https://*****.com' : 'http://*****.com';

2、在很久很久以前，https的连接内部访问http的接口是被叫做安全降级，会被拦截掉，但https内走http的图片等静态资源并不会被拦截，但不知何时起，一些移动端的机型https连接内的图片也被拦截了，既然图片被拦截了，静态资源文件估计也很难幸免，所以在引用外部的静态资源时要实现考虑下自己将来提供出去的连接是否为https，是的话引用的外部静态资源也要是https的。