之前的文章中，我們提到了一種基於BGPStream的分佈式體系結構，並利用Apache Kafka（分佈式消息系統）來執行連續的全局BGP監控。我們的目標是雙重的：我們演示了BGPStream如何啟用和簡化開發複雜的全球監測基礎設施；並且針對出現的挑戰，我們在下文中提出了有效的解決方案。
為了構建開發這種複雜體系結構的背景和動機，讓我們考慮兩個示例應用程序，即“互聯網中斷：檢測和分析”（IODA）和“劫持”（Hijack）研究項目。在IODA中，我們24/7全天候監視互聯網來檢測和描述宏觀連通中斷現象。對於BGP，我們的目標是瞭解一組前綴（例如，共享同一地理區域或同一起源AS）是否可全局訪問。來自單個探測源的信息不足以驗證中斷的發生，事實上，由於本地路由失敗，探測源可能無法訪問前綴。另一方面，如果拓撲上和地理上分散的幾個探測源同時丟失了部分前綴，那麼這些前綴本身可能正在經歷中斷。在劫持中，我們感興趣的是檢測和分析基於BGP的流量劫持。由於大多數常見的劫持表現為兩個或更多個AS同時宣佈完全相同的前綴或相同地址空間的一部分，因此檢測它們需要比較從多個探測源觀察到的前綴可達性信息。
為了及時檢測這些事件，我們需要保持一個全局的（如，針對每個VP）視圖，並且擁有更新精細時間粒度（例如，幾分鐘）的更新BGP可達性信息。這種不斷更新的全局視圖可以在許多其他應用中使用，例如跟蹤包含特定AS的AS路徑、驗證路徑洩漏的發生、發現AS級拓撲圖中出現的新的(可疑的)AS鏈路等。
圖1 實時監控分佈式架構
在圖1中描繪了我們建議的體系結構：多個BGPCorsaro進程數據（每個進程收集器一個實例，以便跨多個CPU/主機分佈計算），它們的輸出被存儲在Apache Kafka集群中，並由應用程序（消費者）進一步處理由同步服務器生成的元數據。在下面的小節中，我們描述這個體系結構的主要組件以及它們所解決的挑戰：首先，我們解釋瞭如何高效且準確地重構每個探測源的可觀察的LocRIB；然後說明了如何減少我們存儲的數據量，以及稍後對消費者的處理；第其次展示瞭如何根據應用程序需求來支持不同同步機制的問題；最後我們提供了作為消費者實現的應用程序的示例。
重新構建探測源的路由表
RIB類型的dump文件通常每2或8小時可用一次。我們的目標是以1或幾分鐘的粒度重構每個探測源的可觀察的LocRIB（這裡稱為路由表）的快照。為此，我們開發了一個BGPCorsaro插件，稱為路由表（RT）。RT插件使用RIB類型的dump文件作為起始引用，然後依靠Updates類型的文件來重構路由表的演進，使用後續的RIB類型的dump文件進行健全性檢查和校正。然而，由於這是一個基於異構測量數據的分佈式收集的推理過程，因此可能出現許多問題：BGP會話失敗、數據損壞、dump文件發佈無序等等。我們通過維護有限狀態機和數據結構來解決這個問題。綜合考慮探測源的狀態，其路由表和我們認為數據正確的信息度來建模。特別是，我們處理以下四個特殊事件：E1。如果libBGPStream標記其至少一個記錄被損壞，則忽略該RIB類型dump文件中的所有記錄。E2。由於來自單個RIB類型dump文件的記錄常常跨越幾分鐘的時間戳，並且RIB和Update類型dump文件可能被無序地發佈，因此插件可以接收一些老的RIB類型的dump文件記錄，這些記錄比插件應用的最新更新記錄要老。為了解決這個問題，我們檢查RIB類型的dump文件的每個單獨記錄，並且僅當記錄的時間戳比插件已經應用的信息的時間戳更近時才使用這些記錄的信息。E3。在接收到損壞的更新類型dump文件記錄時，我們停止應用更新並等待下一個RIB類型dump文件。E4。我們在接收到某些探測源狀態消息時強制進行狀態轉換（例如，使用已建立的代碼接收到狀態消息觸發到激活UP狀態的轉換）。
圖2 有限狀態機
我們將狀態和路由表信息保存在多維哈希表中，該哈希表可以看作是一個前綴（prefix）作為行和探測源作為列的矩陣。每個單元格包含前綴（例如，AS路徑）的可達性屬性、單元格上次被Updates類型dump記錄修改的時間戳、以及指示這種操作是通知還是撤回的A/W標誌。此外，對於每個單元格，RT插件使用影子單元格臨時存儲來自新RIB類型dump的記錄，直到它接收到其最後一條記錄：如果沒有RIB類型dump記錄損壞（E1），我們將用影子單元的內容替換主單元的內容，除非RIB類型dump記錄比主單元的最後修改時間（E2）要大。
圖2描述了將一個探測源的路由表維護成有限狀態機的過程，該有限狀態機對探測源的狀態進行建模。當插件啟動時，探測源的路由表不可用，探測源處於Down狀態（1）。當新的RIB類型的dump開始時，探測源的狀態移動到Down RIB Application狀態。在這個階段，插件使用從RIB類型dump記錄接收的信息填充陰影單元格，並使用Updates類型dump記錄填充主單元。一旦接收到整個RIB類型dump記錄，探測源的狀態就變成(3)；當在這種狀態下，路由表被確定探測源路由表的準確表示。每個新的通知或撤回記錄觸發主單元的修改，而如果新的RIB類型dump開始，則探測源的狀態轉換到UP RIB Application狀態(4)，類似於(3)的狀態，但是RIB類型dump記錄修改單元的影子信息。一旦RIB類型dump結束，陰影和主單元合併（如前所述），並且探測源再次轉換到狀態（3）。此外，一個損壞的更新轉儲記錄迫使狀態改為Down狀態（E3）。接收到攜帶有已建立代碼[52]的狀態消息的Updates類型dump記錄將探測源的狀態移動到UP狀態(E4)，而接收到任何其他狀態消息指示探測源和收集器之間的連接未建立，因此，探測源被認為是DOWN狀態 (E4）。
為了評估我們的方法的準確性，我們週期性地比較當前和陰影小區中的信息。RIS和RouteViews的錯誤概率（定義為所有探測源的所有前綴中不匹配前綴的數量）在31個收集器上經過12個月計算後分別是10.8和10.5。我們發現，不匹配通常由沒有狀態消息的無響應探測源（例如，RouteViews）或收集器在啟動RIB類型dump之前沒有應用所有傳入的更新消息（但是之後應用它們，即使它們已經被分配了時間戳）引起。
運行時的IO情況：差異, (非)序列化, Kafka
在每個時間倉的末尾，RT插件將每個探測源的重構路由表發送到Kafka集群。然而，為了減少要由使用者存儲和稍後處理的數據量，我們開發了允許RT插件計算在前一時間段生成的路由表與當前時間段生成的路由表之間的差異，並且只傳輸改變的部分（我們稱呼為差異元素）。消費者使用互補例程從Kafka檢索數據，並通過對先前存儲的版本應用差異來重構完整的路由表。產生的數據結構標記路由表的更新部分，允許使用者分析這些數據。我們還定期（例如，1小時）在Kafka集群中存儲整個（非差異）路由表，應用程序可以使用這些表進行同步，以便接收將來的差異數據。
圖3突出了只處理路由表之間的差異而不是處理每個更新消息的優點（就處理的BGP元素數量而言）。我們在2016年3月份的來自route-views2的數據上運行RT插件：在圖表中，紅色圓圈顯示從每個時間段內的BGP更新消息中提取的BGP元素的平均（底部）和最大（頂部）數量，而藍色方塊顯示連續路由表之間的差異元素數量。當時間倉為1分鐘時，僅存儲差異數據比全部存儲的BGP元素數量平均少3倍，這表明即使在如此短的時間尺度上更新消息也存在冗餘。隨著時間倉的大小增加，減少因子也增加，但以時間粒度為代價；1小時的時間倉產生的差異單元比BGP單元少13倍。此外，最大值表明，通過處理差異，消費者對突發更新（例如，由於前綴翻轉）更有彈性。
圖3 存儲差異 VS 全部存儲
數據同步
不同的收集器、不同的數據源提供數據具有不同延遲。執行數據同步需要在延遲、處理時可用的數據量和內存佔用之間進行權衡。這種權衡的最佳點取決於具體的應用目標和要求。而不管延遲如何，監視應用程序可能需要當前時間段的所有可用源（或給定部分）的數據。其它應用程序可能具有嚴格的實時要求，並且喜歡顯式設置超時。例如：在劫持的實時檢測中，一旦檢測到可疑的BGP事件，我們就設置幾分鐘的超時以執行traceroute；相反，在IODA應用程序中，我們放鬆延遲約束，以利於數據完整性，並使用30分鐘的超時，因為它的結果是確保所有探測源的多個RT路由表在99%的時間段內可使用（在2014和2015年已經有確鑿的數據可以驗證它）。
我們設計了一個基於存儲在Kafka中的元數據和多個同步服務器的系統，每個同步服務器實現不同的同步機制：每個BGP Corsaro RT插件在Kafka隊列中寫入路由表，索引元數據；這些元數據由同步服務器監控。同步服務器負責基於它們實現的同步標準，將元數據注入Kafka隊列中它們自己的主題中，以將數據標記為準備使用。通過使用Kafka，所得到的系統是水平可伸縮的（因為Kafka支持跨多個節點分佈數據）和健壯的（例如，由於數據複製）。此外，由於同步服務器只處理具有小內存佔用的輕量級元數據，因此不會影響可伸縮性。
消費者
消費者實現分析從Kafka檢索的路由表，並執行事件檢測、提取統計信息作為時間序列輸出。我們開發了兩個消費者用於每個國家和每個AS的近實時中斷檢測。兩個消費者都選擇由全饋送VP觀察的前綴，並通過計算位於每個國家並且由每個AS宣佈的前綴的數量來監視這些前綴的可見性。消費者將這些數據存儲到支持自動變化點檢測和數據可視化的時間序列監控系統中。
圖4 可見的伊拉克IP前綴（2015年6月20號-7月20號）
圖4顯示了在一個月期間（2015年6月20日至7月20日）每個國家和每個AS的中斷數據，選擇與伊拉克有關的可見前綴和伊拉克5個最大的ISP。這些明顯的下降反映了在政府進行部長級預備考試時在全國範圍內發生的一系列互聯網中斷。
