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曾经发布过相关的文章。

查看英文原文：Monitoring Metrics for Docker Containers