最近工作中的一個問題，耗時一個月之久終於調查完畢且順利解決，頓時感慨萬千。耗時之久和預期解決時間和環境搭建以及日誌不合理等等有關，當然這個並非此文的重點。
之所以在很久以後的今天又開始寫文，主要是這個問題調查的過程值得銘記。具體情況如下文述。

一、問題發現過程
資料告警服務提示相關分析結果缺失，經初步調查，發現分析服務在呼叫對應的NLP演演算法服務時出現大量Failed，遂檢視演演算法日誌，確實存在錯誤資訊。

二、問題調查和解決
1.定位問題
1) 反饋給演演算法相關開發同學：他們認為可能是該演演算法遇到了長文字資料（超過3000字），由於分析時間超長，導致後續演演算法請求時出現阻塞而導致failed。

2) 根據開發的反饋，開始定位是否存在這樣的長文字資料：通過分析日誌和資料庫查詢確認後，並沒有分析長文字資料，且出現異常時的文字資料均為短文字（小於200）。
3) 深入調查：該演演算法部署了多個節點，出現異常時，多個節點均出現了異常，因此可能是演演算法本身遇到了某個瓶頸問題。經確認，該演演算法使用了同一臺GPU伺服器上的tf-serveing服務。
4) 確認GPU伺服器是否發生了異常情況：經確認，該伺服器進行過VIP漂移操作。
5) 問題是否可以復現：測試環境中，對GPU伺服器進行vip漂移操作，發現錯誤現象出現，問題可復現。
因此，問題的起因是GPU伺服器進行了VIP漂移操作，導致演演算法出現異常。

2.調查問題
1) 瞭解vip原理，初步瞭解後，覺得可能是我們的演演算法缺少超時設定，因此演演算法中新增超時設定後，再次進行測試
備註：keepalived可以將多個無狀態的單點通過虛擬IP(以下稱為VIP)漂移的方式搭建成一個高可用服務，常用組合比如 keepalived+nginx，lvs，haproxy和memcached等。
它的實現基礎是VRRP協議，包括核心的MASTER競選機制都是在VRRP協議所約定的。
2）一輪測試發現：問題仍然存在，修復失敗，且無新增日誌。於是，我們要求增加日誌資訊，並以Debug方式啟動演演算法，進行二輪測試。
3）二輪測試發現：問題仍然存在，出現新的錯誤日誌，錯誤資訊為：Connect error: No route to host(errno:113)。

百度一番，都說是server端的防火牆設定了過濾規則；但是，Server端並沒有，怎麼辦？
Server端抓包：
經抓包發現，GPU伺服器完成vip漂移需要耗時4s左右，然而，演演算法在漂移開始的2s內傳送了近20次請求之後無請求。
問題的根源（可能）：Server端vip漂移未完成時，演演算法卻傳送了大量請求導致Server端的tcp連線池滿，後續server端不再為其他請求分配資源。

3.解決問題
1）根據調查的原因，修復方法是：sever端在進行vip漂移完成前，儘量減少演演算法的請求次數，因此我們對該演演算法進行了超時重試次數的設定和請求間隔的設定（可配置）。
2）演演算法修復後經測試，問題解決。

三、總結
1）合理且重要的日誌輸出對於問題的定位和調查非常重要
2）涉及HTTP請求的問題調查時，服務端抓包有必要
3）Linux 的errno113問題並不一定是設定了防火牆導致的

備註：
（一）vip環境：用來給K8s做三節點高可用，被K8s的kubeproxy的ipvs方式轉發到具體pod，四層轉發，tcp協議（NAT模式）
（二）Linux errono命令