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

[[198223]]

到底什么全棧?

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

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

容器堆棧是什么樣的?

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

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

根據(jù)上面的圖片，為了獲得我們的應(yīng)用程序的全棧可見性，我們需要從下面的層中收集性能指標(biāo)：

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

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

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

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

[[198224]]

其他的考慮

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

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

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

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

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

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

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

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

結(jié)論

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