Prometheus--学习笔记

Prometheus  https://prometheus.fuckcloudnative.io/

0.数据模型

prometheus 所有采集的监控数据都以指标metric的形式保存在内置的时间序列的数据库当中TSDB：属于同一指标名称，同一标签集合的，有时间戳记的数据流。

1. 指标类型:四种核心指标类型

• Counter计数器 Inc,Add,rate,topk
• Gauge 仪表盘 dalta predict_liner
• Histogram 直方图 histogram_quantile
• summary 摘要，与histogram类似，不同点在于：关于分位数

 

原文链接：https://blog.csdn.net/wtan825/article/details/94616813

查看分位数时summary和histogram的选择

清楚几点限制：

Summary 结构有频繁的全局锁操作，对高并发程序性能存在一定影响。histogram仅仅是给每个桶做一个原子变量的计数就可以了，而summary要每次执行算法计算出最新的X分位value是多少，算法需要并发保护。会占用客户端的cpu和内存。

不能对Summary产生的quantile值进行aggregation运算（例如sum, avg等）。例如有两个实例同时运行，都对外提供服务，分别统计各自的响应时间。最后分别计算出的0.5-quantile的值为60和80，这时如果简单的求平均(60+80)/2，认为是总体的0.5-quantile值，那么就错了。

summary的百分位是提前在客户端里指定的，在服务端观测指标数据时不能获取未指定的分为数。而histogram则可以通过promql随便指定，虽然计算的不如summary准确，但带来了灵活性。

histogram不能得到精确的分为数，设置的bucket不合理的话，误差会非常大。会消耗服务端的计算资源。

两条经验

如果需要聚合（aggregate），选择histograms。

如果比较清楚要观测的指标的范围和分布情况，选择histograms。如果需要精确的分为数选择summary。

 

2. PromQL 操作符，内置函数

自查 https://prometheus.fuckcloudnative.io/di-san-zhang-prometheus/di-4-jie-cha-xun/operators

 

3. 存储

Prometheus 按照两个小时为一个时间窗口，将两小时内产生的数据存储在一个块（Block）中。

每个块都是一个单独的目录，

• 里面含该时间窗口内的所有样本数据（chunks），
• 元数据文件（meta.json）以及
• 索引文件（index）。其中索引文件会将指标名称和标签索引到样板数据的时间序列中。
• 此期间如果通过 API 删除时间序列，删除记录会保存在单独的逻辑文件 tombstone 当中。

 

示例 保存数据块的目录结构

./data

|- 01BKGV7JBM69T2G1BGBGM6KB12 # 块

|- meta.json # 元数据

|- wal # 写入日志

|- 000002

|- 000001

|- 01BKGTZQ1SYQJTR4PB43C8PD98 # 块

|- meta.json #元数据

|- index # 索引文件

|- chunks # 样本数据

|- 000001

|- tombstones # 逻辑数据

|- 01BKGTZQ1HHWHV8FBJXW1Y3W0K

|- meta.json

|- wal

|-000001