為拯救網工們的頭髮，祭出了個大殺器 —— 基於意圖的主動運維繫統，並小試牛刀，輕鬆解決了網工們頭疼的 “ 幽靈丟包 ” 問題。具體來講，這個架構長得這個樣子：
左半部分下方是由自動化引擎構成的自動化層，它依據一定策略從復雜的多雲基礎架構中收集足夠的現場數據供給它的上一層—— 由洞見引擎構成的洞見層，後者對數據進行處理、分析和判斷，輔助人類做出正確的決策（ 我們稱為“ 意圖” ）。這些意圖可能是對數據收集策略的調整，也可能是直接實現某個主動運維的目標，總之在形成後都會被發送給下面的自動化層，它們被轉換為具體的執行策略，由自動化引擎驅動執行，並同時繼續收集數據反饋給洞見層完成狀態監控，從而最終形成一個不斷自我優化的閉環。 “ 幽靈丟包” 問題就是通過自動化層的AppDynamics Agent 探針收集了大量數據，在洞見層的洞見引擎AppDynamics 對這些數據分析出應用結構和結構內每一層應用體驗的定量化指標，最終找到導致端到端體驗惡化的精確位置（ 即“ 診斷意圖” ），再交給自動化層的自動化引擎ACI APIC 控制器進行底層精細化監測和診斷，從而最終抓獲幽靈丟包元兇。
其實我們看到這個例子中ACI APIC 的故障診斷工具箱內還是傳統的端口計數、差錯統計、Traceroute 等，但有了洞見層明確的診斷意圖加持，立刻功力倍增，瞬間搞定了傳統要幾天才能解決的難題。如果能把自動化層收集數據的手段進一步升級，比如引入大數據收集手段；把洞見層處理和分析數據的手段升級為大數據分佈式處理、機器學習和人工智能，那會是一幅什麼圖景呢？不用憑空想像，因為這就是 Cisco 智能主動運維繫統 Nexus Insights 。
我們就從 Nexus Insights 的自動化層如何實現大數據收集策略開始。
自動化層為什麼要加持大數據呢？我們常常把網絡流量比喻為道路交通（ 在英語裡甚至是同一個詞 Traffic ），那發現網絡異常就相當於交警檢查交通違章。傳統收集數據的手段往往是一個收集器輪流採集網絡節點數據，或者發出探測包沿線探測（ 比如ping、traceroute 等），這就好比交警輪流到路口檢查闖紅燈和超速，或者騎著摩託在路上巡邏，撞見了就抓、撞不見也沒什麼辦法。在網絡世界中也一樣，在收集器輪詢的空隙、探測包之間的間隔以及探測包沒能覆蓋的路徑上，到處都有可能存在導致用戶體驗惡化的瞬斷、丟包，突發擁塞、延遲和抖動，也就像沒能親臨現場的警察漏掉交通違章一樣被收集器漏掉了。這種由收集器方發起的數據收集模式被稱為 “ 拉取 ”（ Pull ）。
更高效的數據收集方式一定是 “ 推送 ”（ Push ）而非 “ 拉取 ”（ Pull ）。想像一下不靠交警親臨，而是所有車輛和路口都設置攝像頭，並實時主動對外報告交通狀態會是一種什麼場面？必然是任何違章都逃不過法眼。所以必須要想辦法讓每一個用戶數據包（ 車輛攝像頭）、每一個網絡交換機（ 路口攝像頭）都向外報告，這種利用帶內數據包和帶內網絡設備主動推送（ Push ）的數據收集手段，又稱為帶內網絡遙測（ In-band Network Telemetry，INT ）。當然代價就是數據量相當大（ 所謂 “ 大數據 ” ），但我們因此獲得的是全時全場景信息，能為洞見層提供全真的場景重現。
雲基礎架構單端口已經演進到了 400G ，要想不影響業務數據流而又逐包的實現全場景重現，就必須依靠設備的硬件轉發芯片。也就是說，無論廠商宣傳的軟件網管平台多麼酷炫，它的交換機的硬件決定了這個舞台的天花板。因此著名的交換機、路由器和 NIC 硬件開源標準組織 P4（ p4.org ）對數據平面 INT 做了功能定義和分類：
INT eMbed instruct(X)ions（ INT MX ）
INT eMbed Data（ INT MD ）
INT eXport Data（ INT XD ）
