与zabbix区别
都喜欢用prometheus于zabbix作对比,其实这两个互有优劣,没有谁可以完全替代谁的。prometheus一下子火起来的原因还是因为对k8s与公有云的集成,可以快速发现弹性节点与内部资源的监控。恰恰现在这两个东西火的不行。
zabbix也可以做到,但是效率没得比。这与它的年代相关,设计模式就是这样。但它也还在发展不是么。而且这只是云相关的监控。
下面prometheus的报警部分是通过alertmanager, 但整体还是prometheus的一部分, 所以都写成prometheus了。
1、监控资源的类型
prometheus更适合监控上层的资源,如k8s, 可以通过访问k8s的接口发现节点,容器,k8s内部资源。公有云也是一样。而且prometheus只支持http协议,也只能通过访问接口的方式获取监控数据。
zabbix 支持各种底层协议,可以监控物理硬件,如网络设备,服务器硬件状态。
它们两个都可以通过其他方式实现监控,prometheus可以通过exporter,zabbix可以自定义监控, 但算起来就是效率的问题了。
2、配置方式的不同
prometheus无论是监控、报警、信息模板都是通过配置文件实现的,特别是信息模板还是go模板。
zabbix配置都是通过web页面实现,而且还有用户管理功能。而且zabbix这么多年已经有很多可以直接套用的监控模板。
3、报警介质
prometheus 报警介质暂时只支持微信,邮件,第三方插件实现的钉钉, 还有国外使用的一些报警介质。
zabbix 一般都是通过添加报警介质为脚本的方式自定义各种报警方式,比如一般使用的,微信,短信,电话。
4、报警方式
prometheus 支持信息分组,抑制,静默。 通过相同的规则写不同的for也可以实现步骤发给不同的人。不支持用户分组的功能,不能一次性给一组用户发送。
zabbix 也支持抑制,静默,步骤。 但不支持信息分组功能。支持用户分组,可以给一组人发送。
5、监控机制
prometheus通过访问metric接口, 这就是文本一个网页,里面包含很多监控样本。 一次访问就可以获取大量的样本数据。可以说在prometheus里面已经没有监控项的概念了,有的只是数据,报警规则的计算就是直接在一堆数据里执行查询就完事了。
zabbix 的监控项的获取都是一对一的关系,以此获取一个监控项数据。虽然也可以通过zabbix 收集器
的监控类型,由节点一次推送大量数据, 但是使用起来没有这么便捷, 而且也是与监控项一对一的关系。报警规则也是与监控项绑定的。
6、数据存储
prometheus 默认使用自己的时序数据库TSDB在本地存储,存储时间默认15天。如果想长时间存储需要接外部数据库,如infuxdb。
zabbix 使用mysql, 因为是关系型数据库,存储时间也不能太长,数据量太大会导致查询和报警延迟,需要做分表或定期删除重建一下历史表。
7、自动发现
prometheus 没有单独发现节点的方式,需要通过上层服务来发现,如k8s。但是还可以发现k8s里的各种资源。总之,通过其他服务接口来发现节点与资源监控。
zabbix 使用fping发现节点,以及使用自动发现来发现监控项,并且可以对自动发现的不同监控项自动添加不同的报警规则,如不同主机的磁盘分区不同。 不依赖其他服务。也可以自定义监控项来发现k8s里的东西,但就算发现了也监控不了,就算可以监控也是很费劲。
8、展示
prometheus 也有自己的web页面,主要是用来测试promQL,简单查看出发的报警以及监控的目标。需要使用grafana或kibana来展示详细的数据图表。
zabbix 有自己的web页面,有些汇总图也需要grafana或kibana来展示。
总结一下就是: 无关优劣,各取所需。
组件
中间的prometheus server 就是prometheus主体。
pushgateway
:
我们知道prometheus是通过http接口访问来获取数据, 但是想获取一个脚本的执行结果或就是一个计划任务怎么办, 执行完了就退出了。 根本没有提供http接口。 pushgateway就是用来干这个的,脚本执行完把结果发给pushgateway, prometheus从pushgateway获取就可以了。
prometheus targets
:
就是监控的目标,可以使你的服务,也可以是exporters,都要提供http接口。
exporters
:
有些服务提供不了http接口, 如: mysql, redis等, 就有了exporters。 来获取数据并提供http接口。
alertmanager
:
prometheus 的报警组件,prometheus发现符合报警规则的都会push到alertmanager。 alertmanager在根据一系列机制来决定如何发送报警。
PromQL
:
prometheus 的数据查询语言,使用很便捷。 查询数据,报警规则,grafana,都是通过PromQL来获取数据。
监控数据的组成
[root@k8s-op prometheus]# curl http://172.100.101.196:9090/metrics
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 5.1137e-05
go_gc_duration_seconds{quantile="0.25"} 9.3217e-05
go_gc_duration_seconds{quantile="0.5"} 0.000118911
go_gc_duration_seconds{quantile="0.75"} 0.000168187
go_gc_duration_seconds{quantile="1"} 0.008098125
go_gc_duration_seconds_sum 0.951585627
go_gc_duration_seconds_count 3549
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 183
# HELP go_info Information about the Go environment.
# TYPE go_info gauge
go_info{version="go1.13.4"} 1
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
# TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 1.798002288e+09
# HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.
# TYPE go_memstats_alloc_bytes_total counter
go_memstats_alloc_bytes_total 8.27826165056e+11
上面有五组监控数据, 每一组都有两个注释和监控指标组成。
那两个注释,第一个是描述类信息,第二个是 指标的名称以及类型。
比如第一组,名称就是go_gc_duration_seconds
, 类型是 summary
。 如果说下面还有go_gc_duration_seconds_sum
和go_gc_duration_seconds_count
, 这就与类型有关系了。
第二组,名称是go_goroutines
, 类型是 gauge
。
每组监控里的每个样本都是由 <metrics_name>{<label_name>=<label_value>....}组成。
监控数据的类型(metrics type)
其实在prometheus存储里也没有类型,不清楚这类型的具体作用。暂时当做注释来看了。
其实说到底,就是一些样本数据,类型好像就是把这些样本的功能给区分了。
Counter
:
计数器,是只增不减的类型。
比如cpu使用时长,这个是只增不减的,可以获取运行的时长,也可以通过增长率计算现在的使用情况。一般都使用_total作为后缀。这个是提供监控数据的服务自身做的计数,prometheus不会计数,它只是存储下来。
Gauge
:
表示当前状态,该是多少就是多少,可大可小。 比如当前进程数,内存可用空间。
summary与histogram都是用来表达过程,整个指标都为了说明同一个问题。
Summary
:
采样点分布图统计,由多个样本数据组成,描述一些数据分布的情况。 比如上面的go_gc_duration_seconds
,多个样本数据用来说明go gc耗时的分布情况,go_gc_duration_seconds_sum
说明一共耗时,go_gc_duration_seconds_count
说明gc的次数, 其中有25%(quantile="0.25")的gc,时间小于9.3217e-05; 50%的小于0.000118911; 100%的都小于0.008098125。
这个指标就可以把gc耗时给完整表达出来。
这个类型就是把一些样本给统计起来,为了分析指标的百分比状态。
Histogram
:
跟summary差不多,summary统计的是有百分多少小于后面的值。 而histogram统计的是小于指定的值有多少个。 比如,把go_gc那个改一下:
go_gc_duration_seconds{le="5.1137e-05"} 0
go_gc_duration_seconds{le="9.3217e-05"} 887
go_gc_duration_seconds{le="0.000118911"} 1774
go_gc_duration_seconds{le="0.000168187"} 2661
go_gc_duration_seconds{le="0.008098125"} 3549
go_gc_duration_seconds_sum 0.951585627
go_gc_duration_seconds_count 3549
变成了小于le时间的有多少个。
这个时间单位就看提供这个样本数据的服务了, 这里这个应该是秒。
安装
下载页面:
https://prometheus.io/download/
第三方exporter:
https://prometheus.io/docs/instrumenting/exporters/
这个安装太简单了, 直接下载解压,启动就行了。比如:
prometheus --config.file=prometheus.yml
而alertmanager也是这样:
alertmanager --config.file=alertmanager.yml
加一个简单的unit启动:
[Unit]
Description=prometheus
[Service]
Type=simple
ExecStart=/usr/local/prometheus/prometheus \
--config.file=/usr/local/prometheus/prometheus.yml \
--web.enable-lifecycle \
--storage.tsdb.path=/usr/local/prometheus/data
RestartSec=2
Restart=always
[Install]
WantedBy=multi-user.target
[Unit]
Description=prometheus
[Service]
Type=simple
ExecStart=/usr/local/alertmanager/alertmanager \
--config.file=/usr/local/alertmanager/alertmanager.yml \
--storage.path=/usr/local/alertmanager/data
RestartSec=2
Restart=always
[Install]
WantedBy=multi-user.target
测试配置文件是否可用:
[root@k8s-op prometheus]# ./promtool check config prometheus.yml
Checking prometheus.yml
SUCCESS: 1 rule files found
Checking rules/test.yml
SUCCESS: 3 rules found
[root@k8s-op alertmanager]# ./amtool check-config alertmanager.yml
Checking 'alertmanager.yml' SUCCESS
Found:
- global config
- route
- 1 inhibit rules
- 3 receivers
- 0 templates
至于详细的配置,可以看这里:
https://www.yxingxing.net/archives/prometheus-20191206-config