Prometheus监控系统——前篇

目录

Prometheus简介

        prometheus特点

prometheus时序数据

                数据来源

                收集数据:

        prometheus获取方式

prometheus生态组件

                 prometheus架构图

 prometheus数据模型

        概述

                指标类型

               job和实例targets/instance

                prometheusQL(数据查询语言也是时序数据库使用语言)

部署Prometheus

                默认配置文件详解

        部署监控其他节点 

 表达式浏览器常规使用

总结


Prometheus简介

        Prometheus是一套开源的监控、报警、时间序列、数据库的组合采集的样本以时间序列的方式保存在内存(TSDB时序数据库)中,并定时保存到硬盘中(持久化)时序数据库不属于sql数据库也并不是nosql数据库

        Prometheus是继Kubernetes之后,第二个从云原生计算基金会(CNCF)毕业的项目。Prometheus是Google监控系统BorgMon类似实现的开源版,整套系统由监控服务、告警服务、时序数据库等几个部分,及周边生态的各种指标收集器(Exporter)组成,是在当下主流的云原生监控告警系统,所以非常契合k8s的监控对容器非常适用。

官网:https://prometheus.io/docs/concepts/data_model/

        prometheus特点

        自定义多维数据模型(时序列数据由metric名和一组key/value标签组成)

        非常高效的储存平均一个采样数据占大约3.5bytes左右,320万的时间序列,每30秒采样,保持60天,消耗磁盘大概228G

        在多维上灵活且强大的查询语句(PromQL)

        不依赖分布式储存,支持单主节点工作

        通过基于HTTP的pull方式采集时序数据

        可以通过push gateway进行时序列数据库推送(pushing)

        可以通过服务发现或静态配置去获取要采集的目标服务器(自动发现监控断点)

        多种可视化图表及仪表盘支持

prometheus时序数据

        时序数据,是在一段时间内通过重复测量(measurement)而获得的观测值的集合将这些观测值绘制于图形之上,它会有一个数据轴和一个时间轴,服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据;

                数据来源

        prometheus基于HTTP call (http/https请求),从配置文件中指定的网络端点(endpoint/IP:端口)上周期性获取指标数据。

        很多环境、被监控对象,本身是没有直接响应/处理http请求的功能,prometheus-exporter则可以在被监控端收集所需的数据,收集过来之后,还会做标准化,把这些数据转化为prometheus可识别,可使用的数据(兼容格式)

                收集数据:

        监控概念:白盒监控、黑盒监控

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

        黑盒监控:对于被监控系统没有侵入性,对其没有直接"影响",这种类似于基于探针机制进行监控(snmp协议)

        Prometheus支持通过三种类型的途径从目标上"抓取(Scrape)"指标数据(基于白盒监控);

Exporters ——>工作在被监控端,周期性的抓取数据并转换为pro兼容格式等待prometheus来收集,自己并不推送

Instrumentation ——>指被监控对象内部自身有数据收集、监控的功能,只需要prometheus直接去获取

Pushgateway ——>短周期5s—10s的数据收集

        prometheus获取方式

        Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上拉取(pull)数据,而非等待被监控端的推送(push)

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

集中控制:有利于将配置集在Prometheus server上完成,包括指标及采取速率等;

        Prometheus的根本目标在于收集在target上预先完成聚合的聚合型数据,而非一款由事件驱动的存储系统,通过targets(表示的是具体的被监控端),比如配置文件中的 targets['localhost:9090']

prometheus生态组件

Prometheus监控系统——前篇_第1张图片

prometheus生态圈中包含了多个组件,其中部分组件可选

Prometheus Server:收集和储存时间序列数据

        通过scraping以刮擦的方式去获取数据放入storge(TSDB时序数据库),制定Rules/Alerts:告警规则,service discovery是自动发现需要监控的节点

Client Library:客户端库,目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径;

Push Gateway:接收那些通常由短期作业生成的指标数据的网关,并支持由Prometheus Server进行指标拉取操作;

Exporters:用于暴露现有应用程序或服务(不支持Instrumentation)的指标给Prometheus Server)

        而promethus内建了数据样本采集器,可以通过配置文件定义,告诉prometheus到那个监控对象中采集指标数据,prometheus 采集过后,会存储在自己内建的TSDB数据库中,提供了promQL 支持查询和过滤操作,同时支持自定义规则来作为告警规则,持续分析一场指标,一旦发生,通知给alerter来发送告警信息,还支持对接外置的UI工具(grafana)来展示数据

采集、抓取数据是其自身的功能,但一般被抓去的数据一般来自于:export/instrumentation (指标数据暴露器) 来完成的,或者是应用程序自身内建的测量系统(汽车仪表盘之类的,测量、展示)来完成

Alertmanager:由告警规则对接,从Prometheus Server接收到"告警通知"后,通过去重、分
组、路由等预处理功能后以高效向用户完成告警信息发送

Data Visualization(Dashboards): 与TSDB对接并且展示数据库中的数据,Prometheus web UI (Prometheus Server内建),及Grafana等;

Service Discovery:动态发现待监控的Target,从而完成监控配置的重要组件,在容器化环境中尤为有用;该组件目前由PropetheusServer内建支持

                 prometheus架构图

Prometheus监控系统——前篇_第2张图片

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

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

        exporters(常规任务—守护进程)专门采集一些web服务,nginx,mysql服务。因为不适合直接通过http的方式采集数据,所以需要通过exporter采集数据(下载mysql_exporter,采集mysql数据指标)cadvisor:docker数据收集工具(docker也有自己内置的监控收集方式)

exporter和instrumtations,负责专门服务数据的收集然后暴露出来等待promtheus收集

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

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

        ps:时间序列数据库(时序数据库)主要用于指处理代表签(按照时间的顺序变化,既时间序列化)的数据,带时间标签的数据也成为时间序列数据,这是一种特殊类型的数据库,一般不会保存长时间的数据(与mysql相比)。

        数据保存时间 storge.tsdb.retention=90d参数中修改即可(或启动时间指定)

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

        data visualization:prometheus web ui(prometheus-server内建),也可以使用grafana

        PrmoQL(告警规则编写),通常告警规则的文件指定输出到展示界面(grafana)

        ui表达式浏览器(调试)

 prometheus数据模型

        概述

        prometheus仅用键值方式存储时序式的聚合数据,他不支持文本信息

        其中的"键"成为指标(metric),通常意味着cpu速率、内存使用率或分区空闲比例等,同一指标可能适配到多个目标或设备、因而它使用"标签"作为元数据,从而为metric添加更多的信息描述维度例如三台设备,在同一时刻,都会产生例如1分组CPU负载的数据,他们都会使用相同的指标(metric),而此时一个指标,如何表示时间序列?

        比如:三个node节点都会有相同的指标(例如cpu0的负载那么就会使用相同的指标名称)
使用 指标:标签=标签值 的格式来表示,例如:local1 {host=node1,host=node2},metric(cpu指标):

示例:
cpu_usage{core='1',ip='192.168.37.100'} 14.04
key        cpu0      labels(元数据)      样本
1
2
prometheus每一份样本数据都包含了:

① 时序列标识:key+lables
② 当前时间序列的样本值value
③ 这些标签可以作为过滤器进行指标过滤及聚合运算,如何从上万的数据过滤出关键有限
的时间序列,同时从有限的时间序列在特定范围的样本那就需要手动编写出时间序列的样本表达式来过滤出我们需求的样本数据

                指标类型

默认都是以双精度浮点型数据(服务端无数据量类型数据)

① counter : 计数器单调递增

② gauge:仪表盘:有起伏特征的

③ histogram:直方图:

        在一段时间范围内对数据采样的相关结果,并记入配置的bucket中,他可以存储更多的数据,包括样本值分布在每个bucket的数量,从而prometheus就可以使用内置函数进行计算:

计算样本平均值:以值得综合除以值的数量

计算样本分位值:分位数有助于了解符合特定标准的数据个数,例如评估响应时间超过1秒的请

例,若超过20%则进行告警等

④ summary,摘要,histogram的扩展类型,它是直接由监控端自行聚合计算出分位数,同时
将计算结果响应给prometheus server的样本采集请求,因而,其分位数计算是由监控端完成

               job和实例targets/instance

① job:能够接收prometheus server数据scrape "mysql_nodes" "mysql_master_slave"

② targets 每一个可以被监控的系统,成为targets多个相同的targets的集合(类)称为job

③ instance:实例 与 targets(类似)

与target相比,instance更趋近于一个具体可以提供监控数据的实例,而targets则更像一个对象、目标性质

                prometheusQL(数据查询语言也是时序数据库使用语言)

支持两种向量,同时内置提供了一组用于数据处理的函数

① 即时向量:最近以此时间戳上跟踪的数据指标(一个时间点上的数据),即时向量选择器:返回0个1个或者多个时间序列上在给定时间戳上的各自的一个样本,该样本成为即时样本

② 时间范围向量:指定时间范围内所有时间戳上的数据指标,范围向量选择器:返回0个1个或多个时间序列上在给定时间范围内的各自的一组样本
(范围向量选择器无法用于绘图)

部署Prometheus

服务器分配

主机名  地址 安装包
prometheus 192.168.37.100  prometheus-2.27.1.linux-amd64.tar.gz
node1  192.168.37.101 node_exporter-1.1.2.linux-amd64.tar.gz
node2 192.168.37.102
node3  192.168.37.107

       关闭防火墙、设置时间同步、修改主机名(所有服务器)

[root@prometheus ~]# ntpdate ntp1.aliyun.com
19 Feb 16:29:03 ntpdate[24039]: adjust time server 120.25.115.20 offset -0.002715 sec
[root@prometheus ~]# date
2022年 02月 19日 星期六 16:29:41 CST
[root@prometheus ~]#

下载安装包,Download | Prometheus
      
解压到/usr/local目录下

[root@prometheus /opt]# tar -zxf prometheus-2.27.1.linux-amd64.tar.gz -C /usr/local/
[root@prometheus /opt]# cd /usr/local/prometheus-2.27.1.linux-amd64/
[root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]# ls
console_libraries  consoles  LICENSE  NOTICE  prometheus  prometheus.yml  promtool
[root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]#

                默认配置文件详解

[root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]# cat prometheus.yml

# my global config
global:		//全局组件
  //每隔多久抓取一次指标,不设置默认1分钟
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  //内置告警规则的评估周期
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

//对接的altermanager(第三方告警模块)
# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:		//告警规则
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:		
  # The job name is added as a label `job=` to any timeseries scraped from this config.
  - job_name: 'prometheus'		//对于指标需要打上的标签,对于PrometheusSQL(查询语句)的标签:比如prometheus{target='values'}

    # metrics_path defaults to '/metrics' 		 //收集数据的路径
    # scheme defaults to 'http'.

    static_configs:		//对于Prometheus的静态配置监听端口具体数据收集的位置 默认的端口9090
    
    - targets: ['localhost:9090']

 开启服务

[root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]# ./prometheus

查看网页

Prometheus监控系统——前篇_第3张图片        查看target

Prometheus监控系统——前篇_第4张图片
        

        查看采集数据 ,Prometheus会进行周期性的采集数据(完整的),多次周期性(在一个时间区间内)采集的数据集合,形成时间序列

 访问192.168.37.100:9090/metrics       

 Prometheus监控系统——前篇_第5张图片

        部署监控其他节点 

        prometheus想要监控其他节点,则需要借助node_exporter,下载地址和Prometheus一样找到node_exporter

解压安装包,命令优化路径,设置服务控制,开启服务

[root@node1 /opt]# tar -zxf node_exporter-1.1.2.linux-amd64.tar.gz
[root@node1 /opt]# ls
mysql-5.7.20  mysql-boost-5.7.20.tar.gz  node_exporter-1.1.2.linux-amd64  node_exporter-1.1.2.linux-amd64.tar.gz  rh
[root@node1 /opt]# cd node_exporter-1.1.2.linux-amd64/
[root@node1 /opt/node_exporter-1.1.2.linux-amd64]# ls
LICENSE  node_exporter  NOTICE
[root@node1 /opt/node_exporter-1.1.2.linux-amd64]# cp node_exporter /usr/local/bin/

服务开启,使用systemctl

[root@node1 /usr/lib/systemd/system]# vim node_exporter.service

[Unit]
Description=node_exporter Monitoring System
Documentation=node_exporter Monitoring System

[Service]
ExecStart=/usr/local/bin/node_exporter --web.listen-address=:9100

[Install]
WantedBy=multi-user.target
[root@node1 /usr/lib/systemd/system]# systemctl start node_exporter.service

访问9100端口

Prometheus监控系统——前篇_第6张图片

 

查看抓取内容在这里插入代码片在这里插入代码片

将启动项复制到另外两个节点上

[root@node1 /usr/lib/systemd/system]# scp /usr/lib/systemd/system/node_exporter.service [email protected]:/usr/lib/systemd/system/node_exporter.service
The authenticity of host '192.168.37.102 (192.168.37.102)' can't be established.
ECDSA key fingerprint is SHA256:Mvd5xyxIGyLCKU5ZLBLlHQy2BkTRwdvAtah3Oi5I01E.
ECDSA key fingerprint is MD5:e7:62:58:23:40:39:64:0a:56:8f:bf:e3:bd:a5:97:79.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.37.102' (ECDSA) to the list of known hosts.
[email protected]'s password:
node_exporter.service                                                                                  100%  212   135.8KB/s   00:00
[root@node1 /usr/lib/systemd/system]# scp /usr/lib/systemd/system/node_exporter.service [email protected]:/usr/lib/systemd/system/node_exporter.service
The authenticity of host '192.168.37.107 (192.168.37.107)' can't be established.
ECDSA key fingerprint is SHA256:OvR2tfXV/9eIjNub7c46Jd0Vp6ngtaYMuPEu6Ltxzqs.
ECDSA key fingerprint is MD5:8c:a5:fc:d6:4e:8f:7b:8c:f8:57:10:36:c5:55:55:e6.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.37.107' (ECDSA) to the list of known hosts.
[email protected]'s password:
node_exporter.service                                                                                  100%  212   153.0KB/s   00:00

 启动node_exporter

[root@node2 ~]# systemctl start node_exporter.service
[root@node3 ~]# systemctl start node_exporter.service

        若需要加入其他节点监控端,则需要在192.168.37.100 prometheus服务端停止prometheus修改配置文件添加静态targets才能使得server1节点加入

[root@prometheus /usr/local/prometheus-2.27.1.linux-amd64]# vim prometheus.yml

。。。
  - job_name: 'nodes'
    static_configs:
    - targets:
      - 192.168.37.101:9100
      - 192.168.37.102:9100
      - 192.168.37.107:9100
~

重新启动Prometheus查看网页

Prometheus监控系统——前篇_第7张图片

 表达式浏览器常规使用

在prometheusUI控制台上可以进行数据过滤,最简单的查看cpu使用总量

Prometheus监控系统——前篇_第8张图片

计算过去5分钟内的CPU使用速率

PromQL: irate(node_cpu_seconds_total{mode="idle"}[5m])

解析:
irate:速率计算函数(灵敏度非常高的)
node_cpu_seconds_total:node节点CPU使用总量
mode="idle" 空闲指标
5m:过去的5分钟内,所有CPU空闲数的样本值,每个数值做速率运算

 每台主机CPU 在5分组内的平均使用率
PromQL:(1- avg (irate(node_cpu_seconds_total{mode='idle'}[5m]))by (instance))* 100

Prometheus监控系统——前篇_第9张图片

 解析
avg:平均值
avg (irate(node_cpu_seconds_total{mode='idle'}[5m]):可以理解为CPU空闲量的百分比
by (instance):表示的是所有节点
(1- avg (irate(node_cpu_seconds_total{mode='idle'}[5m]))by (instance))* 100:CPU 5分钟内的平均使用率

TSDB : infuxDB时序数据库

 其他常用的指标:

1、查询1分钟平均负载超过主机CPU数量两倍的时间序列

node_load1 > on (instance) 2 * count (node_cpu_seconds_total{mode='idle'}) by(instance)

2、内存使用率
node_memory_MemTotal_bytes

node_memory_MemFree_bytes

node_memory_Buffers_bytes

node_memory_Cached_bytes

3、计算使用率:

可用空间:以上后三个指标之和

已用空间:总空间减去可用空间

使用率:已用空间除以总空间

指标(配置文件/promql):targets/instance 

target 偏向于表示一个集合

instance 偏向于表示具体的一个可提供监控数据的对象

PromQL: 指标 {标签1=标签值1,......标签N=标签值N} 样本(值)
 

总结

        prometheus 的配置文件:① global ② alertmanager③ rules④ scrape

        prometheus 架构模型(工作流程)

scrape收集数据方式:

① exporter

② 自建/内建指标

③ pushgateway 

sd服务发现:

① 基于fd文件

② 基于DNS ——》SRV记录 

③ 基于consul ——》自动发现,同时利用prometheus 的自身周期扫描配置文件更新项并加载的特性,实现动态更新

④ 基于K8S 服务发现

你可能感兴趣的:(监控,Prometheus)