Docker 监控之 SaaS 解决方案

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

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

SaaS

  • turnkey解决方案
  • 维护成本 ~ Zero
  • 适合中小企业

对于中小型企业尤其创业公司来说,自主开发或者直接利用现有的开源工具进行监控都有一些问题,主要是成本和风险的问题。对于中小企业,应该先把精力集中在发展核心业务,能外包的就先不自己做。而且很多中小公司大家都是全栈,没有专门的运维人员,都是临时抱佛脚,随时都会变成救火队员。

SaaS 最大的优点是什么?那就是免运维,开箱即用,修改的代码少甚至不需要修改代码,或者只需要简单的安装一个 agent 就可以工作了。很多 SaaS 软件的开场白都是运行一条 yum install ,然后倒上一杯咖啡等几分钟,就能看到数据了。

你的初期投入非常小,上手非常快,而且成本比较低(如果你的公司已经有数百上千服务器了,则这部分成本可能会变高,就跟是自建机房还是用云主机的对比一样)。

传统APM一般也都提供了对Docker的监控:

  • New Relic
  • AppDynamics
  • Dynatrace(Ruxit)

最近也有很多专门用于基础设施监控的SaaS服务

  • Datadog
  • SysDig
  • Cloudinsight
  • clusterup
  • Scout

RancherLab 公司有人写了篇文章,大家可以参考下。这篇文章名为《Comparing Seven Monitoring Options for Docker》,即对比了七种不同的监控 Docker 的方案,包括使用 docker stats 命令, cAdvisor, Prometheus ,Sensu,以及 SaaS 服务 Scout, Sysdig Cloud 等方案。

RancherLab 有一个产品叫 RancheOS,是一个专门为了运行 Docker 准备的微型 Linux 版本,它的口号是“The perfect place to run Docker”。跟 CoreOS 类似,但是貌似功能不如 CoreOS 多,也没有 CoreOS 有名,也没有 CoreOS 中 fleet、flannel 和etcd 这样的组件,尤其是 etcd,可以说是 CoreOS 的副产品,但是几乎成了 Docker 业界标准的 kv store 和服务发现组件了。

Datadog

  • 国外最好
  • 功能很强大
  • 安装很简单

国外最流行的 SaaS 解决方案是 Datadog,国内可能比较成熟、规模较大的应该算是 Cloud Insight 了。这类服务用户只需要注册一个账号,按照安装过程通过一条命令来安装探针即可在 web 展示端看到数据。

要说到 Datadog 的不足,那就是在国外,网络延迟需要考虑,万一哪天不科学了也需要有所准备。价格方面 Datadog 也比较贵。免费 plan 支持5台机器,而且只保留一天的数据,而且没有报警功能。收费版 15 美元一台主机,支持报警功能,数据存储 13 个月。

说道 SaaS,不得不提客服,直接面对非母语客服人员交流起来肯定会有诸多不顺吧。

Cloudinsight

  • 实时数据
  • 历史数据
  • 仪表盘
  • 混合监控
  • 报警功能

当然,最便宜的还是Cloud Insight,有多便宜呢,官方定价的话 3 个探针以下是免费的,支持超过 3 台主机的话,平均每天 1 快钱。这只是官方定价,实际上还会便宜,貌似联系客服就可以知道有多便宜了。

Docker 监控之 SaaS 解决方案 技术分享 第1张

Docker 监控之 SaaS 解决方案 技术分享 第2张

Cloudinsight 的图表功能也很丰富,能对任何指标以图表的方式展示,还能在图表上叠加事件,比如报警通知、服务启动停止等,能在观察到 metric 变动趋势的同时,看到相应的时间,了解 metric 发生变动的原因。比如 CPU load 超过一定值时,可能触发报警,这时你能在图表上看到相应的事件,同样,如果 CPU load 一直不是很低,但是从某一时间点开始变低了,你可能也能从一次新的代码部署中了解原因。

Cloudinsight 还支持ChatOps集成,包括国内的 BearyChat 和简聊。随着 Devops 文化的普及,相信这些工具的重要性也会与日俱增。不过貌似简聊已经开源了(不运营了?)。

Sysdig

  • 免费工具
  • SaaS 服务
  • 拓扑可视化

可以认为 sysdig 是 strace + tcpdump + htop + iftop + lsof + 众多 linux 常用的系统监控命令的合体。

如果你熟悉 tcpdump,那么你知道它能还原整个网络流量,而 sysdig 则是操作系统级别的监控工具,能捕捉到所有 OS 事件和数据。而且 sysdig 原生支持 Linux container,包括 Docker 和 LXC,提供了基本的指标监控信息。除了性能指标,sysdig 还能采集 trace 等日志信息,用于以后的问题分析和解决。

Sysdig Cloud 是 sisdig 的 SaaS 版,除了基本的单机 sysdig 功能之外,还提供了跨平台跨基础设施的组件间依赖关系的可视化。

Librato

  • 数据聚合平台
  • 简单探针
  • 图表和报警
  • 价格不贵

Librato 是一个数据聚合平台,而不是严格意义的监控系统。

Librato 很容易从 AWS CloudWatch 和 Heroku 获得数据,如果是自己监控主机或者Docker,需要使用 Collectd 框架。它也有很多插件,可以从 StatsD、Riemann 等数据源采集数据。

Librato 的探针虽然功能不是强大,但是他提供了丰富的实时在线数据处理功能,用户可以使用 DSL 对任意时间序列数据组合进行数学运算,比如加减乘除、比率导数等。还支持和时间窗口滑动功能,即跟过去某一段时间进行比较。

Librato 也支持报警,基于 metric 和条件,设置报警信息。

Librato 是按照 metric 的个数和时间分辨率来收费的,在官网的主页上有一个大概的估算,如果你有 20 个 metric,并且时间间隔为 60 秒,则一台服务器的价格只有 2 美元 1 个月,这比 datadog 要便宜。

Axibase(ATSD)

  • 非开源TSDB
  • 支持报警
  • 预测功能

Docker 监控之 SaaS 解决方案 技术分享 第3张

作为 TSDB,ATSD 支持长时间存储高精度的 metric 数据。ATSD 支持多种数据采集工具和协议,比如 tcollector, Collectd,当然 ATSD 也支持从多台 Docker 主机手机指标数据,并长期保存,进行可视化和分析。

除了传统的时间序列数据,ATSD 还支持属性(Properties)和消息这两种类型的数据。属性一般用于保存 meta data,这有点类似标签。和 OpenTSDB 一样,ATSD 也支持 tag,我们可以使用这些 tag 进行过滤和聚合。

ATSD 内置了自动回归推断算法(holt-winters,arima),可以提早预测故障。预测功能的准确性取决于数据的采集频率,保存时间(也就是数据量大小)和算法。

最大的遗憾,就是 ATSD 并非开源,也不是免费的软件,不过他们提供了一个社区版可以免费使用,但是你只能在一个节点上安装 ATSD,而且不能用于盈利性服务,也不能对软件进行修改以及再发布。

如果我们只是评估一下,或者想自己构建监控方案,它的产品设计还是非常值得我们来借鉴一下。

SaaS 的挑战

数据敏感性

采用 SaaS,意味着你的数据都将会保存到公网,可能会带来心理不安全感。实际上 SaaS 反而会更安全些,尤其是对中小公司没有专门的安全运维团队的情况下。

成本(迁移和使用成本)

一般来说这是一个一次性投入成本。而对于大公司来说,就像公有云一样,成本可能会成为问题。

内部抵抗(观念、个人爱好)

来自技术人员自身的抵抗,不是每个人都喜欢自己变得轻松,使用 SaaS 可能会给一些人带来工作上的不充实感。

Docker 监控方案的发展趋势

标签机制

一种观点:监控服务状态胜过监控个别容器,通过 tag 机制对服务整体的性能指标进行聚合。

Tag 可以是任何维度,比如 BU,地区,服务,甚至个别容器。

比如 Docker 和 Kubernetes 等都支持 label 机制,即 tag 机制。

启动 Daemon:

docker daemon –label com.example.group=“webserver”

启动容器:

docker run –label com.example.group=“webserver”

Dockerfile:

LABEL com.example.group=“webserver”

通过 API 打通

通过 API 化实现共赢。开源软件比如 fluentd、Collectd 等,都支持插件功能。包括 Docker 本身,也在 1.11 版本中,采用了 runC 作为容器运行时,在上面通过 containerD 来统一控制,来支持符合 OCI 标准的容器。

Total 解决方案

包括从探针到展示、告警,就是现在类似 Datadog 和 Cloudinsight 这样的产品,以及支持中间件的详细程度,就像一个大市场,什么都能买到,不管你用什么软件,平台都能提供监控。

这就像是去了酒吧突然想吃碗拉面,然后竟然酒吧能给你做出来的那种感觉。

另一个层面就是从 RUEM(实时用户体验管理)到基础设施层的 打通 。比如你看到某 URL 的用户 HTTP 响应较慢,如果不能跟后端的 APM 打通,你尽管能识别出问题,但是你不知道如何解决。如果和后端的 APM 以及基础设施监控打通,你就能定位到 HTTP 响应慢时,相应的后端代码的位置,并根据后端代码的位置从而进一步找到 MySQL 的监控数据以及系统异常事件,立刻知道问题的根本原因所在并解决问题,可以说效率应该能提高几个数量级。

系统监控工具如果能够做到 All in One,真的对解决人力和时间成本上有非常大的帮助。

拓扑可视化

跨组件、跨基础设施和应用,自动识别组件以及组件之间的依赖关系,以帮助更好的发现问题和解决问题。

这类服务有:

  • Weave Scope
  • Ruxit
  • Sysdig

以上, 欢迎探讨技术问题。

K8S中文社区微信公众号
分享到:更多 ()