關于大多數人來說，“全?！?Full Stack)的意思極好了解?？墒羌偃缭蹅兊恼擃}涉及到監控容器環境呢?全部作業就會開端變得有些含糊了。在這篇文章中，筆者探究了在這么的一個環境下，取得全?？梢娦缘牟灰粯臃矫婧鸵苍S會遇到的一些應戰。




究竟啥全棧？


“全棧工程師”這個術語在2010年頭被提出，表明在全部應用程序倉庫中具有廣泛技能的開發人員。包含前端和后端應用程序組件的組合，乃至包含基礎設施層的代碼表現。運用很多不一樣的應用程序組件或微效勞的容器化應用程序的趨勢，添加了現代應用程序倉庫的復雜性。乃至有人批評了“全棧工程師”這個術語。

盡管關于一個人來說，了解應用程序每個有些的開發細節也許是不現實的(除非十分簡略)，可是應用程序在出產環境中運轉時，一般需求倉庫的一切層都具有可見性。這答應開發人員在應用程序或基礎設施的恰當有些中迅速辨認疑問并采納相應的舉動。所以，在這篇文章中，咱們回來探究一個容器化應用程序的“全?！笨梢娦曰虮O督方法。例如，倉庫一般是啥姿態的?棧的不一樣層的有關衡量是啥?搜集和剖析一切這些衡量規范需求啥功用?



容器倉庫是啥樣的?
在筆者的演示中，常常會運用下面的圖畫來闡明容器化應用程序中最首要的層是啥，并評論傳統的單片應用程序之間的一些首要差異。實際上，跟著容器的運用和一些編列渠道的運用，還引入了額定的籠統層。如今，從一切這些層搜集衡量并將它們綁定在一起是十分首要的，能便利咱們徹底了解一個容器化的應用程序是怎么作業的。


需求搜集哪些目標?


依據上面的圖畫，為了取得咱們的應用程序的全?？梢娦?，咱們需求從下面的層中搜集功能目標：

·在基礎設施中，咱們期望搜集不一樣的資本目標，比方CPU、內存、磁盤、網絡等等，也許來自物理效勞器或虛擬效勞器，也也許是云實例。在后一種情況下，這些目標一般能夠經過某種API(如Amazon Cloudwatch)來訪問，相同包含咱們在云渠道上運用的效勞的別的目標。

·一般，一個和諧器用于協助基礎設施上的容器的布置、拓展和辦理。Kubernetes(或許是Red Hat OpenShift之類的商品)和Docker Swarm是最受期待的技能。在這一層，咱們期望了解容器計數和容器動態，例如縮放工作。從和諧器中，咱們還能夠搜集關于容器怎么與效勞綁定的效勞界說和聯系。這答應咱們在效勞等級進行陳述，例如特定效勞的容器數量或別的有關目標。

·關于容器自身，咱們還期望了解每個容器和每個效勞的資本衡量，以及容器生命周期工作。此外，咱們期望了解容器內的應用程序是怎么運轉的。這種所謂的容器監控為咱們供給了對于容器內運轉的不一樣效勞的應用程序特定的衡量規范。

·最終，咱們期望看到對最終用戶的影響，并了解作為應用程序的消費者所取得的功能。這一般包含頁面加載時刻、過錯等前端目標，有時乃至能夠添加事務目標來“監督真實首要的作業”。





別的的思考
從這些層搜集不一樣的衡量規范自身現已是一個應戰。大多數監控東西只重視其間的一個子集，由于它們是為傳統的單片應用程序開發的?，F代容器監控東西應當與上面說到的一切層進行集成，以供給完好的圖畫以及避免呈現盲點。

但這并不只是局限于衡量搜集。還有一些別的首要的思考事項，與衡量目標和工作的搜集方法有關。

·自動外表:思考到容器的時間短特性，新容器在啟動時自動監控是至關首要的。這包含認識到現已啟動了一個新的容器，以及在內部運轉的效勞，以及怎么監督這些效勞。例如，在CoScale中，咱們運用一個豐厚的插件庫來監控來自已知效勞的應用程序特定目標，如NGINX、Redis、MongoDB和很多別的效勞。

·別的，當將新節點添加到集群時，首要的是這些節點裝備，而且裝備了準確的監督署理和設置，這么你的監督就能夠與環境進行彈性。這能夠經過在Kubernetes中運用“DaemonSets”的概念或Docker Swarm的全球效勞來完結。

·另一個首要的思考要素是監督署理運轉的方位和它們生成的開支。這是格外有關的，由于容器是輕量級且不可變的構造，應當盡也許少地受到影響。一些監控東西需求將署理添加到容器映像中，或許作為sidecar容器，這一般會添加很多的開支。別的東西，例如CoScale，只需求每個節點上的一個署理(一般是運轉它自己的容器)，開支添加最小。

·搜集數據是一回事，但了解它則是另一回事。為了取得準確的見地，需求對容器環境進行準確的可視化。一個擠滿了一切容器的一切資本目標的圖表的外表盤，并不是很有洞察力。你一般期望從高層次的效勞和集群的視圖開端，然后在呈現疑問時能夠進行深化的研討。
·一起，對疑問自身的檢查也具有應戰性。容器和效勞的數量以及它們生成的衡量目標的數量現已致使了數據的眾多。將其與容器的動態方面相結合，你就能夠理解為啥經典的報警技能常常會失利。因而，在這么的環境中，更多的自我學習剖析技能，例如動態的基底和反常檢查，是十分有價值的，而且有助于對疑問的自動檢查。

·最終，在發現疑問的一起，還應當對它們進行修正。為此，需求搜集恰當數量的上下文信息來進行毛病掃除。這包含在疑問發作時發作的別的工作的有關性。是不是一切的特定效勞的容器都受到了影響，或許只是是一個?在哪里也有下流效勞的疑問?更具體的日志數據或盯梢信息能夠協助解決疑問效勞的毛病。



定論


容器環境的完好倉庫監控與單片應用程序監控是不一樣的。典型的監控東西一般不能供給一切不一樣層次的準確見地，而且很難處理容器環境的規劃和動態。不管您方案運用開源解決方案仍是商業商品，上面的不一樣思考都能夠協助您挑選準確的東西，以確保您的環境徹底可見