使用xTCP進行大規模套接字性能監控

背景

CDN和雲提供商在網際網路上提供大量流量，並採用廣泛的監控工具來確保性能和可靠性。 這些工具包括涵蓋各種流量傳輸層的工具，例如網路，伺服器，應用程式等 TCP/IP佔了這種流量的大部分(雖然基於UDP的QUIC在全球範圍內呈上升趨勢，但與TCP相比，它仍佔總流量的一小部分)。

套接字是操作系統抽象，用於鏈接傳輸數據的客戶端和服務器連接。 因此，網絡問題直接反映在每個套接字存儲的數據中。 例如，網絡擁塞可能導致響應速度變慢，並導致往返時間(RTT)增加。 也可能存在網路帶寬可用，但應用程式因請求過多而不堪重負，無法用足夠的數據填充緩衝區以充分利用可用帶寬，從而導致應用程式受限的異常。 通常，伺服器同時處理多個插槽，這會導致資源爭用，給CPU和記憶體等系統資源帶來壓力。

因此，大規模監控TCP套接字的性能可以提供對通信行爲(例如響應速度慢或連接斷開)的重要瞭解，並確定可以進行改進的情況。

現有工具

Linux中的“ss”實用程序是用於獲取套接字統計信息的常用工具。 與“netstat”類似，ss通過允許對套接字狀態，協議和地址進行篩選，提供了更快，更靈活的資訊獲取機制。 我們也開始了ss的插槽監控之旅。 雖然它是快速獲取套接字列表和相關度量標準的強大工具，但ss的主要挑戰是它可能消耗大量資源，尤其是在具有大量套接字的系統上使用時。 這會影響系統性能並減慢其他進程。 此外，由於密鑰值使用不一致，ss輸出並不適合解析，並且使從數千臺伺服器流化收集的數據的能力顯著復雜化。

我們使用ss的第一個套接字集合版本是在選定的高速緩存服務器上運行的bash腳本，我們將“ss–tcp–info”的輸出導出到文件中。 然後，此文件將被rsync到堡壘主機，python腳本將從中讀取，分析並將其插入ElasticSearch。 完成了工作，但遠遠沒有達到我們所需要的規模。 此工作的下一次迭代是使python腳本在高速暫存伺服器上執行，該腳本將從HTTP接口調用，並返回匯總的統計資訊以插入ElasticSearch群集。 此方法將分析瓶頸從中央後臺位置擴展到單個高速暫存伺服器，但導致在具有大量套接字的伺服器上使用大量記憶體。 最終，我們認識到需要輕型替代系統的ss部分。

我們對這一新工具的主要要求是，它應該是輕型的，並可擴展至我們的CDN伺服器擁有的大量套接字，並且能夠使用協議緩衝區等高效機制將數據流回。 MeasurementLab的TCP-INFO工具是Golang實施的一種很好的實用程序。 但是，它設計用於隨時間跟蹤相同的套接字。 鑑於我們的插座連接量很大，我們選擇了不跟蹤單個插座的設計選項。 相反，每個輪詢循環都是獨立的，提供開放套接字當前狀態的快照。 此處的主要目標是跟蹤系統的整體性能，而不是單個插槽。

xTCP

為了解決這些難題，我們引入了開放原始碼xTCP (提取，導出，Xray TCP)。 xTCP是Golang實用程序，用於大規模捕獲和流式傳輸套接字數據。 xTCP使用Netlink來捕獲套接字信息，將數據打包在protobuf中，然後通過UDP端口發送出去(最終發送到Kafka等)或寫入NSQ。

NetLink為用戶空間和內核空間之間的通信提供了通用接口。 套接字監控工具ss，tcp-info使用NetLink_iNet_DIAG (Netlink協議系列的一部分)將套接字信息從內核獲取到用戶空間(手冊頁中的說明：NetLink_iNet_DIAG是Linux 2.6.14中引入的，僅支持AF_iNet和AF_inet6套接字。在Linux 3.3中，它被重命名爲NetLink_sock_DIAF_UNIX套接字並擴展以支持)。

xTCP以高速率提取內核TCP iNet_DIAG數據並通過protobuf導出該數據。 在具有大約~120k套接字的計算機上，Netlink消息大約是~5 MB，但是ss的ASCII輸出大約是~60MB。 此外，默認情況下，ss從內核讀取的數據塊爲~3KB。 xTCP讀取32KB塊，從而最大程度地減少系統調用。 xTCP使用多個工作人員同時讀取Netlink套接字數據，以儘可能快地清空隊列，並同時分析Netlink消息以進行流傳輸。 所有這些優化都使xTCP的佔用空間更小，以便在生產高速緩存服務器上運行。

在Edgio使用

我們大量利用xTCP數據來分析客戶端性能。 我們通常跟蹤RTT並重新傳輸按入網點(POP)和ASN匯總的數據。