關于企業上云，在幾年前大家談論更多的是OpenStack、資源編排和分配，但近幾年上云的應用部署方式發生了很多變化。首先從谷歌搜索的趨勢可以發現Kubernetes的關注（熱度）已經遠遠超過了OpenStack，同樣在百度搜索趨勢中K8s和Kubernetes加起來是OpenStack的兩倍。
容器的特點是彈性伸縮，支撐彈性伸縮最主要的兩個特征分別是分布式和負載均衡。在這兩個特征支撐下，容器可以在業務壓力過大時做到彈性伸縮，業務以POD單位進行彈性擴充。
從可達性來看，任何兩個POD間都是可達的，而且外部也可以通過Ingress、LB的方式來訪問容器集群里面任意的POD，這帶來一個問題：服務之間的溝通變多了，東西向流量成為容器環境下的主體流量，而這個流量，傳統的流量采集方式無法全部覆蓋。
第一：因為傳統的流量采集方式是通過物理交換機的鏡像、分光等方式，在容器網絡環境下，容器間的通信可能在K8s的Node之內或者一個VM的Hypervisor就終結了，很難去到達物理的交換機層面。
第二：即使容器、POD之間的流量能到達物理交換機，隨著容器規模的擴張，要想做到全覆蓋，投入用于流量采集的成本會急劇增長。
容器的環境下有大量的LB，在提供負載均衡等復雜的場景下，SNAT和DNAT會多次發生，每一次發生地址轉換就意味著可能會產生網絡性能問題。
即使兩個POD之間是三層可達，但是這兩個POD的End to End的通信路徑上可能會跨越物理服務器的機架，導致可能會跨越接入交換機、物理網元；也可能會跨越兩個公有云的AZ、區域，或者不同的云，甚至是在私有云和公有云之間通信。所以任何兩個POD之間通過service的訪問都可能會有解析、DNS性能以及負載均衡的問題。
在傳統網絡環境，服務器和虛擬機的IP地址是很少發生變化的，對業務的梳理其實等同于對IP地址身份信息的梳理。由于容器用DNS解析IP，可能存在IP重疊、IP對應的資源身份在不斷地變化等，所以在容器環境，對IP身份的識別非常困難。
一般情況下，一個物理機上可以運行10個虛擬機，一個虛擬機上可以運行10個POD，因此容器網絡環境的IP數量就有100倍的增長。IP數量的巨增，意味著網絡監控的數據至少有100倍的增長。在監控計算、存儲資源時，基本上有多少臺機器得到的監控數據就是多少個。
但是對于網絡監控而言，極限情況下數據是N方的量級，因為網絡監控的本質是一個端到端的信息。極端情況下，容器里所有的POD都會產生通信，就相當于有N方的通信需要被監控，因此網絡規模非常巨大。
以上這些特點都會導致容器網絡監控的難度上升。
分布式系統可觀測性需要去集中解決3個類型的監控數據，即Metrics、Tracing和 Logging。分別代表Prometheus監控的指標數據，比如說CPU內存、流量大小等等；第二類Tracing數據，也可以說服務調用棧的數據；第三類是日志數據，比如ELK里的日志分析。二、三類數據關聯度會大一些，是每一個請求或每一條日志的數據。
Metrics通常是實現分布式系統可觀測性的第一步。它是一個可聚合、可設置報警，面向大規模監控數據做分析和告警判斷，針對Metrics通常會關注四個方面的指標量：
它刻畫的是當前的業務系統的訪問是否順暢、耗費的時間是否在增加。例如從四層網絡的角度看，有三次握手、協議棧響應的時延；從應用的角度看，有HTTP響應、DNS響應的時延。
系統的吞吐。例如一個應用系統的BPS、PPS是多少？新建連接數、新建連接速率是多少？HTTP的請求數是多少等等。
錯誤可能發生在網絡層，比如TCP建連失敗、重置、重傳等，還可能會發生在應用層，比如HTTP的400、500等錯誤，或者是DNS解析失敗。
一般來講是對計算和存儲資源的描繪，在虛擬網絡情況下也可以描述虛擬交換機的負載。網絡層面的負載主要體現在并發連接數、當前正在活躍的用戶數等指標。
對網絡的指標監控通常要考慮以上4個方面，這4個方面能夠覆蓋一個分布式系統所有的角落，最終實現分布式系統的可觀測。
以上可見一個企業需要實現全網流量采集的重要性。往簡單了說，在微服務場景下需要考慮服務和服務之間的調用關系，相當于調用棧的追蹤。其實服務和服務之間訪問，實際上就是POD和POD之間的訪問，意味著在網絡層面直接能看到它們互訪的流量，因此，通過網絡流量采集可以直接獲取到服務的調用棧。這更加可以說明：流量采集可以解決容器網絡可觀測性的難題。
那么為什么需要通過流量采集來解決這個問題呢？有兩個方面的原因。
第一個方面：從應用的層面無法解決問題。從日志或代碼插件很難去感知到網絡層面的問題。比如某個訪問消耗了500毫秒，在網絡層面是由于建連導致的時延問題？還是協議棧時延？其實在應用層并不清楚，只知道最終這個請求消耗了500毫秒。
第二個方面：網絡層的信息能提供更精確的數據。以Nginx日志為例，當一個請求所發送的數據已在內核緩沖區里，Nginx認為已經實現了請求的完整回復，而記錄了一個時延。但是如果能從網絡流量的角度去監測，會發現在實際的環境中對于這樣的場景會有3~10倍時延的誤差。這說明，從網絡層面去分析應用的質量、性能是必要的。
為了實現整個業務的監控，需要在容器網絡環境獲取到的數據，包括Service之間訪問的追蹤關系；負載均衡、Service前后IP的變化關系；真實源IP與SNAT和DNAT后的變化關系。
通過這些數據來刻畫監控數據的分布，以及監控數據和網絡邏輯拓撲的關聯，構建網絡知識圖譜，實現各個緯度的可視化；同時對歷史的交互數據進行回溯分析，在不同的維度（資源組維度、POD維度、服務維度）做層層的鉆取來最終定位業務的性能問題，并進行證據的留存。目前國內已有不少企業通過自己的產品賦能容器網絡性能監控，例如云杉網絡DeepFlow虛擬網絡流量采集、可視化與監控平臺，基于高效的混合云流量全網采集和時序數據存儲、檢索技術，提供混合云網絡流量采集與分發和性能監控診斷解決方案。
