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曾經發布過相關的文章。