往真的 Prometheus 上打查询

目标

向真正的 Prometheus 服务器发出查询，并读取返回的数字。完成这次实验后，你能亲手写出 rate、比率、分位数和预测，并知道写错时为什么错。

为什么重要

PromQL 的语法，一天就能背下来。难的是判断返回的数字对不对。 漏掉了 by (le) 的 histogram_quantile 不会报错—— 它只是给出一个错误的数字。把它挂在仪表板上，几个月都不会有人发现。

所以这个环境中预先放入了 12 小时的时间序列。错误飙升的区间有两段，只有 p99 突然升高的区间有一段，还有一块单调递减的磁盘。你写的查询能不能找出这些事件，就是确认答案的依据。

环境

promq "<PromQL>"      쿼리를 던진다. promq -r 로 원본 JSON
lab-status            무엇이 떠 있는지, 대상이 몇 개인지
tail -40 /var/log/lab-init.log     준비 과정 로그

该代码块中的韩文依次说明：promq 用于提交查询，加上 -r 可得到原始 JSON；lab-status 显示正在运行什么以及有多少个目标；最后一条命令用于查看准备过程的日志。

Prometheus 在 127.0.0.1:9090，示例服务的 exporter 在 9101， node_exporter 在 9100。Grafana 用 lab-start-grafana 启动，并通过 Web 预览的 3000 端口查看。

步骤

找出 http_requests_total 有哪些标签，并写入 /root/obs/01-labels.txt
把每秒请求速率的查询写入 /root/obs/02-rate.promql
把 5xx 比率的查询写入 /root/obs/03-errrate.promql
把 p95 延迟的查询写入 /root/obs/04-p95.promql
把时间序列最多的五个指标，以 이름 시계열수（占位符依次为名称、时间序列数）的格式写入 /root/obs/05-top.txt
把记录规则写入 /etc/prometheus/rules/labhub.yml
使配置生效，并确认出现了新的时间序列
把磁盘耗尽预测的查询写入 /root/obs/08-predict.promql

参考

把查询写进文件之前，请先用 promq 发出一次试试。 如果结果为空，就是标签名称写错了。
如果 promq 'up' 返回 3，说明抓取正常。
如果结果是 NaN，说明你看到的是分母为 0 的区间。

先看有哪些时间序列

找出 http_requests_total 有哪些标签，并写入 /root/obs/01-labels.txt

写查询之前，先看看有什么。用 promq 'count by (__name__)({__name__=~".+"})' 浏览指标名称，再用 promq 'http_requests_total' 查看标签。请在 /root/obs/01-labels.txt 中每行写一个 http_requests_total 的标签名称（只写名称，不写值）。

每秒请求速率

把每秒请求速率的查询写入 /root/obs/02-rate.promql

把查询写进 /root/obs/02-rate.promql，并用 promq "$(cat /root/obs/02-rate.promql)" 亲自确认。抓取间隔是 15 秒，所以范围必须至少是它的四倍，这样才不会出现只取到一个样本的时刻。rate 必须在 sum 的内侧——放在外面会错误处理计数器重置。

5xx 比率

把 5xx 比率的查询写入 /root/obs/03-errrate.promql

写进 /root/obs/03-errrate.promql。因为是比率，所以是除法，必须在分子和分母两侧都套上 rate，单位才对得上。结果在 0.004 左右是平时，超过 0.1 则说明你看到的是事故区间——这个环境中放入了两段错误飙升的区间。

p95 延迟

把 p95 延迟的查询写入 /root/obs/04-p95.promql

写进 /root/obs/04-p95.promql。用 _sum 和 _count 求不出分位数。要对桶套上 rate，并保留 le 标签地汇总，然后交给 histogram_quantile。如果去掉 by (le)，不会报错，却会得出错误的数字——所以更危险。

找出时间序列最多的指标

把时间序列最多的五个指标，以 이름 시계열수（占位符依次为名称、时间序列数）的格式写入 /root/obs/05-top.txt

基数必须实际测量才知道。运行 promq 'topk(5, count by (__name__)({__name__=~".+"}))'，把得到的表抄成五行写入 /root/obs/05-top.txt——每行是 이름 시계열수（占位符依次为名称、时间序列数），数量多的在前。如果有更多目标上线，排名就会改变。所以留下的不是某一个名称，而是当时测得的那张表。

编写记录规则文件

把记录规则写入 /etc/prometheus/rules/labhub.yml

创建 /etc/prometheus/rules/labhub.yml。结构是 groups → rules → record/expr。record 名称遵循 job:http_requests:rate5m 这样的 수준:메트릭:연산（占位符依次为层级、指标、运算）约定。保存之后，务必用 promtool check rules /etc/prometheus/rules/labhub.yml 检查。

使规则生效并确认新的时间序列

使配置生效，并确认出现了新的时间序列

不重启 Prometheus 就让它生效——curl -X POST http://127.0.0.1:9090/-/reload。等待 15 秒左右，再用 promq 'job:http_requests:rate5m' 查看是否生成了新的时间序列。规则在每个评估周期计算，所以不会立即出现。

计算磁盘什么时候会满

把磁盘耗尽预测的查询写入 /root/obs/08-predict.promql

写进 /root/obs/08-predict.promql。predict_linear 给出的是“如果当前趋势持续，N 秒后的值”。请写出一个查询，询问 node_filesystem_avail_bytes 在 6 小时后是否会降到 0 以下。这个环境中的磁盘被特意做成了单调递减。