目录
一、Prometheus概述
1、概念
2、核心组件prometheus server:
3、Prometheus的特点:
4、prometheus的存储引擎:TSDB
5、Prometheus组件:
6、Prometheus的工作流程:
7、Prometheus的局限性,以及和zabbix的对比:
二、实验:二进制部署Prometheus
三、总结:
一、Prometheus概述
1、概念
Prometheus:普罗米修斯,是一个开源的监控以及报警系统。整合zabbix的功能,系统,网络,设备。
Prometheus可以兼容网络,设备。容器监控,告警系统。因为他和K8S是一个项目基金开发的产品,天生匹配K8S的原生系统。容器化和云原生的服务适配性很高
Prometheus是一个服务监控系统和时序数据库,提供了一个通用的数据模型和快捷的数据采集,存储和接口查询
2、核心组件prometheus server:
定期从静态配置的监控目标和基于服务发现的自动配置目标中进行拉取数据
拉取到的数据会持久化的保存到存储设备中
先拉取数据,纳入到监控系统当中,才能进行时序数据的采集、存储、告警和展示
他能够直接把apiserver作为服务发现系统使用。可以动态监控和动态发现
3、Prometheus的特点:
- 多维的数据模型。根据不同的函数计算方法,对同一数据分析出不同的结论。promSQL语句是难点
- 是一个时间序列数据,按照时间的顺序记录系统,已经设备变化的数据,容器化的数据。每个数据都是一个样本。服务器指标数据、应用程序的性能监控、网络数据都是一个时间序列数据
- 可以通过静态,也可以通过服务自动发现收集数据
- Prometheus自带的原生数据展示不是很优化,有专门为他数据展示的工具,Grafana
4、prometheus的存储引擎:TSDB
- 能够存储的数据量很庞大
- 大部分都是写入操作
- 写入操作时一个时序性添加,大多数情况下都是按照时间排列
- 很少更新数据,采集到的数据在秒级或者分钟级就会被写入数据库
- 基本数据大,一般超过了内存大小。数据按照一定的时间区间展示,缓存在这里不起作用
- 读操作,一般都是高并发的操作。
- 就是为了大数据、高并发而生的
5、Prometheus组件:
核心组件:
服务核心组件,采用的是pull方式采集监控数据,通过http协议进行传输,存储时间序列的数据。基于告警规则生成告警通知
1、Prometheus server
是核心组件
核心分为三部分:
1)、retrieval:负责在目标主机抓取监控指标数据
2)、storage:存储,把采集到到的数据保存到磁盘中,默认是保存15天
3)、PromQL:计算展示。负责把数据按照一定的规则,通过指定的语法展示出来,形成一个结果,最后展示出来(grafana)
2、exports
负责在节点收集数据,Node-Exports服务收集服务器节点的状态数据,CPU、内存、网络、磁盘等等都是他收集。默认端口9100
3、client library
客户端库,用于应用程序的内部测量系统。内部测试
4、cadvisor
监控容器内部的资源信息,但是K8S从1.20之后自带这部分组件
5、blackbox-exporter
监控业务容器的存活性
6、Altermanager:
独立的告警莫夸,从Prometheus server收到告警通知之后,Altermanager进行重组、分类、发送到对应的接收方,电子邮件、钉钉、企业微信
7、pushgateway:类似于一个中转站,server端只会使用pull的方式拉取数据,节点的数据只能以上传(push)的方式发送,pushgateway,先把数据保存到pushgateway,Prometheus server统一从pushgateway拉取数据
8、Grafana:
图形化工具
6、Prometheus的工作流程:
- Prometheus server,为核心,收集和存储数据(时间序列数据),从监控目标中通过pull方式拉取数据。或者通过pushgateway把采集到的数据,拉取到server当中
- 拉取到的数据(监控指标数据),保存到本地的磁盘当中。
- 如果监控的指标数据触发了告警,发送到Altermanager模块,然后根据规则发送告警信息
- 通过Prometheus的自带uiweb页面,通过他的promQl可以查询出监控数据
- Grafana可以介入Prometheus的数据源,把监控数据以集群化的方式展示出来
7、Prometheus的局限性,以及和zabbix的对比:
Prometheus:
1、Prometheus只是一款指标监控系统,不适合存储时间,也不适合保存日志,更多的是一种趋势性的监控和展示。并非是一个精准的数据
2、Prometheus认为最近的监控数据才有查询的需要,保存在本地的数据默认只有15天,不支持大量的历史数据进行存储。也不支持查询过往的历史数据。基于源端存储,上传到influxDB或者openTSDB系统。
3、Prometheus集群化程度不高,一般都是单节点部署
zabbix:
大而全的系统,而且功能非常完善,机制非常成熟。具有完善的web页面。可视化和告警。在zabbix界面上可以完成绝大多数的操作,上手的难度很低,可以快速掌握。
他的集成度太高,定制化比较难,扩展比较差
Prometheus:
最近几年比较火的监控系统,基于go语言开发的。
他只是专注于监控的功能,提供一个简单的UI界面供用户查询。
可视化是Grafana提供,告警是Altermanager提供,第三方来实现
Prometheus比较小巧灵活,但是门槛高
二者之间功能的比较:
指标收集方式:
zabbix:基于server和agent,agent部署在目标服务器,数据传送到server,基于tcp协议进行通信。agent把数据推送到server,或者是server主动发起请求获取客户端agent数据
Prometheus:基于客户单进行数据收集,server会定时与客户端交互,通过pull方式获取监控数据
数据存储:
zabbix:使用外部的数据库来保存数据(mysql)
Prometheus:存储在内置的TSDB当中,时间序列数据库
查询性能:
zabbix:zabbix的查询性能较弱,只能在web界面做一些有限的操作
Prometheus:查询功能强大,自带查询语句。查询结果都是以图形或者表格数据展示的
总的来说,zabbix更成熟,上手难度低,对于传统的服务器,系统和网络都有优秀的监控能力。但是他不适配云原生,不适配容器监控
而Prometheus就是容器化监控,支持K8S的监控功能。但是难,promQL不好学
二、实验:二进制部署Prometheus
上传prometheus-2.45.0.linux-amd64.tar.gz
mkdir -p /opt/prometheus
cd /opt/prometheus
tar xf prometheus-2.35.0.linux-amd64.tar.gz
mv prometheus-2.35.0.linux-amd64 /usr/local/prometheus
scrape_interval: 15s
#采集数据的间隔时间,15秒采集一次。默认1分钟
evaluation_interval: 15s
#告警的间隔时间,15秒告警一次。默认1分钟
scrape_timeout:
#数据采集的超时时间,默认10s
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
#配置告警的规则
scrape_configs:
#采集时序数据的源,配置采集的主机。静态、动态两种方式
- job_name: "prometheus"
#每一个监控实例都是以-job_name来表示整体的集合
metrics_path defaults to '/metrics'
#指标数采集的默认路径
static_configs:
#静态配置发现实例(目标节点服务器)
将Prometheus加入到系统服务
vim /usr/lib/systemd/system/prometheus.service
[Unit]
Description=node_exporter
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/node_exporter \
--collector.ntp \
--collector.mountstats \
--collector.systemd \
--collector.tcpstat
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
[Install]
WantedBy=multi-user.target
时间同步做一下,web访问Prometheus页面
yum -y install ntpdate.x86_64
ntpdate ntp.aliyun.com
静态配置(手动添加)加入node节点:
所有节点上上传node_export,安装配置
mdkir -p /opt/prometheus
cd /opt/prometheus
tar xf node_exporter-1.5.0.linux-amd64.tar.gz
mv node_exporter-1.5.0.linux-amd64.tar.gz/node_exporter /usr/local/bin
将 node_exporter添加到系统服务中
vim /usr/lib/systemd/system/node_exporter.service
[Unit]
Description=node_exporter
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/node_exporter \
--collector.ntp \
--collector.mountstats \
--collector.systemd \
--collector.tcpstat
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
[Install]
WantedBy=multi-user.target
看端口起没起:9100
在master的Prometheus上配置节点
vim prometheus.yml
前端访问
http://20.0.0.61:9090/
安装可视化工具Grafana
安装在master上就可以
rpm -ivh grafana-enterprise-7.5.11-1.x86_64.rpm
http://20.0.0.61:3000/
账号和密码都是admin
关联集群成功
添加监控模版
https://grafana.com/grafana/dashboards
模版网站。找模版,填写模版id
几个常用的模版id:12633、11074、15172
三、总结:
Prometheus就是一个时序数列的图形化监控工具。他不在意数据的持久化,只关注最近的需要查询的数据
更适配K8S集群,当然了,也可以对服务器进行一般监控(内存、CPU、硬盘,网络)
CPU负载:什么原因,什么时间点形成报告,一段时间不降,向上级部门报告
每天记录,每周算平均值
数据要复现,每天都会出现某种情况,占了大量的CPU、内存,这个需要关注
但是不是复现的情况,可以不管,某时限突然增高,但是可以下降,如无特殊需求,可以不用管,但是要记录下来
基本上来说,不是复现的数据,可以不管,但是要记录