建站
咨詢
售后
建站咨詢
新聞中心
具體現(xiàn)象
相比于程序的請求量，錯誤肯定是比較少的，但是錯誤一直在發(fā)生，會影響調(diào)用方的代碼，需要檢查下問題原因。
創(chuàng)新互聯(lián)是一家專注于成都網(wǎng)站制作、網(wǎng)站設(shè)計與策劃設(shè)計,紅橋網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)十多年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:紅橋等地區(qū)。紅橋做網(wǎng)站價格咨詢:13518219792
為啥只看到了POST請求
讀者肯定會說, 你們 ELK 過濾字段里面寫的是POST，所以肯定只有POST請求，其實不是這樣的，GET請求也會有502，只是Nginx會對GET請求進(jìn)行重試，產(chǎn)生類似如下的日志：
重試機制是Nginx默認(rèn)的: proxy_next_upstreamhttp://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream
因為GET方法會被認(rèn)為是冪等的, 所以當(dāng)一個upstream出現(xiàn)502的時候, nginx會再次嘗試. 對于我們的問題, 主要想確認(rèn)為什么有502, 只看POST請求就足夠了, 兩者的原因應(yīng)該是一致的。
網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)
網(wǎng)絡(luò)請求流入集群時, 對于我們集群的結(jié)構(gòu)：
用戶請求=>Nginx=>Ingress =>uwsgi
不要問為什么有了 Ingress 還有 Nginx。這是歷史原因，有些工作暫時需要由 Nginx 承擔(dān)。
統(tǒng)計排查
基于我們對于Nginx和Ingress的錯誤請求統(tǒng)計，發(fā)現(xiàn)兩者中的502錯誤是想等的，說明問題一定是出現(xiàn)在Ingress<=>uwsgi之中。
抓包
這個并不是最先想到的方案，因為我們用了很多統(tǒng)計方法也沒總結(jié)出來規(guī)律，最后只能寄希望于抓包了…該請求日志如下:
抓包結(jié)果如下：
從抓包情況來看，當(dāng)前的tcp連接被復(fù)用了，由于Ingress中使用了HTTP1.1協(xié)議，會在一次tcp連接中嘗試發(fā)送第二個HTTP請求，但是uwsgi沒有支持http1.1，所以在第二個請求根本不會被處理，直接拒絕了。所以在Ingress看來，這個請求失敗了, 因此返回了502. 由于GET請求會重試, 但POST請求無法重試, 所以訪問統(tǒng)計中出現(xiàn)了POST請求502的問題。
Ingress配置學(xué)習(xí)
Ingress中, 默認(rèn)對upstream使用的http版本為1.1, 但是我們的uwsgi使用的是http-socket, 而非http11-socket, 我們Ingress中使用了與后端不同的協(xié)議, 出現(xiàn)了意料之外的502錯誤。
??https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#proxy-http-version??
因為Nginx默認(rèn)是1.0, 但是切換到Ingress中默認(rèn)變成了1.1, 而我們沒有統(tǒng)一, 解決方案是強制指定Ingress中使用的http協(xié)議版本。
{% if keepalive_enable is sameas true %}
nginx.ingress.kubernetes.io/proxy-http-version: "1.1"
{% else %}
nginx.ingress.kubernetes.io/proxy-http-version: "1.0"
{% endif %}
如果有大佬看到了，可以簡單講講Ingress會在什么時候復(fù)用http1.1的連接，以及為什么Ingress不復(fù)用每一個連接，這樣問題會盡快的暴露，這些問題我沒有繼續(xù)深究了。畢竟你換個語言比如Golang就沒有這個問題了，這個是uwsgi專屬錯誤。
總結(jié)
有關(guān)這個502問題的排查, 我個人覺得, 最后抓包一次性解決問題其實沒什么特別的, 抓了就能發(fā)現(xiàn)問題, 不抓就發(fā)現(xiàn)不了。
我是希望給大家一個啟發(fā), 對于一整條鏈路, 如何來排查故障: 我們這里既使用了Nginx, 又使用了Ingress, 在排查時, 需要首先檢查兩者的錯誤數(shù)量, 如果確認(rèn)錯誤基本一致, 那就說明錯誤與Nginx沒有關(guān)系, 需要檢查Ingres上的錯誤, 對于多個中轉(zhuǎn)的請求, 這樣的排查能比較快的確定鏈路的錯誤位置。
當(dāng)前名稱：線上K8sIngress訪問故障排查思路，看這一篇就夠了
瀏覽地址：http://m.5511xx.com/article/dppjpii.html
