根据一篇不错的文章: ” 容器领域的十大监控系统对比 ” 列出的流行监控方案
| 方案 | 备注 | |
|---|---|---|
| 1 | DOCKER STATS | 原生命令行工具 |
| 2 | CADVISOR | 通常作为信息采集组件 |
| 3 | SCOUT | 付费云服务 |
| 4 | PINGDOM | 付费云服务 |
| 5 | DATADOG | 付费云服务 |
| 6 | SYSDIG | 付费云服务 |
| 7 | PROMETHEUS | 数据收集、告警 |
| 8 | HEAPSTER | Kuberenets only |
| 9 | ELK STACK | 日志分析，监控的一环 |
| 10 | SENSU | 没有容器化，部署麻烦，免费版功能不强 |
更加确定了我们目前试用的以Prometheus为核心的方案。筛选的过程很简单，撇除掉商业付费的方案，
- Docker stats 只是一个命令行接口，称不上方案，可能会被其他采集工具调用
- CAdvisor 目前我们作为数据采集的重要组件
- Prometheus 目前监控方案的核心
- ELK 目前还没用起来，可作为Granfana数据源，分析日志触发面板上的预警
目前试用的方案来源于github上的一份参考 bvis/docker-prometheus-swarm
从他的容器编排可以看到整体方案是
- 采集器
- CAdvisor
- Node exporter (promethues 组件一部分)
- docker exporter (转发容器原生API信息)
- 数据库
- Prometheus
- 报警器
- to slack (国内用不了)
- to logstash （没用起来）
- ELK （没用起来）
- elasticsearch
- logstash
- kibana
最后结合一个Granfana模板的呈现就是这里 docker-swarm-and-container-overview
其中顶部 Errors，Alert Fired， Alert Resolved是要配置Elasticsearch数据源使用的，目前还没有。
数据库曾经试过我们熟悉的InfluxDB，配合CAdvisor做数据采集使用，但是发现Prometheus的指标查询更有可定制性和弹性。使用InfluxDB时一旦容器变动，需要频繁手动调整Granfana中的查询语句。这样的问题在Prometheus中不是问题。只是Prometheus的查询语言PromQL比InfluxQL略复杂。
文中很多部分提到 Rancher 通过插件等方式整合CAdvisor， Promethues 等组件。Rancher 是否适合Swarm集群，整合的方式是否好用，还需要研究Rancher后再看。
update: 2018-04-10
Rancher 的调研写在Wiki里：Rancher应用于swarm集群管理的调研
Comments
comments powered by Disqus