Promethues原理详解

最新推荐文章于 2024-04-30 17:31:37 发布

IT.cat

最新推荐文章于 2024-04-30 17:31:37 发布

阅读量1.5k

点赞数

分类专栏： Prometheus 文章标签：数据库服务器 Prometheus linux

本文链接：https://blog.csdn.net/qq_57377057/article/details/127512430

版权

Prometheus 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

引言

一、Prometheus概念

1.1、什么是Prometheus

1.2、Zabbix和Prometheus区别

5.1、Prometheus server

5.2、pushgateway

5.3、exporters

常用的exporter：

5.5、Service Discovery

引言

zabbix是传统的监控系统，出现比云原生早，使用的是SQL关系型数据库；而Prometheus基于谷歌的borgemon使用go语言开发，使用TSDB数据库，所以支持云原生。zabbix最新发布的6.0版本，知道自己处于生死存亡时刻，也支持了Prometheus使用的TSDB数据库。

一、Prometheus概念

1.1、什么是Prometheus

Prometheus是一个开源的服务监控系统和时序数据库，其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件Prometheus server会定期从静态配置的监控目标或者基于服务发现自己配置的目标中进行拉取数据，当新拉取到的数据大于配置的内存缓存区时，数据就会持久化到存储存储设备当中。

每个被监控的主机都可以通过专用的exporter程序提供输出监控数据的接口，它会在目标处收集监控数据，并暴露一个HTTP接口供Prometheus server查询，Prometheus通过基于HTTP的pull的方式来周期性的采集数据。
任何被监控的目标都需要事先纳入到监控系统中才能进行时序数据采集、存储、告警和展示、监控目标可以通过配置信息以静态形式指定，也可以让Prometheus通过服务发现的机制进行动态管理。
Prometheus能够直接把API Server作为服务发现系统使用，进而动态发现和监控集群中的所有可被监控的对象。

Prometheus 官网地址：https://prometheus.io
Prometheus github 地址：https://github.com/prometheus

1.2、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还是二者的必走之路。

1.3、Prometheus的特点

多维数据模型：有度量名称和键值对标识的时间序列数据

时序数据，是在一段时间内通过重复测量（measurement）而获得的观测值的集合；将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴；

服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据。

内置时间序列（pime series）数据库：Prometheus；外置的远端存储通常会用：InfluxDB、openTsDB等
promQL一种灵活的查询语言，可以利用多维数据完成复杂查询
基于HTTP的pull（拉取）方式采集时间序列数据
同时支持PushGateway组件收集数据
通过服务发现或者静态配置，来发现目标服务对象
支持作为数据源接入Grafana

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

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

可以细化为6层

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

三、Prometheus监控体系

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

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

3.2、中间件及基础设施类监控

消息中间件：kafka、RocketMQ等消息代理（redis中间件）
WEB服务容器：tomcat、weblogic、apache、php、spring系列
数据库/缓存数据库：Mysql、Postgresql、MongoDB、es、redis

redis监控内容

redis的服务状态
redis所在服务器的系统层监控
RDB和AOF日志监控

日志--->如果是哨兵模式--->哨兵共享集群信息，产生的日志
--->直接包含的其他节点哨兵信息及redis信息

key的数量
key呗命中的数据/次数
最大连接数---->redis和系统
redis:redis-cli登陆---->config get maxclients查看最大连接数

3.3、应用层监控

用于衡量应用程序代码状态和性能

监控的分类：

白盒监控：自省指标，等待被下载（cadvisor）
黑盒监控：基于探针（snmp）的监控方式，不会主动干预、影响数据。

3.4、业务层监控

用于衡量应用程序的价值。如电商业务的销售量，ops、dau日志、转化等

业务接口：登入数量，注册数、订单量、搜索量和支付量

四、Prometheus时间序列数据

4.1、什么是序列数据

时间学列数据（TimeSeries Data）：按照时间序列记录系统、设备状态变化的数据被称为时序数据。

应用场景很多，如：

无人驾驶车辆运行中要记录的经度，纬度，速度，方向，旁边物体的距离等等。每时每刻都要讲数据记录下来做分析。
某一个地区的各车辆的行驶轨迹数据
传统证券行业试试交易数据
实时运维监控数据等

4.2、时间序列数据特点

性能好：关系型数据库对于大规模数据的处理性能糟糕。NOSQL可以比较好的处理大规模数据，但依然比不上时间序列数据库
存储成本低：高效的压缩算法，节省存储空间，有效降低IO

Prometheus有着非常高效的时间序列数据存储方法，每个采样数据仅仅占用3.5byte左右空间，上百万条时间序列，30秒间隔，保留60天，大概花了200多G（官方数据）

4.3、数据来源

Prometheus基于HTTP call（http/https请求），从配置文件中指定的网络端点（endpoint/IP：端口）上周期性获取指标数据。很多环境，被监控对象，本身是没有直接响应/处理http请求的功能。

Prometheus-exporter则可以在被监控端收集所需的数据，收集过来之后，还会做标准化，把这些数据转化为promenade可识别，可使用的数据（兼容格式）。

4.4、收集数据

监控概念：百合监控，黑盒监控

白盒监控：自省方式，被监控端内部，可以生成指标，只要等待监控系统来采集时提供出去即可

黑盒监控：对于被监控系统没有侵入性，对其没有直接’影响‘，这种类似于基于探针机制进行监控（snmp协议）

prometheus支持通过三种类型的途径从目标上抓取/采集（scrape）指标数据（基于白盒监控）

exporter--->工作在被监控端，周期性的抓取数据并转换为prometheus来收集，自己并不推送
Instrumentation--->指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取
Pushgateway--->短周期5s-10s的数据收集

4.5、Prometheus获取方式

Prometheus同其他TSDB相比有一个非常典型的特性：主动从各Target上拉取（pull）数据，非等待被监控端的推送（push）

两个获取方式各有优劣，其中，Pull模型的优势在于：

集中控制:有利于将配置集在Prometheus server上完成，包括指标及采取速率等;
Prometheus的根本目标在于收集在target上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统通过targets(标识的是具体的被监控端)
比如配置文件中的targets : [ ‘localhost:9090’]

五、Prometheus的生态组件

Prometheus 负责时序型指标数据的采集及存储，但数据的分析、聚合及直观展示以及告警等功能并非由Prometheus Server所负责。

5.1、Prometheus server

Prometheus server：服务核心组件，采用pull方式收集监控数据，通过http协议传输。并存储时间序列数据。Prometheus server 由三个部分组成：Retrival，Storage，PromQL

Retrieval：负责在活跃的target 主机上抓取监控指标数据。
Storage：存储，主要是把采集到的数据存储到磁盘中。默认为15天（可修改）。
PromQL：是Prometheus提供的查询语言模块。

5.2、pushgateway

Pushgateway：类似一个中转站，Prometheus的server端只会使用pull方式拉取数据，但是某些接节点因为某些原因只能使用push方式推送数据，那么它就是用来接收push而来的数据并暴露给Prometheus的server拉取的中转站。可以理解成目标主机可以上报短期任务的数据到Pushgateway，然后Prometheus server统一Pushgateway拉取数据

5.3、exporters

Exporters：指标暴露器，负责收集不支持内奸Instrumentation的原因程序或服务的性能指标数据，并通过HTTP接口提供Prometheus Server获取。换句话说，Exporter负责从目标应用程序上采集和聚合原始格式的数据，并转换或聚合为Prometheus格式的指标向外暴露。

常用的exporter：

Node-Exporter：用于收集服务器节点（例如k8s）的物理指标状态数据，如平均负载、CPU、内存、磁盘、网络等资源信息的指标数据，需要部署到所有运算节点。指标详细介绍：https://github.com/prometheus/node_exporter
mysqld-exporter/nginx-exporter
Kube-state-Metrics：为prometheus 采集k8s资源数据的exporter，通过监听APIServer 收集kubernetes集群内资源对象的状态指标数据，例如pod、deployment、service 等等。同时它也提供自己的数据，主要是资源采集个数和采集发生的异常次数统计。

需要注意的是kube-state-metrics 只是简单的提供一个metrics 数据，并不会存储这些指标数据，
所以可以使用prometheus来抓取这些数据然后存储，主要关注的是业务相关的一些元数据，
比如Deployment、Pod、副本状态等；调度了多少个replicas？现在可用的有几个？
多少个Pod是running/stopped/terminated 状态？Pod 重启了多少次？有多少job在运行中。

cAdvisor：用来监控容器内部使用资源的信息，比如CPU、内存、网络I/0、磁盘I/0。
blackbox-exporter：监控业务容器存活性。

5.5、Service Discovery

Service Discovery：服务发现，用于动态发现待监控的Target，Prometheus支持多种服务发现机制：文件、DNS、Consul、Kubernetes等等。

服务发现可通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮询这些Target 获取监控数据。该组件目前由Prometheus Server内建支持