【prometheus】学习第一篇——prometheus
前言:
说到监控方案,市面上开源的有很多,最常用的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的查询语法见官方文档吧,写的比较全。
这一篇就到这里,下一篇讲一下告警的配置。