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