Roblox Cloud 上的網路封包遺失率與延遲監控

Roblox 網路工程團隊負責維護一個規模龐大且快速成長的網路，其資料中心與網路節點 (POP) 遍布全球。Roblox 平台能否提供卓越的使用者體驗，取決於此網路的效能與可靠性。網路營運人員必須能夠對網路問題進行故障排除與偵測，並掌握網路效能的狀況，這點至關重要。 網路監控通常是透過定期收集裝置統計資料、錯誤指標和系統日誌，並將其儲存於時間序列或日誌資料庫中來實現。資料收集採用推送或拉取模式，並使用 SNMP、Netconf、Rest API 或 Streaming Telemetry 等標準協定。

僅透過裝置遙測進行網路故障偵測存在若干缺點，因為這是一種被動式監控技術。它取決於網路節點能否在異常情況發生時立即識別並回報。裝置未必總是會回報資料，或在某些情況下，其所有健康狀態統計資料可能無法透過常規的遙測收集方法獲取。此外，網路裝置有時可能會提供錯誤資料，或默默地將流量黑洞化。 裝置遙測的一大限制在於，它幾乎無法提供網路端到端可達性、封包丟失率及延遲統計數據的相關資訊。

如以下圖所示，透過定期在網格中傳輸合成探測訊號，是主動監控網路的一種絕佳方式。

在排除生產環境中斷問題時，網路運維人員經常會被問到諸如「網路是否正在丟包？」或「是否有持續的網路故障影響服務連通性？」這類問題。若要回答這類問題卻無法取得歷史封包遺失率與延遲數據，他們就必須調查網路內的大量鏈路與節點。

設計可靠且可擴展的網格監控系統

要讓黑盒式網路監控系統能有效偵測封包遺失或延遲驟升，必須持續對網路各部分進行探測。資料中心網路會利用節點間的所有鏈路傳輸使用者流量。生產環境的網路設備會運行 BGP，並透過多條等成本路徑進行流量負載平衡。在正常情況下，網路拓撲的變更通常會在幾秒內透過路由表更新反映出來。 為了精確測量網路封包遺失率，測試探針應盡可能穿越涵蓋所有網路節點與鏈路的路徑。對於像我們這樣橫跨全球多個站點的大型網路，若要對每對節點或機架之間進行探測，並不可行。我們選擇的解決方案既能維持可視性水準，又更具永續性：在每個站點內對機架間進行 N² 網格探測，同時對所有站點之間進行另一個 N² 網格探測。

我們使用什麼來探測網路？

測試探針應模擬實際通過生產網路的流量。我們網路上的流量大多為 TCP、UDP 或 HTTP，這些協定皆可作為探針使用。TCP 探測的一大問題在於其運作負擔過重，難以擴展至監控大型網路所需的連接數。 TCP 的另一項限制在於，其內建的流量控制與滑動視窗傳輸機制，會導致探測傳輸速率不穩定，這對於量化或偵測瞬間封包遺失並不理想。ICMP（即 ping 和 traceroute 所使用的協定）通常在伺服器或網路節點上受到速率限制，這會限制可用 ICMP 探測的總量。 HTTP 請求位於更高層的應用層，且取決於網路外的某些因素，例如伺服器或應用程式的效能。HTTP 為結果增添了額外的變數因素，難以加以分離。本系統的目標是監控主要運作於 OSI 第 4 層及以下層級的底層網路基礎架構效能。基於這些原因，加上 UDP 是我們網路上的主要傳輸層協定，我們選擇了 UDP 探測。

探測來源為何？

要同時實現高總體探測速率並涵蓋大量網路路徑，一種方法是盡可能利用更多運算節點來傳輸探測封包。此舉有兩大優勢：既有助於分散產生探測封包之系統的負載，又能增加傳輸探測封包的網路埠數量。然而，這需要一個非常穩定且對主機系統資源佔用極低的代理程式。 同時，代理程式應能精確測量多條路徑上的封包遺失率與延遲，且不受主機系統 CPU、記憶體或 I/O 使用率波動的影響。代理程式必須持續在輕量級與高效能之間維持這種微妙的平衡。

我們如何測量網路丟包率與延遲？

這看似是針對單一探測流的簡單計算，然而在規模擴展時會產生一些乍看之下不顯眼的挑戰。為了擴展至如此龐大的網狀網路，代理程式需要同時針對眾多流，快速且精確地計算帶有時間戳記的發送（Tx）與接收（Rx）封包數量。 關鍵在於，網路丟包指標不應包含因代理程式所在主機的 CPU 繁忙或網路緩衝區溢出而丟失的封包。網路延遲的計算應以探針在傳輸線或中間網路節點上的總時間為基準，同時排除在 I/O 緩衝區等待以及代理程式進程等待作業系統排程的時間。

Roblox 的 Ping Mesh 系統

自從公有雲與私有雲基礎設施蓬勃發展以來，對「黑盒」式網路丟包與延遲監控的需求便一直存在。然而，要找到能擴展至我們大型網路的現成解決方案，實屬不易。多家大型雲端營運商與網路工具供應商，皆已設計出專屬的解決方案來監控網路丟包與延遲。 我們曾嘗試使用一些公開可用的工具，但在穩定性和可擴展性方面遇到問題，且對網路效能的洞察力有限。這促使我們建立自己的網狀監控系統，該系統能在低開銷的情況下，更有效地偵測低頻率錯誤。我們系統的亮點包括：

• 我們選擇使用 Go 語言來實作系統的所有組件，這有助於在消耗極少系統資源的同時，實現高水準的效能。
• 我們的代理程式穩定性極高，可運行於各類生產環境主機上，包括在 Roblox 平台上執行關鍵服務的主機，例如流量處理、快取及應用伺服器。
• 代理程式經過優化，透過 Go 封裝函式對 Linux 的 sendmmsg() 和 recvmmsg() 系統呼叫進行封包 I/O 操作批次處理，使其能夠以低開銷傳輸高頻率的探測封包。我們部署中的每個代理程式會同時向多達 100 台其他主機傳送探測封包，速率為每秒 100 個封包 (PPS)。代理程式每秒會向每個目的地傳送封包突發。
• 探測封包在 IP 標頭中攜帶不同的服務類型 (TOS) 欄位值發送至各目的地，並針對網路上的封包遺失與延遲分別進行統計。每個封包突發包均包含發送至其他所有目的地的多種 TOS 值組合。這有助於監控不同服務品質 (QoS) 類別的網路效能。
• 代理程式可在每個探測路徑上偵測到低至每分鐘每 6000 個封包中僅有 1 個封包遺失的情況。即使發生於網路核心或邊緣、持續時間少於 1 秒的封包遺失也能被偵測到，例如 BGP 波動期間的情況。
• 當網路設備介面錯誤導致封包遺失時，探測封包遺失圖表會呈現與該設備介面錯誤率相似的趨勢。我們已成功發現網路中難以偵測的流量黑洞（black-holing）錯誤。
• 代理程式利用 NIC 核心讀取時間戳記，以實現高精度的網路延遲測量。在排除主機作業系統排程延遲與網路時鐘漂移的情況下，可測量出 50–100 微秒的穩定站內往返延遲。
• CPU 使用率與記憶體佔用率極低。代理程式在傳輸與接收峰值速率（各 5 kpps）下，單核心使用率低於 25%。多數已部署的代理程式僅佔用約 5% 的核心資源。管理代理程式的傳輸與接收封包緩衝區及計數器僅需 10MB 的堆疊記憶體。當網路規模擴大時，我們可透過調整限制值或新增代理程式來進行垂直或水平擴展。
• 即使主機系統處於高負載狀態，代理程式也極少受到影響。我們曾多次在主機 CPU 負載接近 99% 的情況下，仍能獲得準確的結果。
• 我們會從每個代理程式收集遙測資料以監控其運作狀態。代理程式能識別各種異常狀況，例如主機系統重新開機、代理程式程序重新啟動，或是因套接字緩衝區溢出導致封包遺失等情況。

代理程式透過 Chef 部署於廣泛的伺服器叢集上，以維持大量節點參與網路探測。代理程式二進位檔在 Linux 系統上透過 systemd 執行與管理，確保在主機重新開機或代理程式升級後能自動重新啟動。當任一代理程式離線或有新代理程式上線時，網格排程器會根據需求動態偵測並調整資料流。 我們的排程器應用程式會定期輪詢裝置清單與服務發現系統，以偵測新代理程式及伺服器健康狀態，進而為 Pod 內、站點內及站點間的探測分配目標。 我們使用訊息總線將目標主機清單傳送給每個負責傳輸測試探測的代理程式。起始或終止於特定機架的個別資料流，會分配給該機架內所有可用的代理程式。這有助於我們在網路架構中測試大量等成本路徑，如下圖所示。

我們在首次部署時僅有 150 個代理程式，如今已成功擴展至 10 倍規模。此網狀網路覆蓋了我們的骨幹網路，串聯了遍佈全球的 25 個據點。 在其中一個主要資料中心站點，我們建置了涵蓋 200 多個機櫃的站內網格，約有 33,000 個資料流匯總為 1.65 Mpps 的探測率。每個機櫃會接收來自其他機櫃的 5–10 kpps 探測資料。排程器應用程式會計算並將超過 35,000 個目標均勻分配給不同站點的所有代理程式。

資料收集與視覺化

我們運行一個獨立的收集器應用程式，定期輪詢所有 Ping Mesh 代理程式以獲取封包遺失與延遲結果。系統會根據收集器本地快取的健康狀態，自動過濾這些資料以排除無效結果。例如，我們會排除來自未回應健康檢查的伺服器，或剛重新開機的伺服器上代理程式所傳回的結果。 我們的收集器能夠同步輪詢並過濾來自超過 1,500 個節點的結果，並在 2 秒內將資料導入時間序列資料庫。

無論是彙總結果還是各流的結果，皆透過 Grafana 儀表板進行視覺化呈現。當資料集龐大時，熱力圖網格往往難以操作，特別是針對我們的大型資料中心站點。我們運用 Prometheus 的 topk() 查詢，從數千筆結果中篩選出個體封包丟失率最高的路徑，通常僅有寥寥數筆。 這些結果會與收集器頻繁擷取的代理程式及主機系統健康狀態統計資料進行全面比對。這使我們能對每個個別結果抱持高度信心，無論封包遺失的波動幅度有多大。綜合檢視這些個別結果，可為我們提供網路故障發生位置的線索。以下展示了一些由我們的網狀監控系統偵測到的封包遺失案例。

摘要與後續步驟

我們的 Ping Mesh 系統一直是網路工程團隊監控端到端封包遺失與延遲的強大工具。這些資料可立即回答「網路是否正在丟失封包？」這個問題。根據我們的經驗，對客戶造成重大影響的網路事件通常會由裝置遙測監控系統偵測並發出警示。 至於影響較小但潛在問題的網路緩衝或孤立流量黑洞現象，則透過本系統得以揭露。

我們的系統還能提供關於 Roblox 雲端網路整體可靠性的洞察。在我們其中一個主要資料中心據點，每分鐘有超過 1 億次探測在監控網路健康狀況，且每分鐘的封包遺失數極少超過 50 次。這顯示出我們資料中心網路的可靠性約達 6 個 9（99.9999%）。 在數億個封包中，經常完全不會出現任何封包遺失。當發生大量封包遺失時，此系統能精確指出封包遺失的位置及持續時間。自動修復引擎會透過將用戶流量導向網路中的其他路徑，使網路自我修復，並防止用戶流量遭遇進一步的封包遺失。Roblox 的網路團隊已建構出極其可靠的雲端網路。

未來，我們計劃運用分析引擎，將裝置遙測資料、系統日誌及其他資料集進行關聯分析。接著，我們將把這些結果與 Ping Mesh 資料進行比對，以協助鎖定網路故障的發生位置。隨著 Roblox 的雲端網路持續擴展與演進，我們計劃強化探測機制，納入 IPv6 和巨型幀（jumbo frames），同時增加更多代理程式以提升站點間的覆蓋率。