記錄一次uwsgi錯誤

寫在前面

記錄一次502錯誤，這個錯誤在測試服務器沒有發生過，只有到了prod環境才發生，先說明一下咱們的系統有單獨的一個用戶平臺系統，用戶登陸成功後，會將用戶信息加密放到redirect_url中，而後重定向到子平臺。子平臺經過參數跟本身的key，再作解密，獲取數據。

錯誤情況

服務上線之後，有些用戶登陸就報了502錯誤，表現的症狀是

• 隨機發生，可是有的人繼續訪問502的連接，就能夠登陸上，一樣，有些人訪問502的連接，也一直報502。
• 發生錯誤跟用戶瀏覽器綁定程度很高，好比一個瀏覽器發生過502，再發生的機率會很高，可是換一個瀏覽器，一樣的帳號就有很大的機率能登陸。
• 有時清理緩存後就行了，過一陣子又出了問題。
• 使用無痕瀏覽器的話，症狀緩解了不少，可是沒有徹底解決。
• 由於程序是django寫的，登陸過admin後臺的人，出現問題的機率會增長。
• 手機號註冊的用戶基本能登陸，可是微信掃碼註冊的用戶不少不能登陸。

錯誤排查

• 先查找日誌，從Kibana中查找的錯誤是nginx報錯：*1063309261 upstream prematurely closed connection while reading response header from upstream，根據這個現象，第一時間查的是nginx的問題，猜想是否是keep alive時間太短，致使讀數據沒讀完被強制關閉了連接。
• 排查uwsgi的日誌，其實當時先入爲主，由於uwsgi的log中沒有明確的報錯信息，以爲會是nginx那邊的問題，雖然502對應着網關錯誤，通常是uwsgi的問題，但先入爲主的思想致使對已經能提示錯誤緣由的日誌沒有過度關注。好比這條日誌：[pid: 50|app: 0|req: 2236/12394] 172.16.59.0 () {52 vars in 4089 bytes} [Thu Nov 14 08:55:34 2019] GET /login/?next=/text&data=9f3649e655416055e02f2a17ae558d75c

解決方案

• 由於跟nginx有關，並且微信登陸出現502錯誤的機率會增大，當時考慮的是找微信登陸跟手機號登陸的差別，發現微信登陸是掃碼以後，用戶平臺HttpResponseRedirect到子平臺的。而手機號是將地址作成redirect_url參數返回給前端，前端訪問redirect_url的地址。考慮到這層因素，可是HttpResponseRedirect的302會不會對nginx有影響致使了nginx報錯，因此第一個方案就將微信掃碼的信息加密後重定向到一個地址中，將地址放到GET請求的redirect_url參數中，前端讀取該參數，而後再跳轉，從而達到兩次登陸一致。
• 上述方法使用了以後，緩解了不少502，可是仍是有不少502錯誤，這個問題沒有徹底解決，考慮仍是其餘引發的問題。次日，產品的微信又登陸不了了，並且手機號註冊也登陸不了，讓她不要清理緩存，在接着登陸幾回，找錯誤日誌。這一次目標主要放在了uwsgi上，看到了一些請求日誌。[pid: 50|app: 0|req: 2236/12394] 172.16.59.0 () {52 vars in 4089 bytes} [Thu Nov 14 08:55:34 2019] GET /login/?next=/text&data=9f3649e655416055e02f2a17ae558d75c，結合以前upstream沒讀完就被關閉，懷疑是uwsgi主動關閉的，就考慮是否是某些緩存滿了，而後去找uwsgi相關參數，發現有一個參數爲buffer-size，這個參數默認值爲4k，當時以前的uwsgi說4089 bytes，猜想應該是這個問題，因此將該值擴大到8k，重啓以後，原來登陸不了的問題就解決了。

覆盤

• 覆盤想一下以前的症狀，由於目前咱們是用的authtoken的驗證方式，登陸admin後臺會在cookies多了session，加大了header，致使錯誤發生率提升。清理cookies，會減小header，因此發生錯誤機率會下降，無痕瀏覽器沒有百度統計的cookies，也會減小header的大小，產品常常多個帳號切換，會致使cookies的數據增多。
• 查找bug仍是不要先入爲主，按照經驗，應爲uwsgi沒有明顯的報錯，才致使了排查重點到了nginx和代碼層面。
• 這個bug在測試服務器沒有發生過，主要緣由是測試服務器當時沒介入微信註冊，致使都使用手機號註冊，因此在取用戶數據的時候，oauth的表中就沒有數據，減小了用戶信息加密的長度，致使沒有發生這類錯誤。

優化

• 後期仍是要增長監控的維度，打算增長uwsgi管理服務。
• 從新去研究下uwsgi的配置，排查可能將來可能致使問題。
• 將用戶數據拉去更改，用戶數據只加密用戶表的PK，子平臺獲取信息以後，經過Pk去平臺再拉去用戶的全部信息。這樣會減小url中的參數長度，使URL變的可控，不會隨用戶數據增長而變多。