最近工作中的一個問題，耗時一個月之久終於調查完畢且順利解決，頓時感慨萬千。耗時之久和預期解決時間和環境搭建以及日誌不合理等等有關，當然這個並非此文的重點。
之所以在很久以後的今天又開始寫文，主要是這個問題調查的過程值得銘記。具體情況如下文述。
一、問題發現過程
資料告警服務提示相關分析結果缺失，經初步調查，發現分析服務在呼叫對應的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命令
