對於容器環境來說全棧監控究竟意味著什麼？

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

到底什麼全棧?

「全棧工程師」這個術語在2023年初被提出，表示在整個應用程式堆疊中具有廣泛技能的開發人員。包括前端和後端應用程式元件的組合，甚至包括基礎設施層的**體現。使用許多不同的應用程式元件或微服務的容器化應用程式的趨勢，增加了現代應用程式堆疊的複雜性。甚至有人批評了「全棧工程師」這個術語。

雖然對於乙個人來說，了解應用程式每個部分的開發細節可能是不現實的(除非非常簡單)，但是應用程式在生產環境中執行時，通常需要堆疊的所有層都具有可見性。這允許開發人員在應用程式或基礎設施的適當部分中快速識別問題並採取相應的行動。所以，在這篇文章中，我們回來探索乙個容器化應用程式的「全棧」可見性或監視方式。例如，堆疊通常是什麼樣子的?棧的不同層的相關度量是什麼?收集和分析所有這些度量標準需要什麼功能?

容器堆疊是什麼樣的?

在筆者的演示中，經常會使用下面的來說明容器化應用程式中最重要的層是什麼，並討論傳統的單片應用程式之間的一些重要區別。實際上，隨著容器的使用和一些編排平台的使用，還引入了額外的抽象層。現在，從所有這些層收集度量並將它們繫結在一起是非常重要的，能方便我們完全理解乙個容器化的應用程式是如何工作的。

需要收集哪些指標?

根據上面的，為了獲得我們的應用程式的全棧可見性，我們需要從下面的層中收集效能指標：

·在基礎設施中，我們希望收集不同的資源指標，比如cpu、記憶體、磁碟、網路等等，可能來自物理伺服器或虛擬伺服器，也可能是雲例項。在後一種情況下，這些指標通常可以通過某種api(如amazon cloudwatch)來訪問，同樣包括我們在雲平台上使用的服務的其他指標。

·通常，乙個協調器用於幫助基礎設施上的容器的部署、擴充套件和管理。kubernetes(或者是red hat openshift之類的產品)和docker swarm是最受歡迎的技術。在這一層，我們希望了解容器計數和容器動態，例如縮放事件。從協調器中，我們還可以收集關於容器如何與服務繫結的服務定義和關係。這允許我們在服務級別進行報告，例如特定服務的容器數量或其他相關指標。

·對於容器本身，我們還希望了解每個容器和每個服務的資源度量，以及容器生命週期事件。此外，我們希望了解容器內的應用程式是如何執行的。這種所謂的容器監控為我們提供了針對容器內執行的不同服務的應用程式特定的度量標準。

·最後，我們希望看到對終端使用者的影響，並理解作為應用程式的消費者所獲得的效能。這通常包括頁面載入時間、錯誤等前端指標，有時甚至可以新增業務指標來「監視真正重要的事情」。

其他的考慮

從這些層收集不同的度量標準本身已經是乙個挑戰。大多數監控工具只關注其中的乙個子集，因為它們是為傳統的單片應用程式開發的。現代容器監控工具應該與上面提到的所有層進行整合，以提供完整的影象以及防止出現盲點。

但這並不僅僅侷限於度量收集。還有一些其他重要的考慮事項，與度量指標和事件的收集方式有關。

·自動儀表:考慮到容器的短暫特性，新容器在啟動時自動監控是至關重要的。這包括認識到已經啟動了乙個新的容器，以及在內部執行的服務，以及如何監視這些服務。例如，在coscale中，我們使用乙個豐富的外掛程式庫來監控來自已知服務的應用程式特定指標，如nginx、redis、mongodb和許多其他服務。

·另外，當將新節點新增到集群時，重要的是這些節點配置，而且配置了正確的監視**和設定，這樣你的監視就可以與環境進行伸縮。這可以通過在kubernetes中使用「daemonsets」的概念或docker swarm的全球服務來完成。

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

·收集資料是一回事，但理解它則是另一回事。為了獲得正確的見解，需要對容器環境進行正確的視覺化。乙個擠滿了所有容器的所有資源指標的圖表的儀錶盤，並不是很有洞察力。你通常希望從高層次的服務和集群的檢視開始，然後在出現問題時能夠進行深入的研究。

·同時，對問題本身的檢測也具有挑戰性。容器和服務的數量以及它們生成的度量指標的數量已經導致了資料的氾濫。將其與容器的動態方面相結合，你就可以明白為什麼經典的報警技術常常會失敗。因此，在這樣的環境中，更多的自我學習分析技術，例如動態的基底和異常檢測，是非常有價值的，並且有助於對問題的主動檢測。

·最後，在發現問題的同時，還應該對它們進行修復。為此，需要收集適當數量的上下文資訊來進行故障排除。這包括在問題發生時發生的其他事件的相關性。是否所有的特定服務的容器都受到了影響，或者僅僅是乙個?在**也有下游服務的問題?更詳細的日誌資料或跟蹤資訊可以幫助解決問題服務的故障。

結論

容器環境的完整堆疊監控與單片應用程式監控是不同的。典型的監控工具通常不能提供所有不同層次的正確見解，並且很難處理容器環境的規模和動態。無論您計畫使用開源解決方案還是商業產品，上面的不同考慮都可以幫助您選擇正確的工具，以確保您的環境完全可見。謝濤

對於容器環境來說 全棧監控究竟意味著什麼？

對於容器環境來說 全棧監控究竟意味著什麼？

對於容器環境來說 全棧監控究竟意味著什麼？

為什麼 API 監控對於任何業務來說都重要？

相關推薦

對於容器環境來說全棧監控究竟意味著什麼？

對於容器環境來說全棧監控究竟意味著什麼？

對於容器環境來說全棧監控究竟意味著什麼？