docker

DevOps无疑是近些年来IT界最火的一个概念,作为实现DevOps的一个重要技术手段,Docker容器技术也广泛为大家所使用,在短短的三年时间内,已经有40%的用户在自己的生产环境中部署使用。

在六月结束的全球DockerCon 16大会上,Docker的CEO Ben Golub宣布全球已有46万个应用Docker化,该数据在两年内增长了3000%。同时,Ben称他们会继续努力使得每一台服务器都可以使用Docker,并估计市场价值为上百亿。

随着Docker容器在系统中的广泛使用,对于容器的运维管理成为了运维同学需要掌握的新技能,而在这里,笔者将分享一下基于Zabbix的容器监控方案。

  1. Docker控内容

系统运维的很大一部分工作就是管理服务器,而管理的前提即是对被管理事物有清晰地了解。监控可以帮助我们了解我们管理的服务器的情况,所以监控是系统运维的基础。

对于一般性的系统,应该做到从下到上三层的监控:

  1. 1基础架构层

即最底层,包括服务器的基本信息如CPU、memory、I/O、网络等;

  1. 2中间服务层

是服务器上安装服务的监控,如Tomcat、Niginx、MySQL等;

  1. 3上层应用层

这层可以使用APM监控工具来完成。

对于容器而言,它既属于基础架构层又属于中间服务层,可以说是建立在底层上的服务,却又作为了里层应用的基础架构。这使得Docker容器的监控大体分成三个部分:Docker服务的监控、Docker服务下每一个容器的基本监控、Docker容器里所运行服务的监控。

  1. Docker监控的基本原

常见的监控方法包括Cgroups,Docker command以及Docker API。

Cgroups就是利用伪文件的方式获取单个容器的基本状况,这种方式获取信息全但需要对数据做二次处理;

Docker command是利用Docker服务提供的一些命令来获取信息,这种方法简单便捷但信息量有限;

Docker API可以获取比Docker command更多的信息但是对于大规模的容器管理有着性能的瓶颈。

  1. Docker监控的挑战

容器监控的主要挑战就是监控的代理安装在哪里,是在容器内部还是在容器外部。

在容器内部的话,可以直接监控容器内的服务,但会占用资源;在外部的话技术上会复杂一些,但能更大程度的发挥容器的性能。

因为Docker官方的最佳实践是一个容器只运行一个服务,而添加监控代理在内部无疑增加了服务;所以我们并没有考虑把监控代理放在容器内部。

据云络的经验,我们建议将监控代理放在容器外部。将监控代理放在容器外部需要解决的关键技术,是如何获取容器内部服务的信息。

  1. 基于ZabbixDocker监控方

我们运维平台的监控系统是Zabbix,所以我们主要是尝试了把监控集成到Zabbix上。下面是云络目前监控方案的流程图。

首先,考虑Docker监控代理安装的位置。如果选择将监控代理部署在容器内部,则需要在容器里启动一个start up服务来分别开启监控代理以及容器内所要执行的服务,这将损耗容器的性能,所以这里并不建议。

于是,我们尝试将监控代理部署在容器外侧及host上。

其次,选择监控获取信息方式。

从下自上来看,首先,我们通过Docker API来获取Docker服务的信息,在这里我们可以收集到该host上有多少容器在运行,哪些停止,哪些暂停等整体信息;

随后,我们利用Zabbix的Low discovery 获取容器的服务情况,然后在Zabbix后台建立相应的Zabbix host;

之后再分别利用Cgroups(即伪文件 Pse-udo file)获取单一容器的CPU,I/O等基本情况,同时利用Docker exec脚本定位容器内部服务类别并赋予监控模板收集需要的信息。

最后再将这些信息汇总到Zabbix服务器,进行统一的处理和显示。

  1. 容器技的未来展望

容器具有轻量级、易部署的特性,如果未来在性能、安全性、可靠性等层面更加成熟的话,那么容器技术在企业的使用程度会进一步增大。

容器技术是实现DevOps的一个重要技术手段。随着容器技术的广泛使用,将会出现更多的大规模的集群式容器需要监控和管理,笔者认为这将是未来容器发展对监控的一大挑战。

本文首载于崔牛会官方微信平台“牛透社”:https://mp.weixin.qq.com/s?__biz=MzI4NjEwMDQzMQ==&mid=2649817859

&idx=1&sn=a76d099c795c557f227251c09b1895d6&scene=1&srcid=0823hF1398734FPIXXUOGIM9&pass_ticket=DbbP

bdGqDeegi2vkkeMbNYCHp%2Bm1j1wQj%2BMs5mFeHtQqHmow5UoBeLE8JvqKsMYa#rd