問題背景：前段時(shí)間通過大數(shù)據(jù)的反饋啊，發(fā)現(xiàn)前端的log埋點(diǎn)存在大量丟失的情況，從被反饋業(yè)務(wù)來看，丟失率應(yīng)該在百分之10-15之間！

分析過程：
1、通過對(duì)比大數(shù)據(jù)給過來一天的訂單記錄，和我們本身記錄的log埋點(diǎn)中打入的訂單記錄對(duì)比發(fā)現(xiàn)的確存在丟失情況。
2、通過日志對(duì)比發(fā)現(xiàn)所有丟失的全部都是采用的https。
3、聯(lián)想到我們埋點(diǎn)的方式用的是nginx的插件empty.gif，大意原理是發(fā)送一個(gè)空?qǐng)D片，再加上我們現(xiàn)在大量連接采用了https，在某些機(jī)型（安卓7.0）上https打開的頁(yè)面內(nèi)部不允許訪問http的圖片，故定位問題和https有關(guān)。

嘗試解決：
將埋點(diǎn)的域名增加一個(gè)https域名，在連接為https時(shí)埋點(diǎn)也走h(yuǎn)ttps，連接為http時(shí)保持原來的http域名，原因是https雖安全但響應(yīng)時(shí)間會(huì)稍慢，而且對(duì)服務(wù)器資源消耗也要大一些，所以沒有必要走的時(shí)候就不走了！

觀察驗(yàn)證：
增加https后在線上跑了幾天后驗(yàn)證日志是否有丟失，從大數(shù)據(jù)拿過來一天的訂單再次和我們的log對(duì)比，發(fā)現(xiàn)完全匹配成功！

結(jié)論：
基本上可以斷定了之前l(fā)og丟失和https連接，但我們埋點(diǎn)采用的圖片是http有關(guān)！

小補(bǔ)充：

1、根據(jù)域名判斷埋點(diǎn)域名：

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

2、在很久很久以前，https的連接內(nèi)部訪問http的接口是被叫做安全降級(jí)，會(huì)被攔截掉，但https內(nèi)走h(yuǎn)ttp的圖片等靜態(tài)資源并不會(huì)被攔截，但不知何時(shí)起，一些移動(dòng)端的機(jī)型https連接內(nèi)的圖片也被攔截了，既然圖片被攔截了，靜態(tài)資源文件估計(jì)也很難幸免，所以在引用外部的靜態(tài)資源時(shí)要實(shí)現(xiàn)考慮下自己將來提供出去的連接是否為https，是的話引用的外部靜態(tài)資源也要是https的。