（一）Prometheus的相关概念
1、Prometheus：是一个开源的系统监控以及报警系统，整合zabbix的功能、系统、网络、设备
2、Prometheus可以兼容网络、设备，进行容器监控、告警系统
3、因为Prometheus和k8s是一个项目基金开发的产品，天生匹配k8s的原生系统，容器化和云原生服务适配性很高
4、Prometheus是一个服务监控系统和时序数据库，提供了通用的数据模型和快捷数据采集，存储和接口查询
（1）核心组件：Prometheus server，定期从静态配置的监控目标或者基于服务发现的自动配置目标中进行拉取数据，拉取到数据会持久化的保存到存储设备之中
①先拉取数据，纳入到监控系统当中，才能进行时序数据采集、存储、告警和展示
②能够直接把apiserver作为服务发现系统使用，实现动态监控、动态发现
5、Prometheus的特点
（1）多维的数据模型：根据不同的函数计算方法，对同一数据可以作为不同的结论
①promQL是难点
（2）时间序列的数据：按照时间的顺序记录系统，设备变化的数据、容器化的数据，每个数据都是一个样本
①服务器指标数据、应用程序的性能监控、网络数据都是时间序列数据
（3）通过静态，也可以通过服务自动发现收集数据
（4）Prometheus自带的原生数据展示不是很友好，专门的数据化展示工具grafana
6、Prometheus的存储引擎：TSDB
（1）能够存储的数据量很庞大
（2）大部分都是写入操作
（3）写入操作是一个时序添加，大多数情况下都是按照时间排列
（4）很少更新数据，采集到的数据在秒级或者是分钟级后就会被写入数据库
（5）基本数据大，一般超过了内存的大小，数据按照一定的时间区间展示，缓存在这里不起作用
①Prometheus展示实时数据，对持久化要求不是很高
（6）读操作，一般都是高并发的操作
（7）就是为了大数据高并发而生的
7、Prometheus的组件
| * 服务核心组件，采用pull方式采集监控数据，通过http协议进行传输，存储时间序列的数据，基于告警规则生成告警通知 | ||||
| Prometheus server | 核心组件，核心分为三个部分 | |||
| retrieval | 负责在目标主机抓取监控指标数据 | |||
| storage | 存储，把采集的数据保存在磁盘当中，默认只保存15天 | |||
| promQL | 负责把数据按照一定的规则，通过指定的语法形成结果，最后展示出来grafana | |||
| exports | 负责在节点收集数据 node-exports负责收集服务器节点的状态数据、CPU、内存、网络、磁盘等等都是其收集 默认端口：9100 | |||
| client-library | 客户端库，用于应用程序的内部测量系统，内部测试 | |||
| cadvisor | 监控容器内部的资源信息，但是k8s从1.20之后自带这个组件 | |||
| blackbox-exporter | 监控业务容器的存活性（一般不用） | |||
| altermanager | 独立的告警模块，从Prometheus server收到告警通知之后，从altermanager进行重组、分类，发送到对应的接受方 电子邮件、钉钉、企业微信 | |||
| pushgateway | 类似于一个中转站，server端只会使用pull的方式拉取数据，节点的数据只能以push的方式上传，先把数据源保存在pushgateway，Prometheus server统一从pushgateway拉取数据 | |||
| grafana | 图形化工具 | |||
8、Prometheus的工作流程
（1）Prometheus server为核心，收集和存储数据（时间序列数据），从监控目标中通过pull方式拉取数据，或者通过pushgateway把采集到的数据，拉取到server当中
（2）拉取到的数据保存到本地的磁盘当中（监控指标数据）
（3）如果监控的指标数据触发了告警，发送到altermanager模块，然后根据规则发送告警信息
（4）通过Prometheus的自带UI的web页面，通过promQL可以查询出监控的数据
（5）grafana可以介入Prometheus数据源，把监控数据以图形化的方式展示出来
9、Prometheus的局限
（1）只是一款指标监控系统，不适合存储时间、也不适合保存日志，更多的是一种趋势性的监控和展示，并非是一个精准的数据
（2）认为只有最近的数据才有查询的需要，保存在本地的数据默认只有15天，不支持大量的历史数据进行存储，也不支持查询过往的历史数据。基于远端存储，上传到influxDB或者openTSDB系统
（3）集群化程度不高，一般都是单节点部署
10、Prometheus和zabbix的对比（重）
| zabbix | Prometheus | |
| 特性 | ①优点：大而全的系统，而且功能非常完善，机制非常成熟，具有完善的web页面，可视化和告警，在界面可以满足绝大部分的操作，上手难度很低可以快速掌握 ②缺点：高度集成导致其定制比较难，扩展也比较差 | ①优点：近几年比较火的监控系统，基于go语言开发的，只是专注于监控的功能，提供一个简单的UI界面供用户查询，可视化——grafana——altermanager，第三方程序实现，比较小巧灵活 ②缺点：自带promQL语言，门槛高，学习难度大，上手难 |
| 功能 | ||
| 指标收集方式 | ①zabbix：指标收集方式：server、agent ②agent：部署在目标服务器，数据传送到server，基于tcp协议进行通信 ③agent把数据推送到server，或者server主动发起请求，获取agent的数据 | ①基于客户端进行数据收集，server端定时与客户端交互，通过pull的方式获取监控数据 |
| 查询性能 | ①查询的性能较弱，只能在web界面进行一些有限的操作 | ②查询功能强大，自带查询语句，查询结果都是以图形、表格数据展示 |
| zabbix更成熟，上手难度低，对于传统的服务器、系统和网络都有优秀的监控能力，不适配云原生、不适配容器监控 | ||
| Prometheus就是容器化监控，支持k8s的监控功能，查询语句难、不好学 | ||
（二）Prometheus基于二进制部署
1、部署压缩包
①配置文件的格式：cat prometheus.yml | grep -v "^#"
2、添加到系统服务：vim /usr/lib/systemd/system/prometheus.service
systemctl daemon-reload
systemctl restart prometheus.service
systemctl enable prometheus.service
3、访问：20.0.0.71:9090
4、配置时间同步
5、加入node节点（配置所有节点）
tar -xf node_exporter-1.5.0.linux-amd64.tar.gz
mv node_exporter-1.5.0.linux-amd64 node_exporter
mv node_exporter /usr/local/bin/
①添加至系统服务：vim /usr/lib/systemd/system/node_exporter.service
②查看端口：netstat -antp | grep 9100
③静态方式添加指定节点
6、配置grafana（配置在一个节点即可）
rpm -ivh grafana-enterprise-7.5.11-1.x86_64.rpm
systemctl start grafana-server.service
systemctl enable grafana-server.service
netstat -antp | grep 3000
①访问：http://20.0.0.71:3000/
7、网页配置
（1）下载模版：https://grafana.com/grafana/dashboards
（2）删除模版
