写八条 PromQL 查询
目标
通过将八个 PromQL 查询写入文件，会考虑速率顺序、文件保存和最小流量门等实际规则。这是测试比例最大的领域，为 28%，这里犯的大多数错误都是无错误返回错误答案的类型。
为什么它很重要？
PromQL 困难的原因不是语法，而是即使是错误也很安静。sum第二rate如果不放在外面，价值就会很低。by (le)如果省略，则将显示任何数字而不是分位数，并且如果没有最低流量门，则在清晨的每个低流量路段都会出现幽灵通知。这三个在仪表板上都显示正常。因此，应该根据“它们在什么条件下撒谎”而不是“它们有效吗？”来审查查询。此练习将该评论嵌入到每个查询中。
步骤
1./root/pca-promql/01-request-rate.promql写下每条路由每秒的请求率。指标是http_requests_total, Windows 是[5m]，聚合标签是route没看到。
2./root/pca-promql/02-error-ratio.promql写下每条路线的 5xx 错误率。该分子是status_class="5xx"过滤通过rate，分母是整数rate, 两侧by (route)通过计数来划分。
3./root/pca-promql/03-p99-route.promql将每条路线的 p99 延迟写入 .histogram_quantile(0.99, ...)里面http_request_duration_seconds_bucket到[5m]给它一个价格by (le, route)它被计算为 .
4./root/pca-promql/04-cardinality-topk.promql编写一个查询来选择时间序列最多的前 10 个指标。topk(10, ...)里面count by (__name__)，目标选择器是{__name__=~".+"}没看到。
5./root/pca-promql/05-disk-predict.promql将磁盘耗尽预测写入 .predict_linear(node_filesystem_avail_bytes{mountpoint="/data"}[6h], 4 * 3600) < 0，当前松弛比为< 0.2条件（node_filesystem_avail_bytes投掷node_filesystem_size_bytes除以 )and将其与 系在一起。
6./root/pca-promql/06-nan-guard.promql编写一个具有低流量保护的错误率通知表达式。与步骤 2 中的比例相同> 0.01同时sum(rate(http_requests_total[5m])) by (route) > 1第二and将其与 系在一起。
7./root/pca-promql/07-scrape-health.promql写一个刮擦健康检查。up{job="checkout-api"} == 0班级absent(up{job="checkout-api"})投掷or将其与 系在一起。
8./root/pca-promql/08-burn-rate.promql使用多个窗口燃烧率。job:slo_errors:ratio_rate1h{job="checkout-api"} > (14.4 * 0.001),job:slo_errors:ratio_rate5m{job="checkout-api"} > (14.4 * 0.001),job:http_requests:rate5m{job="checkout-api"} > 1三个术语and将其与 系在一起。
注意
- 分级是用空格完成的。
#匹配字符串，忽略注释。您可以将其整齐地写在多行中，但完全按照指示编写指标名称、标签、窗口和数字。 - 常见错误1：
rate(sum(...))命令。评分明确拒绝这种形式。 - 常见错误 2：在步骤 3 中
by (route)只要写le省略。 - 常见错误3：步骤2中仅包含分子
by (route)附连。除法要求两个标签集匹配。
每条路由每秒的请求率
/root/pca-promql/01-request-rate.promql写下每条路由每秒的请求率。指标是http_requests_total, Windows 是[5m]，聚合标签是route没看到。
如果按原样绘制计数器，它是一条向右上方的直线。首先应用速率并汇总结果。如果您执行相反的操作，pod 重新启动重置将不会补偿。
每条路线 5xx 错误率
/root/pca-promql/02-error-ratio.promql写下每条路线的 5xx 错误率。该分子是status_class="5xx"过滤通过rate，分母是整数rate, 两侧by (route)通过计数来划分。
因为它是一个比率，所以我们需要一个分子和一个分母。分割两个向量需要匹配的标签集，因此两者必须聚合到同一维度。
每条路线 p99 延迟
/root/pca-promql/03-p99-route.promql将每条路线的 p99 延迟写入 .histogram_quantile(0.99, ...)里面http_request_duration_seconds_bucket到[5m]给它一个价格by (le, route)它被计算为 .
桶是计数器，因此首先应用速率。如果在聚合过程中丢失了文件，桶就会被压碎，导致没有错误的无意义的数字。切勿使用平均分位数的形式。
基数前 10 名诊断
/root/pca-promql/04-cardinality-topk.promql编写一个查询来选择时间序列最多的前 10 个指标。topk(10, ...)里面count by (__name__)，目标选择器是{__name__=~".+"}没看到。
要按指标名称计算时间序列的数量，请将 count 括在 name 中。选择所有指标的选择器在名称标签上使用正则表达式。有了topk，就只剩下顶层了。
磁盘耗尽预测
/root/pca-promql/05-disk-predict.promql将磁盘耗尽预测写入 .predict_linear(node_filesystem_avail_bytes{mountpoint="/data"}[6h], 4 * 3600) < 0，当前松弛比为< 0.2条件（node_filesystem_avail_bytes投掷node_filesystem_size_bytes除以 )and将其与 系在一起。
Predict_linear 将仪表的近期趋势推断为线性回归。第二个参数以秒为单位。如果只看趋势，即使在有足够空闲空间的磁盘上它也能点燃，所以把当前的空闲比率条件与 AND 放在一起。
防止低流量幽灵通知
/root/pca-promql/06-nan-guard.promql编写一个具有低流量保护的错误率通知表达式。与步骤 2 中的比例相同> 0.01同时sum(rate(http_requests_total[5m])) by (route) > 1第二and将其与 系在一起。
如果每 5 分钟有 3 个请求进来，其中 1 个请求失败，则错误率为 33%。仅根据比率情况，您每天早上都会收到通知。用 AND 附加最小流量条件。如果请求完全为0，则比率变为NaN，该情况悄然消失。
刮擦健康检查
/root/pca-promql/07-scrape-health.promql写一个刮擦健康检查。up{job="checkout-api"} == 0班级absent(up{job="checkout-api"})投掷or将其与 系在一起。
up为0的情况和up时间序列本身消失的情况是不同的。后者永远不会被值比较捕获。当没有时间序列时，将返回1的函数与OR绑定。
多窗口燃烧率
/root/pca-promql/08-burn-rate.promql使用多个窗口燃烧率。job:slo_errors:ratio_rate1h{job="checkout-api"} > (14.4 * 0.001),job:slo_errors:ratio_rate5m{job="checkout-api"} > (14.4 * 0.001),job:http_requests:rate5m{job="checkout-api"} > 1三个术语and将其与 系在一起。
长窗口确定“是否燃烧到这种程度？”，短窗口确定“是否仍在进行中？”如果没有短窗口，则即使事件结束后，通知也会保留长窗口的长度。在这里，我们将这三个项与最小流量门进行运算。请参考记录规则时间序列名称。