技術人生系列——追蹤圖數據庫中“突然隱身”的通信連接
日期：2021-02-23
圖數據庫作為新興的數據庫技術熱點，正在廣泛的被各大銀行客戶采用。作為NoSQL數據庫中最為突出的代表，圖數據庫對目前各種比較火熱的精準營銷業務場景、風控業務場景、客戶圖譜場景都能提供強大的底層支持。中亦大數據產品團隊作為國內銀行業接觸圖數據庫較早的技術團隊，為各大客戶持續提供平臺層面的技術支持能力。
最近，我們在客戶現場的圖數據庫生產集群中遇到了一個罕見的通訊故障：數據庫的導入組件和內部組件的通信通道會不定時丟失，且再也無法建立。經過現場反復協調排查和遠程持續分析排查，并聯合了中亦工程師和美國原廠的核心技術力量，終于分析出引發故障的系統原因并最終排除了故障，整個過程歷經不少波折，真相大白水落石出時，大家都恍然大悟，原來是這樣簡單的原因——雖然答案和解決方案很簡單，但是在分析過程中，由于大數據復雜的技術架構，需要抽絲剝繭，逐個分析可能因素，所以相對于最終的結果，這樣的分析過程更值得記錄，借本期技術人生系列文章，分享給大家。
一、故障描述
TG圖數據庫集群狀態gadmin status均為正常工作狀態，m1、m2、m3節點間連接狀態均為正常，且TG所使用端口無被占用情況。在跑生產批量日更腳本中加載數據部分時，發現加載任務有一定幾率卡住在讀取文件步驟，且卡住后未產生報錯日志和加載任務日志。經TG的Abort命令打斷當前加載任務后重新運行多次該加載任務，故障依舊；gadmin start命令重啟集群后，可成功運行該加載任務；重啟后仍有一定幾率重新發生此故障。
簡單來說，在無人干預的情況下，原來正常的數據導入進程會hang死。重啟后正常一段時間后，又會繼續hang死，且圖數據庫層面通訊的兩端組件都沒有收到報錯。
通過上圖，我們可以了解到，TigerGraph圖數據庫導入的基本原理：
1、每個節點admin組件會有一個線程定時輪詢集群中每個節點的8500端口，嘗試建立TCP連接。
2、當某個節點，如m1節點開啟導入任務時，會開啟restpp-loader進程，監聽本地的8500端口，這時自然會和admin的線程建立連接。
3、通過建立好的tcp連接進行數據通信，由本地的restpp-loader讀取文件，數據轉換，傳送至admin和其他組件，從而進行下游的導入任務。
二、排查過程
1.初步排查定位原因
我們首先針對TigerGraph版本，License，Schema腳本和loading腳本、數據源格式及生產機器內存硬盤資源進行了一一檢查，均無發現異常?；究梢源_定原有的流程是沒有邏輯上的問題。
緊接著，我們對圖數據庫產品底層組件一一進行了故障排查。首先是對TigerGraph的Kafka、Nginx、GPE、GSE、GSQL、ZooKeeper、DICT、TS3、Restpp等組件的檢查，經檢查發現產品各組件均正常運行，日志文件均無報錯情況。
經采用小批量數據進行測試并進行后臺日志監控，我們發現一個特殊的現象：集群主節點m1不能接收到加載任務，而m2、m3可以接收到，那是否可以說明這其實是一個節點通訊的問題？但是我們緊接著分別對m1、m2、m3進行多次的測試，故障依然存在。這說明不光是 m1 主節點無法和其他節點通信，其他節點之間也會不定時無法建立連接。隨著對數據流的逐個環節的分析，發現是RESTPP_LOADER所在的節點無法接收到本節點所發的請求，如下圖所示，我們初步定位到了故障點：restpp-loader 嘗試去與8500端口建立連接的線程出現了異常。
2.嘗試排除環境中其他軟件的干擾
首先我們可以判斷TigerGraph本身是沒有問題的，因為在研發環境一直都是正常運行的。那么就需要判斷是生產環境中安裝的其他軟件對TigerGraph造成了干擾，還是linux系統環境的不同導致了故障的發生。
遂在生產環境裝有conductor、ctm等軟件的其他節點，以及未安裝上述軟件但系統環境大致相同的兩個節點，分別成功安裝了TigerGraph單節點企業版。經測試，發現安裝有conductor、ctm等軟件的節點上的TigerGraph復現了生產環境三節點集群的數據加載故障，而未安裝上述軟件的節點可正常運行所有任務，無故障產生。經行內老師協調，臨時關閉了生產節點的conductor和ctm服務，但故障依然存在，且故障依然為GSE與RESTPP組件通信受阻導致。
如下圖顯示，簡單來說，在有其他軟件的環境會出現故障，在“干凈”的環境中正常運行，關掉其他軟件依然有故障復現。那么真相直接指向唯一的一個方向：由于安裝其他軟件，修改了某項系統配置，引發了這個故障。
3.設置監控腳本進行監控
問題分析到這里，我們再次回過頭去分析哪些系統配置可能影響端口的情況。
首先是看系統資源限制，發現配置都比較正常：
接下來分成兩個方向進行排查：
◆ 通過gdb在產品層面打斷點去分析
這個方向的考慮是希望在美國原廠的支持下，對TigerGraph圖數據庫進行調試，在導入組件內部通過打斷點的方式，發現組件層面的報錯。之前已經分析過了，在產品提供的通用日志中并沒有提供報錯信息，那么我們本質上是去提取debug級別的日志。
令我們困惑的一點是，在debug日志中只能看到某一次程序從線程池中取得線程，并去建立連接，并且建立了連接！但是這個連接從此就消失了，并且從系統的nestat無法找到？！這是讓我們百思不得其解的一點。
程序認為連接已經建立，系統中卻找不到建立的連接，那么這個連接去哪里了？
◆ 通過shell腳本在系統層去監控進程和網絡情況
既然從產品層面無法獲得更多信息，我們把思路轉向系統層面，通過監控系統的進程情況和網絡情況，來定位到故障發生的瞬間，到底發生了什么。
4.分析監控日志最終發現原因
如果您能有耐心看到這里，想必也能或多或少體會到這個問題的詭異程度。已經可以確認就是端口之間通訊的問題，但是又找不到這個“隱身”的連接到底去哪了？
在系統運行一晚后，我們分析了監控日志，我們發現在某一個時刻連接自己8500端口的線程突然消失了。
我突然聯想到之前查到的一個資料：因為TigerGraph底層用了zmq進行通信，我在社區中看到一個人在2013年提交了一個issue，說他發現在大并發的情況下，他寫的單機程序會時不時的hang住，建議zmq修復這個bug。他遇到的問題和我們很像，但是這個issue沒有被fix，而是被關閉了，說明zmq的社區管理判斷他提的并不是一個真實的bug。
但是在他的描述中出現了self connection ，這個詞就像一道閃電，照亮了整個黑暗。我再次聯系美國開發，他也立馬反應過來，去查看關鍵的系統配置項，果然真相大白，我們苦苦追尋的配置項就是下圖中的：
正常的配置應該是如下：
該配置項是linux為了區分服務端程序可用端口和客戶端可用隨機端口而設置的，就是為了防止端口沖突。在這個故障中，TigerGraph所在集群的默認系統配置中
/proc/sys/net/ipv4/ip_local_port_range
的32768 60999被修改為1025 65535。在這個配置修改后，客戶端在申請隨機端口連接服務端的時候，有一定概率申請到8500端口，從8500端口去與8500端口建立自連接，從而導致TigerGraph組件認為連接建立，而系統卻認為服務未建立，進而導致整個導入功能的異常。而重啟過后能正常一段時間的原因就是在圖數據庫進程關閉后，在8500端口隱身的線程連接也會被系統回收。
為了保險起見，根據這個原因，我們在多個安裝且正常運行TigerGraph的環境中修改了系統配置，并都復現了生產環境的故障。
到此為止，我們完全確定了故障的發生原因。
三、故障修復方案制定與執行
1.修復方案
故障由/proc/sys/net/ipv4/ip_local_port_range的默認配置被修改導致，行內老師協調，將該設置還原系統默認設置，以解決TigerGraph加載故障。
具體步驟如下：
2.修復故障
經由行內老師內部自檢及評估后，暫未發現該系統設置被修改原因，遂將該設置修改回系統默認設置，TigerGraph再也沒有出現該加載故障。
四、故障總結
1.控制變量快速定位故障根源
在本次故障排除的過程中，我們面對的是一個復雜的分布式系統環境，系統環境本身與其他環境不同，而且在這個環境中還有多個軟件的潛在干擾。這個時候需要我們冷靜的采用枚舉法列出所有可能的故障原因，再通過控制變量法和排除法逐一去除干擾因素。排除一切不可能的因素后，剩下的肯定是正確的答案。
2.關鍵系統配置檢查
在定位到系統級別的問題時，應該第一時間檢查相關關鍵配置項。首先，我們需要定時監控維護這些配置項。在這次排除后，我們也無從得知到底是什么原因這個配置項被修改了。這警示我們可能在平時的工作需要關注這個方面。第二是需要了解這些系統參數的含義和配置方法，這就需要我們不斷對自己的技術進行提高。
3.廣泛積累夯實技術基礎、深入鉆研挖掘技術深度
這次排查問題，我們從圖數據庫產品本身技術架構，組件功能原理，到linux系統運行機制，考慮了很多技術問題和可能原因，這對我們提出了很大的挑戰。所幸這次有美國原廠技術力量并肩作戰，最終取得勝利，但是這次問題也鞭策我們平時需要廣泛的去學習技術知識，并在自己的技術領域持續深耕，正所謂博觀而約取，厚積而薄發。只有這樣，在考驗來臨時，我們才能舉重若輕的解決，為客戶創造價值。
