分享Docker监控体系(Kubernetes Mesos监控)-阿里云开发者社区

开发者社区> 云原生> 正文

分享Docker监控体系(Kubernetes Mesos监控)

简介: 常不释放资源,造成高CPU占用;比如进程结束异常,不停的重启相同的进程;比如日志级别设置过低,大量日志输出,影响进程性能和占用大量磁盘空间。所以做监控时一定要遵循有自我安全控制的能力。监控工具在拿到生产环境中运行前,一定要先在测试环境中进行一段时间的试运行 。

常不释放资源,造成高CPU占用;比如进程结束异常,不停的重启相同的进程;比如日志级别设置过低,大量日志输出,影响进程性能和占用大量磁盘空间。所以做监控时一定要遵循有自我安全控制的能力。监控工具在拿到生产环境中运行前,一定要先在测试环境中进行一段时间的试运行 。

3、触发式的数据采集

需要关注异常点的现场数据采集,比如threaddump,heapdump,主机的性能数据等。这些故障点的数据重启后就会失去,有些故障不能重现时,相关的分析数据就很重要了,所以对于这些数据,需要进行触发式的数 据采集。当满足某些条件时触发采集,而在平常不运行。

容器的监控方案

传统的监控系统大多是针对物理机或虚拟机设计的,物理机和虚拟机的特点是静态的,生命周期长,一个环境安装配置好后可能几年都不会去变动,那么对监控系统来说,监控对像是静态的,对监控对象做的监控配置也是静态的,系统上线部署好监控后基本就不再需要管理。

虽然物理机,虚拟机,容器对于应用进程来说都是host环境,容器也是一个轻量级的虚拟机, 但容器是动态的, 生命周期短,特别是在微服务的分布式架构下,容器的个数,IP地址随时可能变化。如果还采用原来传统监控的方案,则会增加监控的复杂度。比如对于一个物理机或虚拟机,我们只要安装一个监控工具的agent就可以了,但如果在一个物理机上运行了无数个容器,也采用安装agent的方式,就会增加agent对资源的占用,但因为容器是与宿主机是共享资源,所以在容器内采集的性能数据会是宿主机的数据,那就失去在容器内采集数据的意义了。

而且往往容器的数量比较多,那么采集到的数量也会非常多,容器可能启动几分钟就停止了,那么原来采集的数据就没有价值了,则会产生大量这样没有价值的监控数据,维护起来也会非常的复杂。那么应该如何对容器进行监控呢?答案是在容器外,宿主机上进行监控。这样不仅可以监控到每个容器的资源使用情况,还可以监控到容器的状态,数量等数据。

单台主机上容器的监控

单台主机上容器的监控实现最简单的方法就是使用命令Docker stats,就可以显示所有容器的资源使用情况,如下输出:

虽然可以很直观地看到每个容器的资源使用情况,但是显示的只是一个当前值,并不能看到变化趋势。而谷歌提供的图形化工具不仅可以看到每个容器的资源使用情况,还可以看到主机的资源使用情况,并且可以设置显示一段时间内的越势。以下是cAdvisor的面板:

而且cAdivsor的安装非常简单,下载一个cAdvisor的容器启动后,就可以使用主机IP加默认端口8080进行访问了。

跨多台主机上容器的监控

cAdivsor虽然能采集到监控数据,也有很好的界面展示,但是并不能显示跨主机的监控数据,当主机多的情况,需要有一种集中式的管理方法将数据进行汇总展示,最经典的方案就是 cAdvisor+ Influxdb+grafana,可以在每台主机上运行一个cAdvisor容器负责数据采集,再将采集后的数据都存到时序型数据库influxdb中,再通过图形展示工具grafana定制展示面板。结构如下:

这三个工具的安装也非常简单,可以直接启动三个容器快速安装。如下所示:

在上面的安装步骤中,先是启动influxdb容器,然后进行到容器内部配置一个数据库给cadvisor专用,然后再启动cadvisor容器,容器启动的时候指定把数据存储到influxdb中,最后启动grafana容器,在展示页面里配置grafana的数据源为influxdb,再定制要展示的数据,一个简单的跨多主机的监控系统就构建成功了。下图为Grafana的界面:

Kubernetes上容器的监控

在Kubernetes的新版本中已经集成了cAdvisor,所以在Kubernetes架构下,不需要单独再去安装cAdvisor,可以直接使用节点的IP加默认端口4194就可以直接访问cAdvisor的监控面板。而Kubernetes还提供一个叫heapster的组件用于聚合每个node上cAdvisor采集的数据,再通过Kubedash进行展示,结构如下:

在Kubernetes的框架里,master复杂调度后有的node,所以在heapster启动时,当heapster配合k8s运行时,需要指定kubernetes_master的地址,heapster通过k8s得到所有node节点地址,然后通过访问对应的node ip和端口号(10250)来调用目标节点Kubelet的HTTP接口,再由Kubelet调用cAdvisor服务获取该节点上所有容器的性能数据,并依次返回到heapster进行数据聚合。再通过kubedash进行展示,界面如下:

Mesos的监控方案

而Mesos提供一个mesos-exporter工具,用于导出mesos集群的监控数据prometheus,而prometheus是个集 db、graph、statistic、alert 于一体的监控工具,安装也非常简单,下载包后做些参数的配置,比如监控的对象就可以运行了,默认通过9090端口访问。而mesos-exporter工具只需要在每个slave节点上启动一个进程,再mesos-exporter监控配置到prometheus server的监控目标中就可以获取到相关的数据。架构如下:

在Prometheus的面板上我们可以看到Prometheus的监控对象可以为mesos-export,也可以为cAdvisor。

下面为Prometheus的展示界面:

采集工具的对比

cAdvisor 可以采集本机以及容器的资源监控数据,如CPU、 memory、filesystem and network usage statistics)。还可以展示Docker的信息及主机上已下载的镜像情况。因为cAdvisor默认是将数据缓存在内存中,在显示界面上只能显示1分钟左右的趋势,所以历史的数据还是不能看到,但它也提供不同的持久化存储后端,比如influxdb等。

Heapster的前提是使用cAdvisor采集每个node上主机和容器资源的使用情况,再将所有node上的数据进行聚合,这样不仅可以看到整个Kubernetes集群的资源情况,还可以分别查看每个node/namespace及每个node/namespace下pod的资源情况。这样就可以从cluster,node,pod的各个层面提供详细的资源使用情况。默认也是存储在内存中,也提供不同的持久化存储后端,比如influxdb等。

mesos-exporter的特点是可以采集 task 的监控数据。mesos在资源调度时是在每个slave上启动task executor,这些task executor可以是容器,也可以不是容器。而mesos-exporter则可以从task的角度来了解资源的使用情况,而不是一个一个没有关联关系的容器。

以上从几个典型的架构上介绍了一些监控,但都不是最优实践。需要根据生产环境的特点结合每个监控产品的优势来达到监控的目的。比如Grafana的图表展示能力强,但是没有告警的功能,那么可以结合Prometheus在数据处理能力改善数据分析的展示。下面列了一些监控产品,但并不是严格按表格进行分类,比如Prometheus和Zabbix都有采集,展示,告警的功能。都可以了解一下,各取所长。

本文转自开源中国-分享Docker监控体系(Kubernetes Mesos监控)

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云原生
使用钉钉扫一扫加入圈子
+ 订阅

云原生时代,是开发者最好的时代

其他文章