NetNORAD：通過端到端探測對網路進行故障排除

Facebook的服務由其龐大的底層網路基礎設施提供支援。保持此網路正常執行是基礎架構團隊的首要任務之一。我們的規模意味著裝置故障可以並且確實每天都在發生，我們努力防止這些不可避免的事件影響使用我們服務的任何人。最終目標是自動檢測網路中斷在幾秒鐘內緩解它們。相比之下，人為驅動的調查可能需要幾分鐘，如果不是幾小時。其中一些問題可以使用傳統的網路監控來檢測，通常是通過SNMP查詢裝置計數器或通過裝置CLI檢索資訊。通常，這需要大約幾分鐘的時間來產生穩健的訊號並通知操作員或觸發自動補救響應。此外，在我們的實踐中，我們經常遇到稱為灰色故障的情況，其中傳統指標無法檢測到問題，或者裝置無法正確報告其自身的故障。所有這些考慮因素激勵我們構建NetNORAD--一個將網路視為“黑匣子”並對網路問題進行故障排除的系統獨立於裝置輪詢。

測量損失率和延遲

從應用程式的角度來看，網路有兩個主要特徵：丟包率和延遲。這兩者的變化會影響傳輸協議的行為，例如TCP。為了衡量這兩個指標，我們讓Facebook的伺服器相互ping通，收集丟包統計資料和RTT，然後根據這些資訊推斷網路故障。該系統中的兩個關鍵元件是在我們的伺服器上執行的pinger和responder程式。該ping傳送UDP探測包來響應，後者接收，時間戳，併發回探頭。該過程以輪次進行，其中每個pinger將資料包傳送到其所有目標，收集響應，然後重複該過程。我們執行多個ping過程，每個過程用於標記網路中不同QoS類的每個不同DSCP值。

您可能會問為什麼我們會選擇UDP進行網路探測。實際上，我們的絕大多數流量都是通過TCP傳送的，但是當我們開始使用無狀態TCP探測（SYN-RST）時，我們注意到從目標機器請求TCP RST會產生太多噪音並混淆應用程式監視系統。從作業系統的角度來看，使用TCP進行狀態探測（SYN-SYN / ACK）是資源密集型的，特別是考慮到確保覆蓋所需的探測數量。我們還排除了ICMP，因為ECMP場景中可能存在極化問題（缺乏熵）。

我們的經驗是，在絕大多數情況下，UDP和TCP在網路中共享相同的轉發行為。同時，UDP更簡單，允許直接測量底層資料包丟失和網路延遲。UDP的使用還允許在探針中嵌入自定義資訊，例如多個時間戳，以準確地測量RTT。對於後者，我們使用核心時間戳，允許我們補償由Linux核心中的緩衝引起的延遲，這是端到端探測技術的常見問題。

部署系統

Facebook的網路是分層次結構的。在最低階別，伺服器安裝在機架中，這些伺服器以群集形式組織。整合在同一建築物中並由公共網路服務的叢集形成資料中心（DC）。反過來，資料中心通過網路進行聚合，該網路將它們在同一區域內互連並連線到Facebook全球骨幹網路。Facebook的基礎設施遍佈全球多個地區。

我們在每個叢集中部署了少量pinger，但我們在所有計算機上執行響應程式。使用較少數量的pinger是有意識的選擇，以減少我們通過探測這麼多目標所獲得的資料量。所有pinger共享一個全域性目標列表，其中包含每個機架中至少兩臺計算機。pinger可以非常快速地傳送資料包，最高可達1 Mpps，總的探測速率大約為數百Gbps。

分層結構還允許我們簡化一些資料聚合技術。當pinger在給定的ping輪次中收到響應時，它會聚合屬於同一群集的計算機的結果，並根據其與目標群集的接近程度對其進行標記。例如，對於具有1,000個目標的群集X，pinger會將這些主機上的所有丟失統計資訊彙總為幾個值：平均丟包率，損失差異以及返回的所有響應中的RTT百分位數。然後它使用鄰近標記標記結果，具體為：

資料處理

結果帶有時間戳並寫入Scribe，這是一個分散式實時日誌記錄系統，最終將其傳送到Scuba，這是一個用於資料分析和視覺化的分散式記憶體儲存。Scribe允許多個讀者（也稱為零售商）以釋出者/訂閱者的方式使用資訊，而Scuba只是其中之一。

我們執行專用的報警流程，該流程使用Scribe的實時資料並跟蹤每個群集/鄰近標記組合的丟包時間序列。對於每個群集/鄰近對，該過程通過對來自所有pinger的結果求和來跟蹤資料包丟失的演變方式。例如，對於叢集X，我們將有三個時間序列反映來自不同視點的叢集丟包：DC，Region和Global。這些來自所有認為自己分別位於相同資料中心，相同區域和區域外的pingers相對於探測叢集。

對於每個時間序列，我們以10分鐘為間隔跟蹤百分位數。跟蹤多個百分位數使我們能夠識別網路上事件的性質。例如，第50百分位數的資料包丟失峰值意味著可能存在影響進出群集的大部分流量的故障，而第90百分位數的大資料包丟失值會告訴我們存在高水平的損失影響少數目標。對於每個百分位數和接近標記組合，我們設定上升和下降閾值以觸發和清除相應的警報。

設計此管道的一個重要因素是檢測有效網路故障的響應時間。Scribe寫入/讀取延遲通常為秒級，通過時間序列跟蹤，我們通常會在20-30秒內看到警報。這個數字對於系統在生產中的成功至關重要，在事件發生時會發出警報。較大的延遲會使NetNORAD成為歷史損失跟蹤的良好工具，但會降低其作為前線警報系統的影響。

故障隔離

不容易判斷資料包丟失是由終端主機故障還是真正的網路問題引起的，因為這些與端到端探測的角度無法區分。為了避免因重啟伺服器而導致的大量誤報，pinger實現異常檢測邏輯，幫助找到報告資料包丟失的目標，相對於一般人群來說，資料量過高; 來自這些目標的資料不包括在報告中。排程程式程式僅從已知的健康機器集中選擇目標，例如，未釋出已知會影響機器連線性的警報的機器，這一技術得到了補充。

類似的異常檢測邏輯適用於過濾壞的 pingers：在可能存在連線問題的機器上執行的程式。警報過程會跟蹤每個針對具有相同接近標記的所有群集報告的丟失，並且如果報告相對於其對等點的丟失過高則標記針對該針腳的丟失。然後忽略來自壞針的樣品，直到它再次穩定。

使用鄰近標記，我們可以通過執行警報關聯分析來執行基本形式的故障隔離。我們遵循兩個基本原則：

通過將這些規則應用於警報，我們可以減少它們的數量並估計故障的位置。這不會，也不能確定確切的故障位置。就像常見的網路故障排除過程一樣，為了本地化故障，我們需要執行一個額外的工具，我們稱之為fbtracert。與流行的UNIX工具traceroute類似，fbtracert並行探索網路中兩個端點之間的多條路徑。此外，它還可以分析每一跳的資料包丟失情況，並將得到的路徑資料關聯起來，找出常見的故障點。

在許多情況下，特殊和有效，fbtracert並不普遍。它受到網路裝置中控制平面監管和處理traceroute探測資料包的各種錯誤的限制 - 例如，使用錯誤的源IP地址進行響應。在底層轉發路徑頻繁變化的情況下，它也不能有效地工作，因為它需要每個路徑的穩定統計，這在一些骨幹網路中就是這種情況。

在fbtracert無法找到故障的情況下，我們依賴於積極的人為參與，這通常始於挖掘我們儲存在Scuba中的端到端資料包丟失資料，並使用資料過濾和對各種金鑰進行分組（例如，ping源/目標，協議，QoS標記）。因此，我們將繼續致力於探索新的故障隔離方法，以使其更加健壯並適用於更多情況。

開源NetNORAD

我們正在開源NetNORAD系統的一些關鍵元件，以推廣端到端故障檢測的概念，並幫助世界各地的網路工程師運營其網路。第一個元件是pinger和響應器（用C ++編寫）和fbtracert實用程式（用Go編寫）。雖然這不構成完整的故障檢測系統，但我們希望您可以使用這些元件作為起點，使用您自己的程式碼和其他開源產品進行資料分析。

感謝網路基礎設施工程和網路系統團隊使NetNORAD成為現實。