目录
一、prometheus数据模型
（什么是标签、什么是指标、什么是样本)
1、概述
prometheus仅用键值方式存储时序式的聚合数据，他不支持文本信息
其中的"键"成为指标(metric)，通常意味着cpu速率、内存使用率或分区空闲比例等
同一指标可能适配到多个目标或设备、因而它使用"标签"作为元数据，从而为metric添加更多的信息描述维度例如三台设备，在同一时刻，都会产生例如1分组cPu负载的数据，他们都会使用相同的指标(metric)，而此时一个指标，如何表示时间序列?
比如：三个node节点都会有相同的指标（例如cpu0的负载那么就会使用相同的指标名称)
使用指标:标签=标签值的格式来表示，例如: locall {host=node1, host=node2 }
metric ( cpu指标):
示例:
cpu_usage { core='1',ip='192.168.226.128' } 14.04
key cpu0 labels（元数据) 样本
1
2
prometheus每一份样本数据都包含了:
时序列标识:key+lables
当前时间序列的样本值value
这些标签可以作为过滤器进行指标过滤及聚合运算，如何从上万的数据过滤出关键有限的时间序列，同时从有限的时间序列在特定范围的样本那就需要手动编写出时间序列的样本表达式来过滤出我们需求的样本数据2、指标类型
默认都是以双精度浮点型数据（服务端无数据量类型数据)
counter :计数器单调递增
gauge :仪表盘:有起伏特征的
histogram：直方图，在一段时间范围内对数据采样的相关结果，并记入配置的brucket中，他可以存储更多的数据，包括样本值分布在每个bucket的数量, 从而prometheus就可以使用内置函数进行计算：
计算样本平均值：以值得综合除以值的数量
计算样本分位值：分位数有助于了解符合特定标准的数据个数，例如评估响应时间超过1秒的请求比例，若超过20%则进行告警等
summary，摘要，histogram的扩展类型，它是直接由监控端自行聚合计算出分位数，同时将计算结果响应给prometheus server的样本采集请求，因而，其分位数计算是由监控端完成
3、作业job和实例targets/instance
job：能够接收prometheus server数据scrape
targets每一个可以被监控的系统，成为targets多个相同的targets的集合（类）称为job
instance：实例与targets（类似)
与target相比，instance更趋近于一个具体可以提供监控数据的实例，而targets则更像一个对象、目标性质
4、prometheusQL
（数据查询语言也是时序数据库使用语言)
支持两种向量，同时内置提供了一组用于数据处理的函数
即时向量：最近以此时间戳上跟踪的数据指标（一个时间点上的数据)
即时向量选择器:返回0个1个或者多个时间序列上在给定时间戳上的各自的一个样本，该样本成为即时样本
时间范围向量:指定时间范围内所有时间戳上的数据指标
范围向量选择器:返回0个1个或多个时间序列上在给定时间范围内的各自的一组样本(范围向量选择器无法用于绘图)
5、prometheus数据模块
global：全局配置
altermanager configuration：告警模块（通过prometheusQL+布尔值表达式产生告警信息）
rules
scrape
二、表达式浏览器（promql）
1、表达式使用
CPU使用总量
node_cpu_seconds_total
计算过去5分钟内的CPU使用速率
PromQL: irate(node_cpu_seconds_total{cpu="0",mode="idle"}[5m])
irate:速率计算函数(灵敏度非常高)
node_cpu_seconds_total:node节点CPU使用总量（指标)
modd="idle"空闲指标
5m:过去的5分钟内，所有CPU空闲数的样本值，每个数值做速率运算
{ mode=“idle”}:整体称为标签过滤器
每台主机CPU在5分钟内的平均使用率
PromQI:(1-avg(irate(node_cpu_seconds_total{cpu="0",mode="idle"}[5m]))by(instance))*100
avg:平均值
avg (irate (node_cpu_seconds_total{fmode=‘idle’ } [5m]):可以理解为CPU空闲量的百分比
by (instance):表示的是所有节点
查询1分钟平均负载超过主机CPU数量两倍的时间序列
node_load1 > on (instance) 2 * count (node_cpu_seconds_total{mode='idle'})by (instance)
node_load5
node_load15
1、5、15分钟的cpu负载
一般来说以上的值不能长时间大于CPU核心数量
内存使用率
node_memory_MemTotal_bytes
node_memory_MemFree_bytes
node_memory_Buffers_bytes
node_memory_Cached_ bytes
计算使用率:
可用空间:以上后三个指标之和
己用空间:总空间减去可用空间
使用率:己用空间除以总空间
三、部署service discovery服务发现
1、Prometheus指标抓取的生命周期
隐藏敏感数据 整合多个标签，来进行单个自定义指标数据的输出
发现——> 配置 ——> relabel(配置定义/服务自身执行）——> 指标数据抓取——> metrics relabel(自定义)
基于文件的服务发现;
(定义一组资源"子"配置文件yaml格式 里面只存方需要采集的targets 信息，此种方式可以被pro动态获取到，而不需要重启)
基于DNS的服务发现;
基于API的服务发现:Kubernetes、Consul、Azure、重新标记
target重新打标
metric重新打标
基于K8s的服务发现
2、Prometheus服务发现机制
Prometheus Server的数据抓取工作于Pull模型，因而，它必需要事先知道各Target的位置，然后才能从相应的Exporter或Instrumentation中抓取数据
对于小型的系统环境来说，通过static_dpnfigs指定各Target便能解决问题，这也是最简单的配置方法;每个Targets用一个网络端点(ip:port）进行标识;
对于中大型的系统环境或具有较强动态性的云计算环境来说，静态配置显然难以适用;
因此，Prometheus为此专门设计了一组服务发现机制，以便于能够基于服务注册中心（服务总线）自动发现、检测、分类可被监控的各Target，以及更新发生了变动的Target指标抓取的生命周期
在每个scrape_interval期间，Prometheus都会检查执行的作业(Job);这些作业首先会根据
Job上指定的发现配置生成target列表，此即服务发现过程;服务发现会返回一个Target列表，其中包含一组称为元数据的标签，这些标签都以" meta_"为前缀;
服务发现还会根据目标配置来设置其它标签，这些标签带有"“前缀和后缀，b包括"scheme”、 " address"和" metrics path_"，分别保存有target支持使用协议(http或https，默认为http) 、 target的地址及指标的URI路径（默认为/metrics) ;
若URI路径中存在任何参数，则它们的前缀会设置为" param"这些目标列表和标签会返回给Prometheus，其中的一些标签也可以配置中被覆盖;
配置标签会在抓取的生命周期中被重复利用以生成其他标签，例如，指标上的instance标签的默认值就来自于address标签的值;
对于发现的各目标，Prometheus提供了可以重新标记（relabel）目标的机会，它定义在job配置段的relabel_config配置中，常用于实现如下功能
以上的8条——>详细版的prometheus工作生命周期
将来自服务发现的元数据标签中的信息附加到指标的标签上
过滤目标（会利用于重打标签机制上）：
之后便是数据抓取，以及指标返回的过程，抓取而来的指标在保存之前，还允许用户对指标重新打标过滤的方式
它定义在job配置段的metric_relabel_configs配置中，常用于实现如下功能#册删除不必要的指标
从指标中册删除敏感或者不需要的标签
添加、编辑或者修改指标的标签值或标签格式
3、静态服务发现
修改prometheus服务器上的配置为文件，指定targets的端口上面配置过
- job_name: 'nodes'
static_config:
- targets:
-192.168.255.2:9100
-192.168.255.3:9100
-192.168.255.4:9100
4、动态发现
基于文件服务发现
192.168.255.1
基于文件的服务发现仅仅略优于静态配置的服务发现方式，它不依赖于任何平台或第三方服务，因而也是最为简单和通用的实现方式。prometheus server定期从文件中加载target信息(pro-server pull指标发现机制-job_name
获取我要pull的对象target)文件可以只用json和yaml格式，它含有定义的target列表，以及可选的标签信息，以下第一配置，能够将prometheus默认的静态配置转换为基于文件的服务发现时所需的配置;（rometheus会周期性的读取、重载此文件中的配置，从而达到动态发现、更新的操作)
[root@prometheus files_sd]# cat prometheus.yml
# my global config
# Author: MageEdu <mage@magedu.com>
# Repo: http://gitlab.magedu.com/MageEdu/prometheus-configs/
global:
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).
# 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=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
file_sd_configs:
- files:
- targets/prometheus_*.yaml
refresh_interval: 2m
# All nodes
- job_name: 'nodes'
file_sd_configs:
- files:
- targets/nodes_*.yaml
refresh_interval: 2m
[root@prometheus targets]# cat nodes_centos.yaml
- targets:
- 192.168.255.2:9100
- 192.168.255.3:9100
labels:
app: node-exporter
job: node
[root@prometheus targets]# cat prometheus_server.yaml
- targets:
- 192.168.255.1:9090
labels:
app: prometheus
job: prometheus
指定yml文件启动
[root@prometheus prometheus-2.27.1.linux-amd64]# ./prometheus --config.file=./files_sd/prometheus.yml
总结
指标类型：单调递增（计数器），可高科可低（仪表盘），平均数或者分位值（直方图），统计数据（sumamary）
PrometheusQL两种向量：
即时向量：表示的是一个时间刻度
时间范围向量：表示的是一组时间区间
即时向量选择器：在指定的时间戳上的数值（称之为即时向量样本）
范围向量选择器：在一组时间区间内的0或1或多个数值（范围向量样本）
支持多种即时向量组合形式，不支持多种时间范围向量组合形式
prometheus的配置文件
①global：全局配置 ②altermanager ：告警模块 ③rules ④scrape（服务发现）
prometheus架构模型（工作流程）
scrape收集数据方式：①exporter ②自建/内建指标 ③pushgateway
服务发现：①基于fd文件 ②基于DNS——>SRV记录 ③基于consul——>自动发现，同时利用prometheus的自身周期扫描配置文件更新项并加载的特性，实现动态更新 ④基于k8s服务发现
997
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
