二进制部署promethues

news2024/9/23 13:26:35

1、定义：promethues是一个开源的系统监控以及报警系统，整合zabbix的功能（监控系统、网络、设备），promethues可以兼容网络、设备、容器监控、告警系统。因为其与k8s是一个项目基金开发出来的产品，天生匹配k8s的原生系统、容器化和云原生服务适配性很高

2、promethues是一个服务监控系统和时序数据库，提供了一个通用的数据模型和快捷数据采集、存储和接口查询

3、核心组件：promethues server，定期从静态配置的监控目标或者基于服务发现的自动配置目标中进行数据拉取，拉取的数据会持久化保存到存储设备中（先拉取数据纳入到监控系统中，才能进行时序数据采集、存储、告警和展示），能直接把api server作为服务发现系统使用，动态监控、动态发现

4、特点

（1）多维的数据模型。根据不同的函数计算方法，对同一数据可以做出不同的结论

（2）时间序列的数据。按照时间的顺序记录系统、设备变化的数据、容器化的数据，每个数据都是一个样本，服务器指标数据、应用程序的性能监控、网络数据都是时间序列数据

（3）通过静态配置或服务器自动发现收集数据

（4）promethues自带的原生数据展示不友好，通过数据化展示工具Grafana进行展示

5、存储引擎：TSDB

①TSDB能够存储的数据量很庞大

②大部分都是写入数据（从设备上获取数据，写入到promethues的存储库中）

③写入操作是一个时序添加，大多数情况下按照时间排列

④很少更新数据，采集到的数据在秒级/分钟级后就会被写入数据库

⑤基本数据大，一般超过内存的大小，数据按照一定的时间区间展示，缓存在这里不起作用

promethues是实时化数据，对持久化要求低

⑥读操作一般都是高并发的操作

⑦为了大数据高并发而生的

6、promethues的组件

（1）核心组件

①promethues server：服务核心组件，采用pull的方式采集监控数据，通过http协议进行传输、存储时间序列的数据，基于告警规则生成告警通知，所以promethues server是核心组件

• retrieval：负责在目标主机上抓取监控指标数据

• Storage：存储，把采集到的数据存储到磁盘中。默认保存15天，15天后自动清除

• PromQL：负责把数据按照一定的规则，通过指定的语法形成一个结果，由grafana展示出来

②exports：负责在节点收集数据，Node-Exports负责收集服务器节点的状态数据。CPU、内存、网络、磁盘等都是由Node-Exports收集，默认端口是9100

③client Library：客户端库，用于应用程序的内部测量系统，用于内部测试

④cadvisor：监控容器内部的资源信息。可选组件，但k8s1.20版本后自带此组件

⑤blackbox-exporter：监控业务容器的存活性（一般不用）

⑥Altermanager：独立的告警模块，从promethues server收到告警通知后，Altermanager进行重组、分类，再发送到对应的接收方（通过电子邮件、钉钉、企业微信等方式）

⑦pushgateway：类似于中转站，promethues server端只会pull的方式拉取数据，节点的数据只能以push的方式上传、发送，此时需要pushgateway，先把数据保存在pushgateway，promethues server统一从pushgateway拉取数据

⑧grafana：promethues的图形化工具。可选项

7、工作流程

第一步：promethues server收集和存储时间序列数据（从监控目标中通过pull方式拉取数据，或者从pushgateway中把采集到的数据拉取到server中）

第二步：拉取到的数据（监控指标数据）保存到本地磁盘中

第三步：若监控的指标数据触发告警，会发送到altermanager模块，根据规则发送告警信息

第四步：若不发送告警信息，只是查询信息，可以通过promethues自带的ui web页面promql查询出监控数据

第五步：因为promethues自带的展示页面不友好，Grafana可以接入promethues的数据源，把监控数据以图形化的方式展示出来

8、promethues的局限性

（1）promethues只是一款指标监控系统，不适合存储事件，也不适合保存日志，更多的是一种趋势性的监控和展示，并非是一个精准的数据

（2）promethues认为只有最近的数据才有查询的需要，保存在本地的数据默认只有15天，不支持大量的历史数据进行存储，也不支持过往的历史数据，若一定要保存，可以基于远端存储，上传到influxDB或openTSDB系统中

（3）promethues集群化成都不高，一般是单节点部署

9、promethues与zabbix的区别【面试】

（1）难度

zabbix：大而全系统，功能非常完善，机制也很成熟，并且具有完善的web页面和可视化以及告警。在界面上可以满足绝大部署的操作，难度低，可以快速掌握，但集成度太高，定制化较难，扩展性差

promethues：最近几年比较火的系统，基于go语言开发的，只专注于监控功能，提供一个简单的ui界面供用户查询，可视化由grafana，告警由altermanager这样的第三方程序来实现，比较小巧里灵活，但难度高

（2）功能

zabbix：server和agent，agent部署在目标服务器，数据传送到server，基于TCP协议进行通信，agent把数据推送到server，或者server主动发起请求获取agent数据

promethues：基于客户端进行数据收集，server端通过pull的方式获取监控数据，定时与客户端交互

（3）数据存储

zabbix：使用外部数据来保存数据

promethues：存储在内置的TSDB中（时间序列数据库）

（4）查询性能

zabbix：查询性能较弱，只能在web界面做一些有限的操作

promethues：查询性能较强，自带查询语句，但查询结果都是以图形或表格数据展示

结论：zabbix更成熟，难度低，对于传统的服务器、系统和网络都有优秀的监控能力，但不适配云原生、容器监控（可以监控，但适配性不好）；promethues就是容器监控，支持k8s的监控，难度高

二进制部署prometheus实验

1、安装prometheus——9090

scrape_interval: 15s	采集数据的间隔时间。默认1分钟
evaluation interval: 15s	告警间隔时间。默认1分钟
scrape timeout	数据采集的超时时间。默认10秒钟采集不到即超时
rules_files: -"first rules.yml" -"second rules .yml"	配置告警规则
scrape contigs	参数时序数据的源，配置采集的主机。静态、动态
- job name: "prometheus "	每一个监控实例都是以-job_name来表示监控的集合
metrics path defaults to '/metrics'	指标采集的默认路径
static configs:	静态配置发现实例（目标节点服务器）