Docker监控套件(Telegraf+Influxdb+Gra

Docker监控套件(Telegraf+Influxdb+Grafana)研究与实践

如今，云计算以及DevOps理念越来越流行，随之而来的是越来越多的人尝试使用Docker以及相关的生态技术来构建企业测试，开发甚至生产环境来满足企业标准化和自动化运维，然而随着Docker容器技术的广泛应用，容器相关的监控也变的越来越重要了。

本篇文章主要分享一下Docker容器监控方面的心得。目前市面上还是有多种开源方案可供选择的，比如说谷歌出品的Cadvisor加上Influxdb+Grafana架构、结合Kubernetes使用的Heapster方案以及开源的服务监控系统Prometheus，选择从不同方案去探索整个Docker容器的监控架构，我们会发现整个Docker容器监控方案其实大同小异，基本上都是分为三个部分，客户端通过Docker进程采集该主机上容器的相关数据(通过socket采集和通过API采集)；中间件时间序列数据库存储存储序列化后的数据以及业务容器可视化数据展示。其实从监控架构本身来思考监控体系的构建，也无非就是采集端，数据存储和处理以及可视化数据展示，只不过一个稳健高效的监控系统会在各个环节中对于系统性能，数据处理能力以及架构的可用性和可扩展性进行不断的优化。
​
​本篇文章为大家介绍一个新的监控工具集TIG(Telegraf+Influxdb+Grafana)去监控Docker容器资源状态。由于Docker容器中的资源都是通过cgroups去做限制的，因而对容器的监控基本就是通过去监控cgroups中容器的各个文件来监控该容器的资源使用情况的，而这一切Docker都封装好了API，用户可以过API去进行获取容器的相关资源信息。

而之所以选择Telegraf去采集相关的数据，无非在于以下几种考虑：

• 1.Telegraf工具是使用go编写的，在性能和效率上会稍微好些，而且不依赖其他系统软件包(这个在Telegraf相关文章会讲到)
• 2.Telegraf采用插件化数据采集，可以支持多种数据/服务集的采集(docker，nginx，redis)，并且可以支持本身系统级别的监控(磁盘，io，网络，内存等)。因此，使用Telegraf的插件化特性其实可以覆盖到多种监控需求，并且不需要进行多个agent的开发。至于性能的问题，基本的数据采集还是不错的，消耗资源也不多，如果想要针对自身业务的特性去二次开发监控项，那就得看plugin开发水平了。
  当然，本篇文章只是以TGI为例的一个引子，在实际的监控架构中，任何一个环节都可以找到替代品，而以我的经验是建议用Telegraf会比较好些。

1.Telegraf相关介绍以及实践

2.Influxdb相关介绍以及实践

3.Grafana相关介绍和实践

4.TIG架构组成以及原理介绍

weichat.png