转载

斌哥的 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版本之后还支持简单的基于阈值检查的报警机制。

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

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

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

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

存储TSDB