几种 Docker 监控方法对比(几种线路同杆架设时,必须保证高压线路在低压线路())

网友投稿 730 2022-09-11

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

几种 Docker 监控方法对比(几种线路同杆架设时,必须保证高压线路在低压线路())

从图中可以看出 Docker 和 虚拟机的差异,虚拟机的 Guest OS 和 Hypervisor 层在 Docker 中被 Docker Engine 层所替代,Docker 有着比虚拟机更少的抽象层。由于 Docker 不需要通过 Hypervisor 层实现硬件资源虚拟化,运行在 Docker 容器上的程序直接使用实际物理机的硬件资源。因此在 CPU、内存利用率上 Docker 略胜一筹。Docker利用的是宿主机的内核,而不需要 Guest OS,因此,当新建一个容器时,Docker 不需要和虚拟机一样重新加载一个操作系统内核,因此新建一个 Docker 容器只需要几秒钟。

既然 Docker 这么火,那么问题来了,为了能够更精确的分配每个容器能使用的资源,我们想要实时获取容器运行时使用资源的情况,怎样对 Docker 上的应用进行监控呢?Docker 的结构会不会加大监控难度?

1. cAdvisor

3. Scout

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

4. Sematext

时间关系我们选择了其中安装最简单的 Cloud Insight 来试验监控基于 Docker 的一个应用——Acme 的运行情况,后期时间允许会将其他几种监控方式都试一遍。

Docker 监控实战

单方面监控 Docker 可能并不太适合与业务挂钩的应用,当业务量上涨,不单单是 Docker 的负载上升,其他 JVM 指标也能也会出现上升的趋势。

我们尝试使用一个支持比较多中间件、数据库、操作系统、容器的 Cloud Insight 来说明这个实际的场景。

Cloud Insight

AcmeAir 是一款由原 IBM 新技术架构部资深工程师 Andrew Spyker,利用 Netflix 开源的 Netflix OSS 打造的开源电子商务应用。此应用具有如下特性:

首先,我们要打开 Cloud Insight 监控,还好 Cloud Insight 安装简单,一条命令即可。接着,我们新建一个用于此次监控的仪表盘,依次将想要获取的指标统统添加进去。比如,选中 jvm.non_heap_memory 这个指标,选择按照 instance 分组。

我们添加以下指标:

docker.cpu.user docker.cpu.sysytem docker.containers.running jvm.heap_memory jvm.nonheapmemory jvm.gc.cms.count jvm.heapmemorymax jvm.gc.parnew.time

应用 Acme 部署在四台 servers 上,我们开启四台 servers, 然后用 JMeter 给应用加压。随着时间 JMeter 不断给应用加压。

当 users 人数达到 188 时,我们再来看一下仪表盘的视图。

从图中可以看到,性能数据发生了变化,根据 JMeter 里的数据,此时 CPU 占用超过了50%,错误率也有所提升;对比来看,根据 Cloud Insight 里的曲线显示,蓝色的线所代表的 Container CPU 占用率已经超过50%,逐渐接近75%,系统剩余的 CPU 资源逐渐下降,该 Container 的系统 CPU 资源消耗也突然增大。我们可以通过这些定位到 CPU 占用率过高的 Container ,及时而主动地去了解性能瓶颈,从而优化性能,合理分配资源。

上一篇:Docker 监控- Prometheus VS Cloud Insight(docker )
下一篇:为什么 Cloud Insight 要支持监控 Docker(为什么做梦会梦见鬼)
相关文章

 发表评论

暂时没有评论,来抢沙发吧~