• 斌哥的 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的,目前有RubyPythonJava的,在 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

    • OpenTSDB
    • Influxdb
    • RRDTool
    • Graphite

    关于时序列数据库,可以看附录中相关的介绍文章。推荐使用OpenTSDB或者Influxdb,简单对比一下各自特点如下:

    • OpenTSDB

      • Java & HBase
      • 易扩展(集群功能强大)
      • 机器多,运维稍显麻烦
    • Influxdb

      • Golang
      • 集群功能不太成熟
      • 有类SQL的查询语句
      • 单台即可工作

    这两者都支持自由模式和多维度,非常适合用于采用tag机制的数据模式建模。
    开源可视化工具

    • Graphite
    • Influxdb + Grafana
    • Prometheus

    光有数据是不够的,raw data没有任何意义,我们需要良好的可视化组件来展示数据和数据的内在意义,发挥数据的作用。

    我们也可以将数据存储和展示交给其他开源软件。

    如果你的数据采集和存储都是自己来完成的,只想使用一个外部的图形化界面的话,选Grafana应该没错,Grafana展现形式非常丰富,配置也很灵活。

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

    以上,先到这里。

    下一章,刘斌将为大家介绍 Docker 监控的开原方案,主流 SaaS 服务,及其特点。

    超好用的监控软件 Cloud Insight 不仅能监控 Docker,还能对 Nagios 进行更好的可视化哦~

    阅读更多技术文章,请访问 OneAPM 官方博客

    本文转自 OneAPM 官方博客

  • 相关阅读:
    UIImageView
    正则表达式
    控制器生命周期和 UIView
    Storyboard
    1218.2——property关键字
    1218.1——OC中的常见关键字及一些基本方法
    1217.2——定义一个类+方法声明调用
    1217.1——OC准备
    1216.2——文件操作
    1216.1——双链表
  • 原文地址:https://www.cnblogs.com/oneapm/p/5457983.html
Copyright © 2020-2023  润新知