前言：
说到监控方案，市面上开源的有很多，最常用的zabbix，深入使用zabbix以后，才知道zabbix设计团队有多厉害，简直是一个完美的监控告警方案。但是在针对docker的监控上还差点，需要自己写监控脚本实现。为此从去年开始调研针对docker的监控方案，如下：
1，cadvisor+influxdb+grafana
优点：部署方便，cadvisor监控docker主机和docker信息，influxdb记录数据，grafana展示
缺点：1，无法获取cpu使用率，cadvisor采集到的是cpu使用时间，得到cpu使用率需要计算，grafana没有办法做复杂的运算。
2，告警体系几乎没有，grafana有基本的告警功能，仅限于图表类型数据可以告警，并且没有告警收敛、告警分析的功能，存在告警风暴的风险。
3，influxdb开源版本不支持集群，商业版才支持集群。这个对后续扩展是个问题。
2，Weave Scope
优点：简直完美的监控，界面漂亮，操作方便，自带终端堡垒机功能。
缺点：1，他的优点也是他的缺点，权限这么大的终端（root用户），居然没有认证体系，任何人拿到ip就能对服务器做任何操作了
2，总体感觉这个方案是给人看的，不太适合做监控系统，界面花哨，但是实际使用并不方便。
3，influxdb+telegraf+kapacitor+chronograf
优点：influxdb提供的全套方案，看着很完美
缺点：我尝试了十几次，没有一次能够把全流程跑通，主要是卡在kapacitor上，这个是实时处理模块，可惜一直无法告警，不知道是不是产品的bug。
4，自己开发的docker监控方案
https://github.com/zhenglisai/docker-monitor
优点：完全自己控制，什么都能够拿到，想拿什么数据拿什么数据
缺点：agent的cpu占用率巨高。。。实际跑起来，单单监控程序就占用了45%的cpu，这个肯定不能接受，个人水平有限，python程序优化以后，也是这样，不清楚是python本身效率低的问题，还是我采集数据的方式不合理，暂时放弃了。
5，最后prometheus方案
优点：全套的监控，丰富的插件
缺点：没有认证！！！prometheus官方文档也是写的，他们专注于监控，不提供用户认证体系。需要的话，需要自己在最外层包一层nginx实现反向代理认证。
背景说明
docker监控方案来来回回折腾了半年，各个方案都试过了，没有一个特别完美的，prometheuse+grafana这个方案，也是用了放弃，放弃以后没有更好的，又拿回来用，来来回回了四五次。后来在开发trigger-action系统的时候，再一次深入调研了prometheus，才发现，原来prometheus这么强大，不愧是谷歌推荐的监控方案（在《SRE google运维解密》这本书中，多次提到prometheus，说是谷歌监控体系的开源版）。
举一个例子来说明一下：
比如统计和监控一个api接口的平均响应时长有没有意义？我们之前的监控系统就是监控这个指标，来判断api是不是健康。后来发现这个指标基本没什么用，有用的是响应时长分布，比如90%的请求响应时长小于30ms，1%的请求响应时长大于1s，那么这个api可以认证基本正常。但是从平均响应时长来看，可能平均100ms，这个平均值不能真实反映api的请求情况。这一点，prometheus可以做到。
正式开始：
【安装篇】
什么都不如官方文档详细，如果你的英语够好，建议直接去看官方文档就行了：https://prometheus.io/docs/introduction/overview/
1，prometheus是go语言写的，多个平台有很好的移植性，并且基本不依赖其他环境，官网下载下来直接运行就行了，不详细说了
https://prometheus.io/download/
【配置篇】
重点说明配置，Prometheus与zabbix最大的不同，是什么都需要通过配置文件来实现，上手难度比zabbix大。
主配置文件：prometheus.yml
让我们看看这个文件有什么：
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets: ['127.0.0.1:9093']
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
- "test.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['0.0.0.0:9090']
- job_name: 'node'
file_sd_configs:
- files: ['/root/prometheus/prometheus/discovery.json']咱们这一篇主要讲一下scrape_configs这一部分，这一部分实现添加监控主机功能。
prometheus采用pull的模式，server端从agent拉取指标，所以agent什么都不需要配置，等待server来拉取数据就行了。
Prometheus添加监控主机有两大类方式：1，写死在配置文件里，每次添加主机，都编写Prometheus.yml文件，然后kill -1 prometheus的pid重新加载配置文件，这种方案用起来很不方便，尤其是主机多了以后。2，自动发现，支持多种发现规则。这里我们采用基于file的自动发现。
static_configs:这一部分就是写死在配置文件里的主机，每次添加主机都可以添加在这里，job_name的意思其实是一个可以筛选的标签，可以认为是分组。
file_sd_configs是基于文件的自动发现，Prometheus会从/root/prometheus/prometheus/discovery.json这个文件中读取主机信息，官方文档说只要更新这个文件就行了，Prometheus会监控这个文件的变化来自动更新，但是在实际使用中，感觉不太好用，还是手动给server进程发送Kill -1信号吧。
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['0.0.0.0:9090']
- job_name: 'node'
file_sd_configs:
- files: ['/root/prometheus/prometheus/discovery.json']
/root/prometheus/prometheus/discovery.json文件内容如下：
[
{
"targets": ["192.168.1.118:9100"],
"labels": {"server_name":"promethues-agent","region":"cn-north-1"}
},
{
"targets": ["192.168.1.118:8080"],
"labels": {"server_name":"docker-agent","region":"cn-north-1"}
}
]可以自己写一个api程序，比如写一个python的api，调用这个api，程序会自动更新这个文件，并重启Prometheus进程，来实现更新监控主机。
在监控主机上运行node_exporter这个程序，也是不需要任何配置，直接运行就行了。
这样访问prometheus服务器的9090端口，就可以看到监控的服务器和监控指标了。
prometheus的查询语法见官方文档吧，写的比较全。
这一篇就到这里，下一篇讲一下告警的配置。
来源：oschina
链接：https://my.oschina.net/u/4366836/blog/3938504