寫在前面
記錄一次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變的可控，不會隨用户數據增加而變多。
