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