别再死记硬背了！用这5个真实监控场景，彻底搞懂Prometheus聚合查询（by/sum/topk实战）

5个真实监控场景实战：用Prometheus聚合查询解决运维难题

当凌晨三点收到磁盘告警时，你是否曾对着几十台主机的监控数据手足无措？Prometheus的聚合查询功能就像瑞士军刀，能帮你从数据洪流中精准提取关键信息。本文将带你用5个真实场景，彻底掌握by、sum、topk等操作符的实战用法。

1. 磁盘告警：快速定位问题主机

收到"磁盘使用率超过90%"的告警时，第一反应往往是："到底哪几台主机最危险？"传统做法是逐个查看主机指标，而topk配合by能瞬间给出答案：

topk(3, max by (instance, mountpoint) ( node_filesystem_usage_percent{mountpoint!~"tmpfs|/boot"} ) )

关键点解析：

• node_filesystem_usage_percent是节点导出器提供的磁盘使用率指标
• !~"tmpfs|/boot"排除临时文件系统和/boot分区
• max by (instance, mountpoint)按主机和挂载点分组取最大值
• topk(3, ...)筛选最严重的3条记录

实际使用中发现，生产环境建议加上and node_filesystem_avail_bytes > 1GB条件，避免小容量系统分区干扰判断

2. 服务监控：排除测试环境干扰

计算生产环境总QPS时，测试环境的流量常会造成数据污染。用without可以优雅解决：

sum without (environment) ( rate(http_requests_total{environment="prod"}[5m]) )

对比两种常见错误写法：

1. 直接求和未过滤环境：sum(rate(http_requests_total[5m]))
2. 过滤后未聚合：rate(http_requests_total{environment="prod"}[5m])

进阶技巧：当需要同时显示各环境QPS时，改用by：

sum by (environment) ( rate(http_requests_total[5m]) )

3. 容量规划：预测磁盘耗尽时间

单纯看剩余空间绝对值会误导判断——1TB对日志分区可能撑不过一周，而对系统分区则绰绰有余。用predict_linear结合聚合更科学：

topk(5, predict_linear( node_filesystem_avail_bytes{mountpoint!~"tmpfs"}[1w], 7 * 86400 ) ) < 0

实现原理：

1. 基于1周历史数据([1w])预测7天(7*86400秒)后的剩余空间
2. topk(5, ...) < 0筛选出最早耗尽的5个分区
3. 结果小于0表示将在预测时间内耗尽

4. 异常检测：发现突增流量服务

用avg_over_time结合by找出QPS突增200%的服务：

rate(http_requests_total[5m]) / avg_over_time(http_requests_total[1h]) by (service) > 3

操作指南：

1. 分子rate(...[5m])计算当前5分钟QPS
2. 分母avg_over_time(...[1h])取1小时平均QPS
3. by (service)确保按服务分组计算
4. > 3筛选当前流量是均值3倍以上的服务

5. 资源优化：识别低效API端点

用bottomk找出响应时间最差但调用量少的API，这些是优化性价比最高的目标：

bottomk(5, avg by (endpoint) ( rate(http_request_duration_seconds_sum[1h]) / rate(http_request_duration_seconds_count[1h]) ) ) * on (endpoint) group_left count by (endpoint) ( rate(http_request_duration_seconds_count[1h]) ) < 100

解读说明：

1. 第一部分计算各端点平均响应时间
2. * on (endpoint) group_left关联该端点的调用量
3. < 100筛选每小时调用量不足100次的端点
4. 最终得到：响应慢且调用少的"低效端点黑名单"

避坑指南：聚合查询常见误区

1. 错误：直接对计数器求和

   sum(http_requests_total) # 错误！

   正确：先做rate或increase

   sum(rate(http_requests_total[5m]))

2. 错误：忽略by导致维度爆炸

   sum(rate(api_latency_seconds[5m])) # 混合所有维度

   正确：明确聚合维度

   sum by (service, endpoint) ( rate(api_latency_seconds[5m]) )

3. 错误：在Grafana中滥用$__interval

   sum(rate(metric[$__interval])) # 可能导致数据不准

   正确：固定合理区间

   sum(rate(metric[5m])) # 根据指标特性选择固定窗口