對于大多數(shù)人來說，“全棧”(Full Stack)的意思很好理解。但是如果我們的話題涉及到監(jiān)控容器環(huán)境呢?整個(gè)事情就會(huì)開始變得有些模糊了。在這篇文章中，筆者探索了在這樣的一個(gè)環(huán)境下，獲得全棧可見性的不同方面和可能會(huì)遇到的一些挑戰(zhàn)。

到底什么全棧？

“全棧工程師”這個(gè)術(shù)語在2010年初被提出，表示在整個(gè)應(yīng)用程序堆棧中具有廣泛技能的開發(fā)人員。包括前端和后端應(yīng)用程序組件的組合，甚至包括基礎(chǔ)設(shè)施層的代碼體現(xiàn)。使用許多不同的應(yīng)用程序組件或微服務(wù)的容器化應(yīng)用程序的趨勢，增加了現(xiàn)代應(yīng)用程序堆棧的復(fù)雜性。甚至有人批評(píng)了“全棧工程師”這個(gè)術(shù)語。

雖然對于一個(gè)人來說，了解應(yīng)用程序每個(gè)部分的開發(fā)細(xì)節(jié)可能是不現(xiàn)實(shí)的(除非非常簡單)，但是應(yīng)用程序在生產(chǎn)環(huán)境中運(yùn)行時(shí)，通常需要堆棧的所有層都具有可見性。這允許開發(fā)人員在應(yīng)用程序或基礎(chǔ)設(shè)施的適當(dāng)部分中快速識(shí)別問題并采取相應(yīng)的行動(dòng)。所以，在這篇文章中，我們回來探索一個(gè)容器化應(yīng)用程序的“全棧”可見性或監(jiān)視方式。例如，堆棧通常是什么樣子的?棧的不同層的相關(guān)度量是什么?收集和分析所有這些度量標(biāo)準(zhǔn)需要什么功能?

容器堆棧是什么樣的?

在筆者的演示中，經(jīng)常會(huì)使用下面的圖片來說明容器化應(yīng)用程序中最重要的層是什么，并討論傳統(tǒng)的單片應(yīng)用程序之間的一些重要區(qū)別。實(shí)際上，隨著容器的使用和一些編排平臺(tái)的使用，還引入了額外的抽象層?，F(xiàn)在，從所有這些層收集度量并將它們綁定在一起是非常重要的，能方便我們完全理解一個(gè)容器化的應(yīng)用程序是如何工作的。

　　需要收集哪些指標(biāo)?

根據(jù)上面的圖片，為了獲得我們的應(yīng)用程序的全?？梢娦裕覀冃枰獜南旅娴膶又惺占阅苤笜?biāo)：

·在基礎(chǔ)設(shè)施中，我們希望收集不同的資源指標(biāo)，比如CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等等，可能來自物理服務(wù)器或虛擬服務(wù)器，也可能是云實(shí)例。在后一種情況下，這些指標(biāo)通?？梢酝ㄟ^某種API(如Amazon Cloudwatch)來訪問，同樣包括我們在云平臺(tái)上使用的服務(wù)的其他指標(biāo)。

·通常，一個(gè)協(xié)調(diào)器用于幫助基礎(chǔ)設(shè)施上的容器的部署、擴(kuò)展和管理。Kubernetes(或者是Red Hat OpenShift之類的產(chǎn)品)和Docker Swarm是最受歡迎的技術(shù)。在這一層，我們希望了解容器計(jì)數(shù)和容器動(dòng)態(tài)，例如縮放事件。從協(xié)調(diào)器中，我們還可以收集關(guān)于容器如何與服務(wù)綁定的服務(wù)定義和關(guān)系。這允許我們在服務(wù)級(jí)別進(jìn)行報(bào)告，例如特定服務(wù)的容器數(shù)量或其他相關(guān)指標(biāo)。

·對于容器本身，我們還希望了解每個(gè)容器和每個(gè)服務(wù)的資源度量，以及容器生命周期事件。此外，我們希望了解容器內(nèi)的應(yīng)用程序是如何運(yùn)行的。這種所謂的容器監(jiān)控為我們提供了針對容器內(nèi)運(yùn)行的不同服務(wù)的應(yīng)用程序特定的度量標(biāo)準(zhǔn)。

·最后，我們希望看到對最終用戶的影響，并理解作為應(yīng)用程序的消費(fèi)者所獲得的性能。這通常包括頁面加載時(shí)間、錯(cuò)誤等前端指標(biāo)，有時(shí)甚至可以添加業(yè)務(wù)指標(biāo)來“監(jiān)視真正重要的事情”。

　　其他的考慮

從這些層收集不同的度量標(biāo)準(zhǔn)本身已經(jīng)是一個(gè)挑戰(zhàn)。大多數(shù)監(jiān)控工具只關(guān)注其中的一個(gè)子集，因?yàn)樗鼈兪菫閭鹘y(tǒng)的單片應(yīng)用程序開發(fā)的?，F(xiàn)代容器監(jiān)控工具應(yīng)該與上面提到的所有層進(jìn)行集成，以提供完整的圖像以及防止出現(xiàn)盲點(diǎn)。

但這并不僅僅局限于度量收集。還有一些其他重要的考慮事項(xiàng)，與度量指標(biāo)和事件的收集方式有關(guān)。

·自動(dòng)儀表:考慮到容器的短暫特性，新容器在啟動(dòng)時(shí)自動(dòng)監(jiān)控是至關(guān)重要的。這包括認(rèn)識(shí)到已經(jīng)啟動(dòng)了一個(gè)新的容器，以及在內(nèi)部運(yùn)行的服務(wù)，以及如何監(jiān)視這些服務(wù)。例如，在CoScale中，我們使用一個(gè)豐富的插件庫來監(jiān)控來自已知服務(wù)的應(yīng)用程序特定指標(biāo)，如NGINX、Redis、MongoDB和許多其他服務(wù)。

·另外，當(dāng)將新節(jié)點(diǎn)添加到集群時(shí)，重要的是這些節(jié)點(diǎn)配置，而且配置了正確的監(jiān)視代理和設(shè)置，這樣你的監(jiān)視就可以與環(huán)境進(jìn)行伸縮。這可以通過在Kubernetes中使用“DaemonSets”的概念或Docker Swarm的全球服務(wù)來完成。

·另一個(gè)主要的考慮因素是監(jiān)視代理運(yùn)行的位置和它們生成的開銷。這是特別相關(guān)的，因?yàn)槿萜魇禽p量級(jí)且不可變的結(jié)構(gòu)，應(yīng)該盡可能少地受到影響。一些監(jiān)控工具需要將代理添加到容器映像中，或者作為sidecar容器，這通常會(huì)增加大量的開銷。其他工具，例如CoScale，只需要每個(gè)節(jié)點(diǎn)上的一個(gè)代理(通常是運(yùn)行它自己的容器)，開銷增加最小。

·收集數(shù)據(jù)是一回事，但理解它則是另一回事。為了獲得正確的見解，需要對容器環(huán)境進(jìn)行正確的可視化。一個(gè)擠滿了所有容器的所有資源指標(biāo)的圖表的儀表盤，并不是很有洞察力。你通常希望從高層次的服務(wù)和集群的視圖開始，然后在出現(xiàn)問題時(shí)能夠進(jìn)行深入的研究。

·同時(shí)，對問題本身的檢測也具有挑戰(zhàn)性。容器和服務(wù)的數(shù)量以及它們生成的度量指標(biāo)的數(shù)量已經(jīng)導(dǎo)致了數(shù)據(jù)的泛濫。將其與容器的動(dòng)態(tài)方面相結(jié)合，你就可以明白為什么經(jīng)典的報(bào)警技術(shù)常常會(huì)失敗。因此，在這樣的環(huán)境中，更多的自我學(xué)習(xí)分析技術(shù)，例如動(dòng)態(tài)的基底和異常檢測，是非常有價(jià)值的，并且有助于對問題的主動(dòng)檢測。

·最后，在發(fā)現(xiàn)問題的同時(shí)，還應(yīng)該對它們進(jìn)行修復(fù)。為此，需要收集適當(dāng)數(shù)量的上下文信息來進(jìn)行故障排除。這包括在問題發(fā)生時(shí)發(fā)生的其他事件的相關(guān)性。是否所有的特定服務(wù)的容器都受到了影響，或者僅僅是一個(gè)?在哪里也有下游服務(wù)的問題?更詳細(xì)的日志數(shù)據(jù)或跟蹤信息可以幫助解決問題服務(wù)的故障。

結(jié)論

容器環(huán)境的完整堆棧監(jiān)控與單片應(yīng)用程序監(jiān)控是不同的。典型的監(jiān)控工具通常不能提供所有不同層次的正確見解，并且很難處理容器環(huán)境的規(guī)模和動(dòng)態(tài)。無論您計(jì)劃使用開源解決方案還是商業(yè)產(chǎn)品，上面的不同考慮都可以幫助您選擇正確的工具，以確保您的環(huán)境完全可見。