什么是Prometheus？

Prometheus是一个开源的系统监控以及报警系统。整和zabbix的功能，系统，网络，设备。

promethues可以兼容网络、设备、容器监控、告警系统。因为和k8s是一个项目基金开发的产品，天生就匹配k8s的原生系统。容器化和云原生服务适配性很高。

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

核心组件：Prometheus server 定期从静态配置的监控目标或者基于服务发现的自动配置目标中进行拉取数据。拉取到数据会持久化的保存到存储设备之中。

Prometheus会先拉取数据纳入到监控系统当中，才能进行时序数据采集、存储、告警和展示

基于pod部署的Prometheus能够直接把api sever作为服务发现系统使用。可以实现动态监控，动态发现。

Prometheus的特点

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

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

3. 通过静态，也可以通过 服务自动发现收集数据

4. Prometheus自带的原生数据展示不是很友好，有专门为他匹配的数据化展示工具。grafana

Prometheus的存储引擎

Prometheus使用的存储引擎是TSDB

TSDB的特点

1. 能够存储的数据量很庞大

2. 大部分时间都是写入操作，读不多。只是从获取数据，将数据写入数据库当中。

3. 写入操作是时序添加。大多数情况下都是按照时间排列

4. 很少更新数据，采集到的数据在秒级或分钟级之后写入数据库

5. 基本数据大。一般超过了内存的大小。数据按照一定时间区间展示，缓存在这里不起作用。由于展示实时数据，所以对持久化要求不高。

6. 读操作，一般都是高并发的操作。

7. 就是为了大数据、高并发而生的。

Prometheus的组件

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，Prometheus server同一从pushgateway拉取数据

8、 grafana 图形化工具

Prometheus的工作流程

1. Prometheus server为核心，收集和存储数据(时间序列数据)，从监控目标中通过pull的方式拉取数据，或者通过pushgateway把采集到的数据，拉取到server当中。

2. 拉渠道的数据，将监控指标数据保存到本地磁盘当中。

3. 如果监控的指标数据触发了告警，发送到altermanager

4. 通过Prometheus自带的uiweb界面，通过promql可以查询到监控用户数据

5. grafana可以介入Prometheus的数据源。把监控数据以图形化的方式展示出来

Prometheus的局限性以及和zabbix的对比

Prometheus的局限性

1. Prometheus只是一款指标监控系统，不适合存储时间，也不适合保存日志。更多的是一种趋势性的监控和展示。并非是一个精准的数据。

2. Prometheus认为只有最近的数据才有查询的需要，保存在本地的数据默认只有15天，不支持大量的历史数据进行存储，也不支持查询过往的历史数据。基于远端存储，上传到influxDB或者是openTSDB系统

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

Prometheus和zabbix的区别

zabbix：

1. zabbix是大而全的系统，而且功能非常完善，机制非常成熟。

2. 具有完善的web页面，可视化和告警。在页面上可以满足绝大部分的操作。

3. 上手难度比较低，可以快速掌握

4. 由于集成度太高，定制化比较困难。而且扩展性也比较差。

Prometheus：

1. Prometheus是近几年比较火的监控系统，基于go语言开发。只是专注于监控的功能，提供一个简单的ui界面供用户查询

2. grafana提供可视化。Altermanager提供告警。通过第三方程序实现

3. 比较小巧灵活。但是门槛较高，上手比较难

zabbix和Prometheus功能比较

zabibx指标收集方式：

1. 通过server和agent收集

2. agent部署在目标服务器，数据推送到server，基于tcp进行通信

3. agent把数据推送到server，或者是server主动发送请求获取agent的数据

Prometheus指标收集方式：

1. Prometheus也是基于客户端进行数据收集，server端定时与客户端交互，通过pull的方式获取监控数据。

数据存储

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

Prometheus存储在内置的TSDB当中，时间序列数据库中

查询性能

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

Prometheus查询功能强大。Prometheus自带查询语句，查询结果都是以图形或表格数据展示。

zabbix更成熟，上手难度低，对于传统的服务器、系统和网络都有优秀的监控能力，zabbix不适配云原生，不适配容器监控。

Prometheus就是容器化的监控，支持k8s的监控功能，promQL上手难度高。

二进制部署Prometheus

master01  20.0.0.32
node01  20.0.0.34
node02  20.0.0.35

master01
tar -xf prometheus-2.45.0.linux-amd64.tar.gz
mv prometheus-2.45.0.linux-amd64 prometheus
cd prometheus
cat prometheus.yaml | grep -v "^#"
#查看他的配置文件
scrape_interval: 15s
#采集数据的间隔时间，默认是1分钟
evaluation_interval: 15s
#告警的间隔时间，默认1分钟
scrape_timeout: 10s
#数据采集的超时时间，默认10s
alerting
#告警的实例配置

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:
#静态配置发现实例(目标节点服务器)

vim /usr/lib/systemd/system/prometheus.service
#添加到系统服务中

[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io
After=network.target
 
[Service]
Type=simple
ExecStart=/usr/local/prometheus/prometheus \
--config.file=/usr/local/prometheus/prometheus.yml \
--storage.tsdb.path=/usr/local/prometheus/data/ \
--storage.tsdb.retention=15d \
--web.enable-lifecycle
  
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
 
[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl restart prometheus.service
systemctl status prometheus.service
默认端口号9090


配置节点监控：
tar -xf node_exporter-1.5.0.linux-amd64.tar.gz

mv node_exporter-1.5.0.linux-amd64/node_exporter /usr/local/bin/

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

systemctl start node_exporter
systemctl enable node_exporter
netstat -natp | grep :9100

vim /usr/local/prometheus/prometheus.yml
#在末尾添加
  - job_name: nodes
    metrics_path: "/metrics"
    static_configs:
    - targets:
          - 20.0.0.32:9100
          - 20.0.0.34:9100
          - 20.0.0.35:9100
      labels:
        service: kubernetes

systemctl reload prometheus

进入页面查看
http://20.0.0.32:9090

node01和node02都添加ndoe节点监控

tar -xf node_exporter-1.5.0.linux-amd64.tar.gz

mv node_exporter-1.5.0.linux-amd64/node_exporter /usr/local/bin/

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

systemctl start node_exporter
systemctl enable node_exporter
netstat -natp | grep :9100

到页面查看两个节点状态是否正常

在moster01安装grafana

rpm -ivh grafana-enterprise-7.5.11-1.x86_64.rpm
systemctl start grafana-server.service
systemctl enable grafana-server.service
systemctl status grafana-server.service

页面登录测试
20.0.0.32:3000

开始和Prometheus匹配

 开始添加k8s集群

导入模板即可11074、15172

https://grafana.com/grafana/dashboards 
#模板网站

总结

prometheus：就是一个监控。时序数列的图形化监控工具，不在意数据的持久化，只关注最近需要查找的数据。

更适配k8s集群。也可以对服务器进行一般监控(内存、cpu、硬盘、网络)