Docker 监控实战：聚合+分组>N?（docker和虚拟机的区别）

Docker 监控实战：聚合+分组>N?（docker和虚拟机的区别）

2 / 3 的公司在尝试了 Docker 后最终使用了它

越大型的公司越早开始使用 Docker

研究发现主机数量越多的公司，越早开始使用 Docker。而主机数量多，在这个研究里就默认等同于是大型公司了。

Docker 优势

那为什么 Docker 越来越火呢？一谈起 Docker 总是会跟着让人联想到轻量这个词，甚至会有一种通过 Docker 启动一个服务会节省很多资源的错觉。然而 Docker 的「轻」也只是相对于传统虚拟机而已。

传统虚拟机和 Docker 的对比如图：

从图中可以看出 Docker 和 虚拟机的差异，虚拟机的 Guest OS 和 Hypervisor 层在 Docker 中被 Docker Engine 层所替代，Docker 有着比虚拟机更少的抽象层。

由于 Docker 不需要通过 Hypervisor 层实现硬件资源虚拟化，运行在 Docker 容器上的程序直接使用实际物理机的硬件资源。因此在 CPU、内存利用率上 Docker 略胜一筹。

Docker 利用的是宿主机的内核，而不需要 Guest OS，因此，当新建一个容器时，Docker 不需要和虚拟机一样重新加载一个操作系统内核，因此新建一个 Docker 容器只需要几秒钟。

总结一下 Docker 容器相对于 VM 有以下几个优势：启动速度快、资源利用率高、性能开销小。

这些解决方案都是基于开源系统来实现的，当然，我们也会把我们自己觉得有意义的修改回馈给社区，我们给 Docker、Kubernetes 和 lxcfs 等开源项目贡献了一些 patch。融入社区，与社区共同发展，这是一件很有意义的事情。

在没有专业运维团队来监控 Docker 的情况下，并且还想加快 Docker 监控的进程，该怎么办呢？

为了能够更精确的分配每个容器能使用的资源，我们想要实时获取容器运行时使用资源的情况，怎样对 Docker 上的应用进行监控呢？Docker 的结构会不会加大监控难度？

1. cAdvisor

3. Scout

Scout 是一款监视服务，并不是一个独立的开源项目。它有大量的插件，除了 Docker 信息还可以吸收其他有关部署的数据。因此 Scout 算是一站式监控系统，无需对系统的各种资源来安装各种不同的监控系统。 Scout 的一个缺点是，它不显示有关每个主机上单独容器的详细信息。此外，每个监控的主机十美元这样略微昂贵的价格也是是否选择 Scout 作为监控服务的一个考虑因素，如果运行一个有多台主机的超大部署，成本会比较高。

4. Sematext

5. Prometheus

Prometheus 由 SoundCloud 发明，适合于监控基于容器的基础架构。支持监控容器的资源和运行特性，支持多维度查询，能聚合 Docker 监控数据。

Docker 监控实践

数据的聚合&分组，是运维2.0时代的重头戏，因此我们重点选取其中比较有这个方面代表性的两个监控方案来看看具体的 Docker 监控过程。

Prometheus 由 SoundCloud 发明，可用于监控基于容器的基础架构。Prometheus 特点是高维度数据模型，时间序列是通过一个度量值名字和一套键值对识别。灵活的查询语言允许查询和绘制数据。它采用了先进的度量标准类型像汇总（summaries），从指定时间跨度的总数构建比率或者是在任何异常的时候报警并且没有任何依赖，中断期间使它成为一个可靠的系统进行调试。

Prometheus 支持维度数据，你可以拥有全局和简单的指标名像 container_memory_usage_bytes ，使用多个维度来标识你服务的指定实例。

可以创建一个简单的 container-exporter 来收集 Docker 容器的指标以及输出给 Prometheus 来消费。这个输出器使用容器的名字，id 和 镜像作为维度。额外的 per-exporter 维度可以在 prometheus.conf 中设置。

如果你使用指标名字直接作为一个查询表达式，它将返回有这个使用这个指标名字作为标签的所有时间序列。

如果你运行了许多容器，这个看起来像这样：

为了帮助你使得这数据更有意义，你可以过滤（filter） and/or 聚合（aggregate） 这些指标。

使用 Prometheus 的查询语言，你可以对你想的任何维度的数据切片和切块。如果你对一个给定名字的所有容器感兴趣，你可以使用一个表达式像 container_memory_usage_bytes{name="consul-server"}，这个将仅仅显示 name == "consul-server" 的时间序列。

像多维度的数据模型，来实现数据聚合、分组、过滤，不单单是 Prometheus。OpenTSDB 和 InfluxDB 这些时间序列数据库和系统监控工具的结合，让系统监控这件事情变得更加的多元。

现在我们来对比 Prometheus 和 Cloud Insight 在数据聚合、分组（切片）上的展现效果和功能。

数据聚合

根据不同的 Container Name 或 Image Name 对内存使用量或 Memeory Cache 进行聚合。

数据分组（切片)

根据不同的 Container Name 或 Image Name 对内存使用量或 Memeory Cache进行分组（切片）。

单方面监控 Docker 可能并不太适合与业务挂钩的应用，当业务量上涨，不单单是 Docker 的负载上升，其他 JVM 指标也能也会出现上升的趋势。如果我们利用 Acme 模拟真实应用环境，再通过 Cloud Insight 进行监控的话，需要新建一个用于此次监控的仪表盘，依次将想要获取的指标统统添加进去。

可以添加以下指标：

docker.cpu.user docker.cpu.sysytem docker.containers.running jvm.heap_memory jvm.non_heap_memory jvm.gc.cms.count jvm.heap_memory_max jvm.gc.parnew.time

应用 Acme 部署在四台 servers 上，我们开启四台 servers, 然后用 JMeter 给应用加压。随着时间 JMeter 不断给应用加压，当 users 人数达到 188 时，我们来看一下仪表盘的视图。

根据 JMeter 里的数据，CPU 占用和错误率都有所提升；与此同时，在指标 docker.cpu.user 这幅图中，蓝色的线所代表的 Container CPU 占用率已经超过 50%，逐渐接近 75%，系统剩余的 CPU 资源逐渐下降。

而指标 docker.cpu.system 图中同样可以看到蓝色的那条数据在 18：29 左右出现了一个波峰，代表系统 CPU 资源消耗突然增大。通过这两幅图，我们可以定位到 CPU 占用率过高的 Container ，及时而主动地去了解性能瓶颈，从而优化性能，合理分配资源。

用 jvm.heap_memory 的值去比左图 jvm.heap_memory_max 的值，将能清楚的反映 JVM 堆内存的消耗情况。而 jvm.gc.parnew.time 图中显示了新生代并行 GC 的时间数据。GC 是需要时间和资源的，不好的 GC 会严重影响系统的系能，良好的 GC 是 JVM 高性能的保证。

无法被监控的软件是很危险的，通过解读这张 Docker 仪表盘总览图，我们也许可以了解到 Docker 实时性能状况，精准定位到性能薄弱的环节，从而优化我们的应用。

总结

Docker 兼容相比其他的数据库、系统、中间件监控，要复杂一些。由于需要表现不同 Container 的性能消耗，来了解不同应用的运行情况，所以数据的聚合、切片（分组）和过滤，在 Docker 监控中成为了必备功能。

参考文章：