Prometheus———概述与部署

墨语清言
435 阅读12分钟

zabbix与prometheus区别

  • 和Zabbix类似，Prometheus也是一个近年比较火的开源监控框架，和Zabbix不同之处在于Prometheus相对更灵活点，模块间比较解耦，比如告警模块、代理模块等等都可以选择性配置。服务端和客户端都是开箱即用，不需要进行安装。zabbix则是一套安装把所有东西都弄好，很庞大也很繁杂。
  • zabbix的客户端agent可以比较方便的通过脚本来读取机器内数据库、日志等文件来做上报。而Prometheus的上报客户端则分为不同语言的SDK和不同用途的exporter两种，比如如果你要监控机器状态、mysql性能等，有大量已经成熟的exporter来直接开箱使用，通过http通信来对服务端提供信息上报（server去pull信息）；而如果你想要监控自己的业务状态，那么针对各种语言都有官方或其他人写好的sdk供你使用，都比较方便，不需要先把数据存入数据库或日志再供zabbix-agent采集。
  • zabbix的客户端更多是只做上报的事情，push模式。而Prometheus则是客户端本地也会存储监控数据，服务端定时来拉取想要的数据。
  • 界面来说zabbix比较陈旧，而prometheus比较新且非常简洁，简洁到只能算一个测试和配置平台。要想获得良好的监控体验，搭配Grafana还是二者的必走之路。

一、Prometheus概述

  • borgmon (监控系统) 对应克隆的版本:prometheus(go语言)
  • 所以prometheus 特别适合K8S 的架构上,作为一个数据监控解决方案，它由一个大型社区支持，有来自700多家公司的6300个贡献者，13500个代码提交和7200个拉取请求

1.1  Prometheus具有以下特性

  1. 多维的数据模型(基于时间序列的Key、value键值对)
  2. 灵活的查询和聚合语言PromQL
  3. 提供本地存储和分布式存储
  4. 通过基于HTTP和HTTPS的Pull模型采集时间序列数据（pull数据的拉取，时间序列:每段 时间点的数据值指标，持续性的产生。横轴标识时间，纵轴为数据值，一段时间内数值的动态变化，所有的点连线形成大盘式的折线图)
  5. 可利用Pushgateway (Prometheus的可选中间件）实现Push模式
  6. 可通过动态服务发现或静态配置发现目标机器（通过consul自动发现和收缩)
  7. 支持多种图表和数据大盘

1.2  Prometheus核心组件

整个Prometheus生态包含多个组件，除了Prometheus server组件其余都是可选的

  • Prometheus Server：主要的核心组件，用来收集和存储时间序列数据。
  • Client Library:：客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics。
  • push gateway：主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。
  • Exporters: 用于暴露已有的第三方服务的 metrics 给 Prometheus。
  • Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。
  • 各种支持工具。

二、运维监控平台设计思路

1.数据收集模块
2.数据提取模块(prometheus-TSDB,查询语言是promQL)
3.监控告警模块（布尔值表达式判断是否需要告警，不成立是健康状态）

  • 可以细化为6层
第六层:用户展示管理层   同一用户管理、集中监控、集中维护
第五层:告警事件生成层   实时记录告警事件、形成分析图表（趋势分析、可视化)
第四层:告警规则配置层   告警规则设置、告警伐值设置（定义布尔值表达式，筛选异常状态）
第三层:数据提取层       定时采集数据到监控模块
第二层:数据展示层       数据生成曲线图展示（对时序数据的动态展示)
第一层:数据收集层       多渠道监控数据（网络，硬件，应用，数据，物理环境）

三、prometheus监控体系 

监控体系

3.1 系统层监控（需要监控的数据)

  • CPU、Load、Memory、swap、disk i/o、process等
  • 网络监控 ：网络设备、工作负载、网络延迟、丢包率等

3.2 中间件及基础设施类监控端监控（移动APP、特定程序等)

  • 消息中间件:kafka、RocketMQ、等消息代理
  • WEB服务器容器:tomcat、weblogic/apache/php/spring系列
  • 数据库/缓存数据库:MysQL、PostgresQL、MogoDB、es、redis

监控数据库哪些东西？例如redis监控内容:

  • redis所在服务器的系统层监控
  • redis 服务状态
  • RDB AOF日志监控
  • 日志—>如果是哨兵模式—>哨兵共享集群信息，产生的日志—>直接包含的其他节点哨兵信息及redis信息
  • key的数量
  • key被命中的数量/次数
  • 最大连接数——>redis 和 系统：
  • 系统：ulimit -a redis :redis-cli 登陆——> config get maxclients 查看最大连接

四、prometheus的部署

[root@localhost ~]# rz
[root@localhost ~]# ls
anaconda-ks.cfg                       公共  图片  音乐
initial-setup-ks.cfg                  模板  文档  桌面
prometheus-2.27.1.linux-amd64.tar.gz  视频  下载
[root@localhost ~]# tar zxvf prometheus-2.27.1.linux-amd64.tar.gz -C /usr/local/
---
[root@localhost ~]# cd /usr/local/
[root@localhost local]# cd prometheus-2.27.1.linux-amd64/
[root@localhost prometheus-2.27.1.linux-amd64]# ./prometheus
---
#另开一台终端
[root@localhost ~]# netstat -natp | grep 9090
tcp6       0      0 :::9090                 :::*                    LISTEN      10161/./prometheus  
tcp6       0      0 ::1:9090                ::1:46988               ESTABLISHED 10161/./prometheus  
tcp6       0      0 ::1:46988               ::1:9090                ESTABLISHED 10161/./prometheus  
---
  • 登录网址192.168.10.60：9090
  • 表达式浏览器

Snipaste_2023-03-15_15-28-23.png

Snipaste_2023-03-15_15-30-19.png

Snipaste_2023-03-15_15-30-49.png

Snipaste_2023-03-15_15-31-12.png

Snipaste_2023-03-15_15-51-03.png

Snipaste_2023-03-15_15-54-02.png

访问192.168.10.60:9090/metrics

Snipaste_2023-03-15_15-54-28.png

五、prometheus生态组件

image.png prometheus架构图：

u=2392426037,341938366&fm=253&fmt=auto&app=138&f=JPEG.webp

5.1 prometheus-server

  • etrieval(获取数据pull/discover） ，TSDB存储，HTPserver
  • 控制台接口，内建了数据样本采集器，可以通过配置文件定义，告诉prometheus到那个监控对象中采集指标数据，prometheus采集过后，会存储在自己内建的TSDB数据库中(默认为2个月时间))，提供了prompL支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析一场指标，一旦发生，通知给alerter来发送告警信息，还支持对接外置的UI工具(grafana）来展示数据

5.2 pushgateway (短期周期任务)

允许短暂和批量作业将其指标暴露给普罗米修斯，由于这些类型的作业可能存在时间不足而被删除，因此他们可以将其指标推送到pushgateway，然后pushgateway将这些指标暴露给Prometheus-server端，主要用于业务数据汇报

5.3 exporters (常规任务—守护进程)

专门采集一些web服务，nginx，mysgl服务。因为不适合直接通过nttp的方式采集数据，所以需要通过exporter采集数据（下载mysqgl_exporter，采集mysql数据指标）cadvisor: docker数据收集工具(docker也有自己内置的监控收集方式) exporter和instrumtations，负责专门服务数据的收集然后暴露出来等待promtheus收集

5.4.service discovery:

原生支持k8s的服务发现,支持consul、DNS等

5.5.prometheus内置TSDB数据库作为存储（时序数据的储存，promtheus的TSDB数据库默认保存15天，可以自行调整)

  • ps:时间序列数据库（时序数据库）主要用于指处理代表签（按照时间的顺序变化，既时间序列化）的数据，带时间标签的数据也成为时间序列数据，这是一种特殊类型的数据库，一般不会保存长时间的数据（与mysql相比）
  • 数据保存时间storge.tsdb.retention=90d参数中修改即可（或启动时间指定)

5.6 alertmanagr

prometheus可以生成告警信息，但是不能直接提供告警，需要使用一个外置的组件altermanager来进行告警，emailetctif优势在于，收敛、支持静默、去重、可以防止告警信息的轰炸

5.7 data visualization

prometheus web ui (prometheus-server内建，表达式浏览器），也可以使用grafana

5.8 PrmoQL (告警规则编写)

通常告警规则的文件指定输出到展示界面（grafana）

5.9 UI : 表达式浏览器（调试)

六、总结

6.1 prometheus如何收集k8s/服务的–三种方式收集

  • Exporters（指标暴露器） ：收集节点的信息、将数据格式化或转化为promtheus可识别的http这种转化方式/镜像拉取方式
  • Instrumentation （应用内置的指标暴露器）： 收集有内置指标暴露器的信息
  • Pushgateway ： 收集短周期的数据

6.2 如何防止告警信息轰炸

alertmanagr: prometheus可以生成告警信息，但是不能直接提供告警，需要使用一个外置的组件altermanager来进行告警，emailetctif优势在于，收敛、支持静默、去重、可以防止告警信息的轰炸

把这条告警规则中的支持静默开启，让它必须，配置文件里直接改alertmanagr改一个单词

6.3 prometheus 工作流程

  1. Prometheus server定期从配置好的jobs或者exporters中拉取metrics，或者接收来自 Pushgateway发送过来的metrics，或者从其它的Prometheus server中拉metrics。
  2. Prometheus server在本地存储收集到的metrics，并运行定义好的alerts.rules，记录新的时间序列或者向Alert manager推送警报。
  3. Alertmanager根据配置文件，对接收到的警报进行处理，发出告警。
  4. 在图形界面中，可视化采集数据。
基本原理
 
服务发现：Prometheus周期性得以pull的形式对target进行指标采集，而监控目标集合是通过配置文件中所定义的服务发现机制来动态生成的。也可以静态配置；
relabel：当服务发现得到所有target后，Prometheus会根据job中的relabel_configs配置对target进行relabel操作，得到target最终的label集合。
采集：进行完上述操作后，Prometheus为这些target创建采集循环，按配置文件里配置的采集间隔进行周期性拉取，采集到的数据根据Job中的metrics_relabel_configs进行relabel，然后再加入上边得到的target最终label集合，综合后得到最终的数据。
存储：Prometheus不会将采集到的数据直接落盘，而是会将近2小时的series缓存在内存中，2小时后，Prometheus会进行一次数据压缩，将内存中的数据落盘。
流程：服务发现 ==> targets ==> relabel ==> 抓取 ==> metrics_relabel ==> 缓存 ==> 2小时落盘
  1. Prometheus Server 可定期从活跃的目标主机上（target）拉取监控指标数据，目标主机的监控数据可以通过配置静态job或者服务发现的方式被Prometheus server采集到，这种方式默认是pull方式拉取指标；也可以通过pushgateway把采集的数据上报到Prometheus server中；还可以通过一些组件自带的exporter采集相应组件的数据；
  2. Prometheus server的时间序列把采集到的监控指标数据整合并保存到本地的磁盘或者数据库中；
  3. Prometheus采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到Alertmanager；
  4. Alertmanager 通过配置报警接受方，发送报警到邮件，微信等；
  5. Prometheus 自带的web ui界面提供PromQL查询语言，可查询监控数据；
  6. Grafana 可接入Prometheus数据源，把监控数据以图形化展示出；

6.4 prometheus监控什么

6.4.1 网络监控

  • 网络性能监控：主要涉及网络监测，网络实时流量监控（网络延迟、访问量、成功率）和历史数据统计、汇总和历史数据分析等功能。
  • 网络检测：主要针对内网或者外网的网络。如DDoS的。通过分析异常流量来确定网络行为。
  • 设备监控：主要针对数据中心内的多种网络设备进行监控。包括路由器，防火墙和交换机等硬件设备，可以通过snmp等协议收集数据。

6.4.2 存储监控

  • 存储性能监控方面：存储通常监控块的读写速率，IOPS。读写延迟，磁盘用量等；文件存储通常监控文件系统inode。读写速度、目录权限等。
  • 存储系统监控方面：不同的存储系统有不同的指标，例如，对于ceph存储需要监控OSD, MON的运行状态，各种状态pg的数量以及集群IOPS等信息。
  • 存储设备监控方面：对于构建在x86服务器上的存储设备，设备监控通过每个存储节点上的采集器统一收集磁盘、SSD、网卡等设备信息；存储厂商以黑盒方式提供商业存储设备，通常自带监控功能，可监控设备的运行状态，性能和容量的。

6.4.3 服务器监控

  • CPU：涉及整个 CPU 的使用量、用户态百分比、内核态百分比，每个 CPU 的使用量、等待队列长度、I/O 等待百分比、CPU 消耗最多的进程、上下文切换次数、缓存命中率等。
  • 内存：涉及内存的使用量、剩余量、内存占用最高的进程、交换分区大小、缺页异常等。
  • 网络 I/O：涉及每个网卡的上行流量、下行流量、网络延迟、丢包率等。
  • 磁盘 I/O：涉及硬盘的读写速率、IOPS、磁盘用量、读写延迟等。

6.4.4 中间件监控

  • 消息中间件： RabbitMQ Exporter、Kafka Exporter
  • Web 服务中间件：Apache Exporter、Nginx Exporter
  • 数据库中间件：MySQL Exporter、PostgreSQL Exporter、Redis Exporter
avatar
文章
阅读
粉丝