prometheus复杂查询需按“过滤→聚合→变换→关联”四步链式操作：先用标签匹配精准筛选数据，再用rate()和sum by()做多维速率聚合，结合offset、predict_linear、absent()处理时序推演与空值，最后通过on()和group_left()实现跨指标关联计算。
Prometheus 的 PromQL 能力远不止简单查询，关键在于理解其数据模型（时间序列 + 标签）和函数组合逻辑。复杂计算不是靠单个函数，而是通过“过滤 → 聚合 → 变换 → 关联”四步链式操作实现的。
用 label_values 和 matchers 精准筛选原始数据
复杂计算的前提是数据干净、范围明确。别直接对 http_requests_total 全量聚合，先用标签匹配缩小上下文：
- 按业务维度过滤：
http_requests_total{job="api-server", status=~"5..", env="prod"} - 排除干扰实例：
http_requests_total{instance!="10.2.3.4:9090"} - 动态获取标签值辅助调试：
label_values(http_requests_total, endpoint)查看所有接口路径
用 rate() + sum by() 做多维速率聚合
原始计数器不能直接相减，必须先转为速率；聚合时保留关键维度，避免过早丢失信息：
- 计算各接口每秒错误率：
sum by (endpoint) (rate(http_requests_total{status=~"5.."}[5m])) - 再除以总请求量得错误占比：
sum by (endpoint) (rate(http_requests_total{status=~"5.."}[5m])) / sum by (endpoint) (rate(http_requests_total[5m])) - 注意：分母用
[5m]而非[1m]，保证时间窗口一致，避免除零或 NaN
用 offset、predict_linear 和 absent() 处理时序推演与空值
监控不只是看当前，还要预判趋势、识别异常缺失：
- 查 1 小时前的 CPU 使用率做同比：
100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) offset 1h - 预测磁盘 4 小时后是否满：
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[24h], 4 * 3600) - 检测某服务指标完全消失（非 0，是无数据）：
absent(up{job="payment-service"} == 1)，返回 1 表示已断连
用 on()、group_left() 实现跨指标关联计算
真实场景常需把不同来源的指标“拼起来”，比如用请求数 × 平均延迟 = 总延迟消耗：
- 先分别算出每实例的 QPS 和平均延迟：
qps = sum by(instance) (rate(http_requests_total[5m]))avg_lat = avg by(instance) (histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))) - 再关联相乘（用
on(instance)对齐）：qps * on(instance) group_left() avg_lat - 若延迟指标无 instance 标签，需用
group_left(job)并确保 job 值能唯一对应
写复杂 PromQL 不是堆砌函数，而是像搭积木：每一步输出仍是时间序列，下一步接着用。多用 {}[5m] 显式指定范围，少依赖默认；查不到结果先用 count() 或 count_values() 看标签分布；遇到 NaN 检查时间窗口是否对齐、标签是否完全匹配。
