背景介紹

某日收到工單，用戶反饋在6.8.2版本的kibana中，對在Discovery中查詢到的數(shù)據(jù)想導(dǎo)出到CSV文件，點(diǎn)擊"生成CSV"按鈕無響應(yīng)，如下圖所示：

image

從瀏覽器中看到點(diǎn)擊按鈕發(fā)起的請求失敗了，什么也沒返回，比較奇怪。

問題追蹤

1. 這應(yīng)該是kibana的問題！

從瀏覽器的Source中可以看到有報(bào)錯(cuò)，kibana對于收到的響應(yīng)沒有正確的處理，js代碼報(bào)錯(cuò)，第一直覺是和客戶使用的中文版的kibana有關(guān)，之前出現(xiàn)過中文版的kibana，在報(bào)告名稱為中文時(shí)無法生成CSV，所以憑借經(jīng)驗(yàn)就覺得這肯定是kibana的問題。

image

所以緊跟著，嘗試對其它的index pattern，生成CSV報(bào)告，發(fā)現(xiàn)不管報(bào)告標(biāo)題是不是中文的，都可以執(zhí)行成功；然后發(fā)現(xiàn)客戶創(chuàng)建的namespace命名空間也是中文的，嘗試重建了一個(gè)英文的namespace, 發(fā)現(xiàn)可以執(zhí)行成功；切換到客戶的namespace下，對其它的index pattern創(chuàng)建報(bào)告，也都可以執(zhí)行成功；十分詭異的問題，單單就這一個(gè)index pattern有問題？

之后查找kibana的日志，發(fā)現(xiàn)沒有錯(cuò)誤日志，不僅如此，在點(diǎn)擊"生成CSV"按鈕后請觸發(fā)HTTP請求的日志都沒有，這就奇怪了，難道請求沒有發(fā)送過來？然而其它的成功創(chuàng)建CSV報(bào)告的請求，都可以正常響應(yīng)并且kibana的日志中也有記錄，這是哪里出問題了？

2. 莫非是瀏覽器的問題？

在瀏覽器中反復(fù)發(fā)起請求，查看網(wǎng)絡(luò)調(diào)用，發(fā)現(xiàn)發(fā)起的請求的響應(yīng)是net:ERR_CONNECTION_CLOSED, 之前沒有注意到這個(gè)錯(cuò)誤，只以為是kibana向某些遠(yuǎn)端地址發(fā)起請求加載資源時(shí)，因?yàn)榫W(wǎng)絡(luò)不通導(dǎo)致的請求失敗。仔細(xì)查看這個(gè)錯(cuò)誤，應(yīng)該是http請求被對端關(guān)閉掉了。

再次查看錯(cuò)誤請求的URL和參數(shù)，發(fā)現(xiàn)錯(cuò)誤請求的URL非常長，如下所示：

image

URL之所以這么長，是因?yàn)榭蛻羰褂昧藄cript_field對索引的字段名稱重寫為中文，之后嘗試選擇少量的字段導(dǎo)出，發(fā)現(xiàn)可以正常創(chuàng)建報(bào)告，逐漸增加字段到一定程度后，就報(bào)錯(cuò)了？ 問題逐漸清晰，肯定是哪里有限制，導(dǎo)致http請求發(fā)送不出去或者是請求被拒絕掉了。難道是瀏覽器有限制？通過Google，查看到chrome瀏覽器對GET請求的URL長度限制為8182個(gè)字符，POST請求是沒有限制的，POST請求一般都取決于服務(wù)器端的限制。而查看錯(cuò)誤的請求的URL長度，發(fā)現(xiàn)只有不到7000個(gè)字符，所以，應(yīng)該不是瀏覽器的問題，那是哪里的問題呢？

3. 可能是負(fù)載均衡器的問題了

因?yàn)閗ibana的域名對應(yīng)著一個(gè)負(fù)載均衡實(shí)例(使用的是騰訊云CLB)，該負(fù)載均衡實(shí)例的七層HTTP請求轉(zhuǎn)發(fā)本身是通過NGINX實(shí)現(xiàn)，所以會不是是觸發(fā)了NGINX的什么限制呢？還是Google發(fā)現(xiàn)有人因?yàn)樵贜GINX中使用了HTTP2導(dǎo)致服務(wù)器無法正常返回，連接被關(guān)閉：neterr-connection-closed-error-at-chrome-with-http2-0-nginx, 然后去確認(rèn)負(fù)載均衡實(shí)例的配置，發(fā)現(xiàn)默認(rèn)開啟了HTTP2.0, 直接關(guān)閉HTTP2.0， 發(fā)現(xiàn)生成CSV的請求正常了，問題找到了。

那具體是觸發(fā)了NGINX的什么限制呢？可能是HTTP請求headers長度的限制，因?yàn)閁RL長度過長的時(shí)候，才會觸發(fā)。
通過查找資料，發(fā)現(xiàn)NGINX的HTTP2模塊中，配置http2_max_field_size默認(rèn)大小為4K, http2_max_header_size默認(rèn)為16K, 應(yīng)該是就是觸發(fā)了http2_max_field_size的限制，因?yàn)楫惓Ｕ埱蟮腢RL長度達(dá)到了接近7000個(gè)字符。

但是使用HTTP1.1協(xié)議，就沒有觸發(fā)限制，發(fā)現(xiàn)NGINX的ngx_http_core_module中，對請求行和請求header的大小由參數(shù)client_header_buffer_size控制，默認(rèn)為1K, 當(dāng)請求行或者h(yuǎn)eader的長度超過1K時(shí)，則由large_client_header_buffers參數(shù)控制內(nèi)存分配，默認(rèn)為"4 8K", 請求行或者h(yuǎn)eader的大小不能超過8K, 總的請求行和header大小不能超過4*8K;如果請求行大小超過8K, 則返回414錯(cuò)誤，某個(gè)請求header大小超過8K, 則會返回400錯(cuò)誤。因?yàn)殄e(cuò)誤請求的URL大小不到8K, 所以在使用HTTP1.1協(xié)議時(shí)，沒有觸發(fā)限制。

問題最終得到解決，可以在開啟HTTP2.0時(shí)，調(diào)大http2_max_field_size參數(shù)到8K，避免觸發(fā)該限制。

經(jīng)驗(yàn)總結(jié)

經(jīng)驗(yàn)往往是有用的，但是執(zhí)迷于經(jīng)驗(yàn)可能會導(dǎo)致走彎路，所以還是得具體問題具體分析，注意問題的細(xì)節(jié)特點(diǎn)，從而快速的解決問題。