斌哥的 Docker 进阶指南—监控方案的实现

过去的一年中，关于 Docker 的话题从未断过，而如今，从尝试 Docker 到最终决定使用 Docker 的转化率依然在逐步升高，关于 Docker 的讨论更是有增无减。另一方面，大家的注意力也渐渐从 “Docker 是什么”转移到“实践 Docker”与“监控 Docker”上。

本文转自刘斌博文「如何选择 Docker 监控方案」，文中刘斌从技术的角度深入解释了 Docker 监控的数据采集原理，介绍了现有开源的监控方案，以及能够对 Docker 进行监控功能的主流 SaaS 服务工具。

上一篇文章中介绍了 Docker 监控目的及技术基础，本篇文章将介绍，Docker 监控方案的实现。

Docker 监控方案的实现

自己动手 + 开源软件
SaaS

评价标准

功能
- 信息详细程度
- 查询的灵活程度
- 报警 + API
灵活性
- 定制
成本
- 学习、开发
- 维护
运维
- 部署复杂程度
高可用

需要考虑的基本要素如上所示，不多述。

自己动手

灵活性强
成本高

这里的成本包括开发成本，开发成本可能包括招人和培训，开发时间和填坑时间。开发完了还需要维护成本，而且随着Docker的升级，可能还需要对metric的采集实现进行升级，以及各种bugfix。

自己动手打造监控方案

采集
存储
展示
报警（动作）

StatsD 是 Flickr 公司首先提出来的，后来由 Esty 公司发扬光大的一个轻量级的指标采集模块。

简单来讲，StatsD 就是一个简单的网络守护进程，基于 Node.js 平台（Esty实现，其实也有其他语言版本），通过 UDP 或者 TCP 方式侦听各种统计信息，包括计数器和定时器，可以用来采集操作系统、不同数据库、中间件的数据指标，进行缓存、聚合，并发送到Graphite 等存储和可视化系统中。

StatsD 具有以下优点：

简单

首先安装部署简单，且StatsD 协议是基于文本的，可以直接写入和读取，方便实现各种客户端和SDK。

Cloud Insight的探针也是采用这些方式，我们有些SDK也是基于StatsD的，目前有Ruby、Python和Java的，在 GitHub 上可以看到。

低耦合性

StatsD 守护进程采取 UDP 这种无状态的协议，收集指标和应用程序本身之间没有依赖，不会阻塞应用，不管StatsD的状态是运行中，还是没在运行，都不会影响应用程序，应用程序也不关心StatsD是否收到数据。

易集成

StatsD非常容易整合其他组件，可以自己编写采集业务逻辑，发送到StatsD守护进程即可。也就是说用户的工作很简单，只需要按定义好的规则采集数据发送到Stats，然后用Graphite存储、展示，通过使用Riemann进行报警。

Tcollector

来源于OpenTSDB

Tcollector 是一个采集指标数据并保存到OpenTSDB的框架，你可以使用该框架自己编写采集的业务逻辑。类似StatsD，运行在客户端，收集本地的metric信息，推送到OpenTSDB。

Collectd

System statistics collection daemon
存储到RRD
插件机制（input/output）
简单报警功能

Collectd即是一个守护进程，也是一个框架，类似StatsD，它性能非常好，采用C语言编写。Collectd不直接支持从Docker中取数据，但是我们可以自己编写插件来采集性能指标数据。

Collectd有强大的插件机制，已经实现了包括amqp、rrdtool、graphite、http、kafka、redis、mongodb、OpenTSDB以及CSV文件等在内的各种插件。

在4.3版本之后还支持简单的基于阈值检查的报警机制。

cAdvisor是一个用于收集、聚合处理和输出容器运行指标的守护进程。而且cAdvisor基本算是一个获取Docker性能数据的标配了吧。

一句命令就可以启动cAdvisor容器，访问8080端口即可看到性能指标数据。cAdvisor可以通过storage_driver参数将数据存到influxdb，同时也可以将metric输出为Prometheus的格式，所以很多自定义Docker监控系统都会采取cAdvisor + Prometheus 的组合。

存储TSDB