Stefan Thies是Sematext的DevOps布道師，在最近的一篇博客文章中，他討論了十個重要的容器監控指標及其在Docker容器運維中的意義，尤其是針對單個主機上運行多個容器的場景。我們可以將它們集中到一個相互關聯的視圖中，這些指標為基于Docker的環境監控提供了一個很好的起點。
按照作者的說法，他針對容器運維提出了一組指標，它們的基本原理來源于容器監控所面臨的挑戰，因為容器的行為是與VM不同的：“傳統的監控方案會從每個服務器以及它們運行的應用中獲取指標。這些服務器以及運行在服務器上的應用一般都是靜態的，會有非常長的運行時間。”
相反，容器的行為與之不同：
可以短期存活和動態調度； 是進程，但是具有自己的環境、虛擬網絡和不同的存儲管理； 共享底層主機的資源，在相同的主機上可能會調度短期存活的批處理命令以及長期存活的進程。Stefan所提出的指標可以分為基于容器的以及基于主機的兩類：
基于容器的指標
資源共享需要對容器進行合理的配額，而這反過來又需要能夠看到容器資源的使用情況。根據調查，一個Docker主機一般會運行5個容器。另外，像Docker Swarm、Kubernetes或Mesos這樣的容器協作解決方案能夠高效調度主機集群中的多個容器，因此容器的行為需要進行監控并進行相應的調優。
容器CPU——節流的（Throttled）CPU時間：觀察在容器的CPU使用中節流的總時間，這個指標提供了在Docker中正確設置CPU共享的基本信息。只有當主機的CPU達到極限，核心才會限流容器的CPU時間。“這個指標的飆升提供了一個很好的指示，這意味著一個或多個容器所需要的CPU處理能力超出了主機所提供的能力范圍。” 容器的內存使用、容器的內存交換（Swap）以及容器內存失敗計數器（Memory Fail Counter）：這些指標的上升意味著容器需要的內存數量超出了為其分配的值。Stefan建議使用容器內存上限（container memory limit）來確保應用不會使用太多內存，從而避免影響到同一個主機上的其他容器。但是，Docker文檔還提到：“注意，內存控制分組（memory control group）會增加一點損耗，因為它會對主機的內存使用進行非常細粒度的統計。” 容器的磁盤I/O：多個容器可以并發使用相同的主機資源。監控有助于分配“更高的吞吐量給關鍵應用，如數據存儲或Web服務器，而對于批處理的操作則可以進行磁盤I/O分流。” 容器的網絡指標：Stefan認為，對于互相關聯的容器來說，監控虛擬網絡是非常重要的，比如容器化的負載均衡器。丟棄的數據包需要進行跟蹤，不過“網絡流量也是一個很好的指示器，能夠反映客戶端對應用的使用情況，有時候我們會看到很高的峰值，這可能意味著出現了拒絕服務攻擊、負載測試或者客戶端應用出現了故障。”基于主機的指標
相對于容器來說，Docker主機是長期運行的，因此應該進行處理能力管理和資源優化，當多個負載運行在同一個主機上的時候，更應如此。
主機CPU和主機內存：理解主機和容器的CPU以及內存使用情況能夠優化Docker主機的資源使用，作者這樣寫到：“當資源使用進行了優化之后，實際上我們會預期甚至要求出現較高的CPU使用率，只有當CPU使用率出現下降（服務產生了中斷）或者長期超過一定的最大限制（如85%）時才應該出現告警。” 主機磁盤空間：Stefan認為，對磁盤空間進行監控和告警是非常重要的，因為容器、鏡像以及主機mount的卷都會消耗磁盤空間。定期移除不再使用的容器和鏡像以便對磁盤空間進行清理是一種很好的實踐。 運行在主機上的容器總數：：在靜態使用的場景下，了解當前和歷史上的容器數量能夠幫助我們在升級的時候確保所有的功能都與之前的部署具有相同的運行狀態。在更為動態的場景中，像Kubernetes這樣的集群管理器會自動調度不同類型的負載，這樣的話指標就會發生不規則的變化。因此，Stefan建議使用異常探測（anomaly detection）功能來對突然的變化進行告警。作者建議使用現代的監控工具，以便應對容器動態化的特性。 Sematext提供了一個監控解決方案，它將監控、日志以及事件集成到了同一個視圖之中，支持按照時間來查看這些數據。Docker Agent擴展了這個容器監控方案，包含了容器自動探測以及收集Docker事件、日志以及指標的特性。
監控Docker容器的其他方案包括cAdvisor、sysdig和DataDog。關于這些工具的對比，Rancher和InfoWorld曾經發布過相關的文章。
京公網安備 11010502049343號