5个真实监控场景实战：用Prometheus聚合查询解决运维难题
当监控面板上的曲线突然飙升，当告警通知接连不断轰炸你的手机，作为运维工程师的你，是否曾面对海量指标数据却无从下手？Prometheus的聚合查询功能就像一把瑞士军刀，能帮你从数据迷雾中精准定位问题。本文将带你通过五个真实场景，彻底掌握by、without和topk等聚合操作的实战技巧。
1. 场景一：快速定位K8s中CPU异常的Pod
凌晨三点，告警铃声刺破夜空——集群CPU使用率超过阈值。但面对上百个运行中的Pod，如何快速找到罪魁祸首？
sum(rate(container_cpu_usage_seconds_total{namespace="production"}[5m])) by (pod)这条查询会按Pod分组，显示每个Pod在过去5分钟内的CPU使用率总和。关键在于by (pod)，它告诉Prometheus："按pod标签分组计算"。结果可能如下：
| pod | value |
|---|---|
| frontend-abc123 | 0.95 |
| payment-service-xyz | 2.37 |
| redis-master | 0.12 |
实战技巧：
- 结合
topk(3, ...)快速定位最耗资源的Pod：topk(3, sum(rate(container_cpu_usage_seconds_total[5m])) by (pod)) - 排除系统组件干扰：
sum(rate(container_cpu_usage_seconds_total{namespace="production", pod!~"kube-system.*"}[5m])) by (pod)
2. 场景二：跨实例汇总微服务请求量
你的订单服务部署在10台服务器上，现在需要监控整个服务的总请求量而非单个实例。这时without就是你的最佳搭档：
sum(rate(http_requests_total{service="order-service"}[5m])) without (instance)without (instance)表示："计算时忽略instance标签"。这相当于把不同实例的数据汇总。对比两种写法：
使用by：
sum(rate(http_requests_total{service="order-service"}[5m])) by (service, method)使用without：
sum(rate(http_requests_total{service="order-service"}[5m])) without (instance)提示：当需要保留的标签较多时，用
without更简洁；当需要保留的标签较少时，用by更直观。
3. 场景三：找出磁盘即将爆满的主机
磁盘空间告警频繁触发，但每次都只显示"某台主机磁盘使用率超过85%"，如何主动发现风险主机？
topk(3, max by (instance, device) ((node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100))这个查询做了三件事：
- 计算每个挂载点的使用率百分比
- 按instance和device分组取最大值
- 筛选出使用率最高的前三个结果
进阶用法：
- 只监控特定文件系统：
topk(3, max by (instance, device) ( (node_filesystem_size_bytes{fstype=~"ext4|xfs"} - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100 )) - 设置动态阈值告警：
(node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100 > 90
4. 场景四：分析API接口的P99延迟
用户反馈系统变慢，你需要快速定位是哪个API接口的性能出了问题：
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, endpoint) )这个查询结合了聚合与分位数计算：
sum by (le, endpoint)按分桶和端点聚合histogram_quantile计算P99延迟
结果解读：
- le="0.1"表示小于100ms的请求
- 如果P99值接近某个le值，说明大部分请求在该范围内
优化技巧：
- 对比不同环境的延迟：
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{env=~"prod|staging"}[5m])) by (le, endpoint, env) ) - 监控延迟变化趋势：
max_over_time( histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, endpoint) )[1h:] )
5. 场景五：服务依赖关系拓扑分析
微服务架构中，一个服务变慢可能影响整个调用链。如何可视化服务间的依赖关系？
sum(rate(http_client_requests_seconds_count{direction="outbound"}[5m])) by (client, server)这个查询可以：
- 统计每个客户端服务对服务器服务的调用频率
- 识别异常调用模式（如某个客户端突然大量调用某个服务）
可视化技巧：
- 在Grafana中使用Node Graph面板
- 使用
label_replace增强可读性：sum(rate(http_client_requests_seconds_count{direction="outbound"}[5m])) by (client, server) * on (client) group_left label_replace(kube_deployment_labels{label_app!=""}, "client", "$1", "label_app", "(.*)")
聚合查询性能优化指南
当监控规模扩大时，不当的聚合查询可能导致Prometheus服务器过载。以下是一些实战经验：
1. 避免全量数据扫描
# 不推荐 - 扫描所有指标 sum(rate(http_requests_total[5m])) # 推荐 - 限定命名空间 sum(rate(http_requests_total{namespace="production"}[5m]))2. 合理使用记录规则将常用聚合查询预计算：
groups: - name: http.rules rules: - record: namespace:http_requests:rate5m expr: sum(rate(http_requests_total[5m])) by (namespace)3. 子查询优化技巧
# 不推荐 - 高开销子查询 max_over_time(rate(http_requests_total[5m])[1h:1m]) # 推荐 - 使用记录规则预计算 max_over_time(namespace:http_requests:rate5m[1h])4. 监控查询性能
# 查询执行时间监控 prometheus_engine_query_duration_seconds{quantile="0.9"} # 识别慢查询 topk(10, prometheus_engine_query_duration_seconds_sum)
