常用PromQL查询案例总结

马哥Linux运维 2025-09-18 449

描述

PromQL实战：10个常用查询案例 - 运维工程师必备技能

前言：在云原生时代，Prometheus已经成为监控领域的事实标准。作为一名资深运维工程师，我见过太多团队在PromQL查询上踩坑，也见过太多因为监控不到位导致的生产事故。今天分享10个实战中最常用的PromQL查询案例，每一个都是血泪经验的总结。

为什么PromQL是运维工程师的必备技能？

在微服务架构盛行的今天，系统复杂度呈指数级增长。传统的监控方式已经无法满足现代化运维的需求。PromQL作为Prometheus的查询语言，具有以下优势：

• 强大的时间序列处理能力：支持复杂的数学运算和聚合函数

• 灵活的标签选择器：精确定位目标指标

• 丰富的内置函数：满足各种监控场景需求

• 实时查询能力：支持即时查询和范围查询

掌握PromQL不仅能提高工作效率，更能在关键时刻快速定位问题，避免生产事故的扩大。

案例1：CPU使用率监控与告警

场景描述

CPU使用率是最基础也是最重要的监控指标之一。在生产环境中，我们需要实时监控各个节点的CPU使用情况，并在使用率过高时及时告警。

实战查询

# 查询单个实例的CPU使用率
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)

# 查询集群整体CPU使用率
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# 按CPU核心查询使用率
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance, cpu) * 100)

# CPU使用率超过80%的告警查询
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100) > 80

关键知识点

• rate() 函数用于计算Counter类型指标的变化率

• node_cpu_seconds_total 是累积指标，需要用rate计算实时使用率

• by (instance) 用于按实例分组聚合

• mode="idle" 表示空闲时间，用100%减去空闲率得到使用率

实战经验

在实际应用中，建议设置多级告警阈值：

• 警告级别：CPU > 70%，持续5分钟

• 严重级别：CPU > 85%，持续2分钟

• 紧急级别：CPU > 95%，持续1分钟

案例2：内存使用率精确计算

场景描述

内存监控比CPU更复杂，因为Linux系统的内存管理机制导致简单的 (总内存-可用内存)/总内存计算方式并不准确。我们需要考虑缓存、缓冲区等因素。

实战查询

# Linux系统准确的内存使用率计算
(
  (node_memory_MemTotal_bytes - node_memory_MemFree_bytes - 
   node_memory_Buffers_bytes - node_memory_Cached_bytes) / 
  node_memory_MemTotal_bytes
) * 100

# 内存可用率计算
(
  (node_memory_MemAvailable_bytes) / 
  node_memory_MemTotal_bytes
) * 100

# Swap使用率监控
(
  (node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes) / 
  node_memory_SwapTotal_bytes
) * 100

# 内存压力告警（使用率>90%且Swap>50%）
(
  (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / 
  node_memory_MemTotal_bytes * 100 > 90
) 
and 
(
  (node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes) / 
  node_memory_SwapTotal_bytes * 100 > 50
)

关键知识点

• node_memory_MemAvailable_bytes 是最准确的可用内存指标

• Cache和Buffer在内存紧张时可以被释放，不应计入已用内存

• Swap使用率过高通常表明系统存在内存压力

实战经验

内存告警策略建议：

• 预警：内存使用率 > 80%

• 告警：内存使用率 > 90% 或 Swap使用率 > 30%

• 严重告警：内存使用率 > 95% 且 Swap使用率 > 50%

案例3：磁盘空间与I/O监控

场景描述

磁盘问题是生产环境中最常见的故障原因之一。磁盘空间不足会导致应用无法写入数据，磁盘I/O过高会严重影响系统性能。

实战查询

# 磁盘空间使用率
(
  (node_filesystem_size_bytes - node_filesystem_free_bytes) / 
  node_filesystem_size_bytes
) * 100

# 排除系统文件系统的磁盘使用率
(
  (node_filesystem_size_bytes{fstype!~"tmpfs|fuse.lxcfs|squashfs"} - 
   node_filesystem_free_bytes{fstype!~"tmpfs|fuse.lxcfs|squashfs"}) / 
  node_filesystem_size_bytes{fstype!~"tmpfs|fuse.lxcfs|squashfs"}
) * 100

# 磁盘I/O使用率
rate(node_disk_io_time_seconds_total[5m]) * 100

# 磁盘读写IOPS
rate(node_disk_reads_completed_total[5m]) + 
rate(node_disk_writes_completed_total[5m])

# 磁盘读写带宽
rate(node_disk_read_bytes_total[5m]) + 
rate(node_disk_written_bytes_total[5m])

关键知识点

• 使用 fstype!~"tmpfs|fuse.lxcfs|squashfs" 过滤掉虚拟文件系统

• node_disk_io_time_seconds_total 表示磁盘忙碌时间

• IOPS和带宽是衡量磁盘性能的重要指标

实战经验

磁盘监控建议：

• 空间告警：使用率 > 85%

• 性能告警：I/O使用率 > 80% 持续5分钟

• 预测告警：基于历史数据预测磁盘空间耗尽时间

案例4：网络流量与连接数监控

场景描述

网络监控对于web应用和微服务架构至关重要。网络异常往往是服务不可用的第一个征兆。

实战查询

# 网络接收流量（bytes/s）
rate(node_network_receive_bytes_total{device!~"lo|docker.*|veth.*"}[5m])

# 网络发送流量（bytes/s）
rate(node_network_transmit_bytes_total{device!~"lo|docker.*|veth.*"}[5m])

# 网络接收包速率（packets/s）
rate(node_network_receive_packets_total{device!~"lo|docker.*|veth.*"}[5m])

# 网络错误包率
rate(node_network_receive_errs_total[5m]) + 
rate(node_network_transmit_errs_total[5m])

# TCP连接状态统计
node_netstat_Tcp_CurrEstab

# TCP连接建立速率
rate(node_netstat_Tcp_PassiveOpens[5m]) + 
rate(node_netstat_Tcp_ActiveOpens[5m])

关键知识点

• 使用 device!~"lo|docker.*|veth.*" 过滤掉回环和容器网络接口

• 网络错误包率异常通常表明硬件或驱动问题

• TCP连接数过多可能导致端口耗尽

实战经验

网络监控要点：

• 流量监控：关注突发流量和异常流量模式

• 连接数监控：防止连接池耗尽

• 错误率监控：网络错误率应接近0

案例5：应用服务可用性监控

场景描述

对于web应用，我们需要监控服务的可用性、响应时间和错误率。这些指标直接关系到用户体验。

实战查询

# HTTP请求成功率
sum(rate(http_requests_total{status=~"2.."}[5m])) / 
sum(rate(http_requests_total[5m])) * 100

# HTTP请求错误率
sum(rate(http_requests_total{status=~"4..|5.."}[5m])) / 
sum(rate(http_requests_total[5m])) * 100

# 按状态码统计请求量
sum(rate(http_requests_total[5m])) by (status)

# 平均响应时间
sum(rate(http_request_duration_seconds_sum[5m])) / 
sum(rate(http_request_duration_seconds_count[5m]))

# P95响应时间
histogram_quantile(0.95, 
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

# API端点性能排行
topk(10, 
  sum(rate(http_request_duration_seconds_sum[5m])) by (endpoint) / 
  sum(rate(http_request_duration_seconds_count[5m])) by (endpoint)
)

关键知识点

• histogram_quantile() 用于计算百分位数

• topk() 函数用于获取Top-K结果

• 监控不同状态码的请求分布有助于快速定位问题

实战经验

服务可用性SLA建议：

• 可用性：99.9%（年停机时间 < 8.77小时）

• 响应时间：P95 < 500ms，P99 < 1s

• 错误率：< 0.1%

案例6：数据库性能监控

场景描述

数据库是应用系统的核心组件，数据库性能直接影响整个系统的性能。我们需要监控连接数、查询性能、锁等待等关键指标。

实战查询

# MySQL连接数使用率
mysql_global_status_threads_connected / 
mysql_global_variables_max_connections * 100

# MySQL QPS（每秒查询数）
rate(mysql_global_status_queries[5m])

# MySQL慢查询率
rate(mysql_global_status_slow_queries[5m]) / 
rate(mysql_global_status_queries[5m]) * 100

# MySQL缓冲池命中率
(mysql_global_status_innodb_buffer_pool_read_requests - 
 mysql_global_status_innodb_buffer_pool_reads) / 
mysql_global_status_innodb_buffer_pool_read_requests * 100

# MySQL复制延迟
mysql_slave_lag_seconds

# PostgreSQL活跃连接数
pg_stat_activity_count{state="active"}

# PostgreSQL缓存命中率
pg_stat_database_blks_hit / 
(pg_stat_database_blks_hit + pg_stat_database_blks_read) * 100

关键知识点

• 数据库连接数不能超过最大连接数的80%

• 慢查询率应该控制在1%以下

• 缓冲池命中率应该在95%以上

实战经验

数据库监控策略：

• 连接数告警：> 80%最大连接数

• QPS监控：关注QPS突增或骤降

• 慢查询优化：定期分析慢查询日志

案例7：容器与Kubernetes监控

场景描述

在容器化环境中，我们需要监控Pod的资源使用情况、容器状态以及Kubernetes集群的健康状态。

实战查询

# Pod CPU使用率
sum(rate(container_cpu_usage_seconds_total{pod!=""}[5m])) by (pod) / 
sum(container_spec_cpu_quota{pod!=""}/container_spec_cpu_period{pod!=""}) by (pod) * 100

# Pod内存使用率
sum(container_memory_usage_bytes{pod!=""}) by (pod) / 
sum(container_spec_memory_limit_bytes{pod!=""}) by (pod) * 100

# 每个Namespace的Pod数量
count(kube_pod_info) by (namespace)

# 不健康的Pod数量
count(kube_pod_status_phase{phase!="Running"})

# Node节点可调度Pod数量
kube_node_status_allocatable{resource="pods"}

# Deployment副本数监控
kube_deployment_status_replicas_available / 
kube_deployment_spec_replicas

# PVC使用率监控
(kubelet_volume_stats_used_bytes / 
kubelet_volume_stats_capacity_bytes) * 100

关键知识点

• 容器指标需要过滤掉系统容器

• Kubernetes状态指标通过kube-state-metrics采集

• 资源配额和使用情况的监控对于集群稳定性至关重要

实战经验

K8s监控要点：

• 资源监控：防止资源争抢

• Pod状态监控：及时发现异常Pod

• 集群容量规划：基于历史数据预测资源需求

案例8：应用性能指标（APM）监控

场景描述

除了基础设施监控，我们还需要关注应用层面的性能指标，如JVM性能、垃圾回收、线程池等。

实战查询

# JVM堆内存使用率
jvm_memory_bytes_used{area="heap"} / 
jvm_memory_bytes_max{area="heap"} * 100

# JVM垃圾回收频率
rate(jvm_gc_collection_seconds_count[5m])

# JVM垃圾回收平均时间
rate(jvm_gc_collection_seconds_sum[5m]) / 
rate(jvm_gc_collection_seconds_count[5m])

# 线程池活跃线程数
jvm_threads_current{state="runnable"}

# 应用启动时间监控
process_start_time_seconds

# 类加载数量
jvm_classes_loaded

# 应用吞吐量（TPS）
sum(rate(method_timed_sum[5m])) by (application)

关键知识点

• JVM指标需要应用集成相应的metrics库

• 垃圾回收时间过长会影响应用响应时间

• 线程数过多可能导致上下文切换开销

实战经验

JVM调优建议：

• 堆内存：使用率保持在70-80%

• GC频率：控制在合理范围内

• GC时间：单次GC时间 < 100ms

案例9：业务指标监控与异常检测

场景描述

技术指标只是监控的一部分，业务指标的监控更能反映系统的真实健康状态。我们需要结合业务场景定义合适的监控指标。

实战查询

# 用户注册成功率
sum(rate(user_registration_total{status="success"}[5m])) / 
sum(rate(user_registration_total[5m])) * 100

# 订单支付成功率
sum(rate(payment_total{status="success"}[5m])) / 
sum(rate(payment_total[5m])) * 100

# API调用量异常检测（基于历史数据）
(
  sum(rate(http_requests_total[5m]))
  - 
  avg_over_time(sum(rate(http_requests_total[5m]))[1d:5m])
) / avg_over_time(sum(rate(http_requests_total[5m]))[1d:5m]) * 100 > 50

# 用户活跃度监控
increase(active_users_total[1h])

# 错误日志增长率
rate(log_messages_total{level="error"}[5m])

# 业务指标趋势预测（使用predict_linear）
predict_linear(revenue_total[1h], 3600)

关键知识点

• 业务指标需要应用主动上报

• predict_linear() 可用于简单的趋势预测

• avg_over_time() 用于计算时间窗口内的平均值

实战经验

业务监控实践：

• 核心业务流程：每个关键环节都要有监控

• 异常检测：基于历史数据建立基线

• 实时告警：业务指标异常需要立即响应

案例10：综合性能大盘与SLI/SLO监控

场景描述

将各种指标整合到综合性能大盘中，实现全链路监控，并基于SLI/SLO建立服务质量保障体系。

实战查询

# 系统整体健康评分
(
  # CPU权重0.3
  (100 - avg(100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100))) * 0.3 +
  # 内存权重0.3  
  (100 - avg((node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100)) * 0.3 +
  # 网络权重0.2
  (100 - avg(rate(node_network_receive_errs_total[5m]) + rate(node_network_transmit_errs_total[5m])) * 100) * 0.2 +
  # 应用权重0.2
  (avg(sum(rate(http_requests_total{status=~"2.."}[5m])) / sum(rate(http_requests_total[5m])) * 100)) * 0.2
)

# SLI计算：可用性
avg_over_time(
  (sum(rate(http_requests_total{status!~"5.."}[5m])) / 
   sum(rate(http_requests_total[5m])))[30d:5m]
) * 100

# SLI计算：延迟（P99 < 1s的比例）
avg_over_time(
  (sum(rate(http_request_duration_seconds_bucket{le="1.0"}[5m])) / 
   sum(rate(http_request_duration_seconds_count[5m])))[30d:5m]
) * 100

# 错误预算消耗速率
(1 - 
  sum(rate(http_requests_total{status!~"5.."}[5m])) / 
  sum(rate(http_requests_total[5m]))
) / (1 - 0.999) * 100

# 告警疲劳度监控
sum(increase(prometheus_notifications_total[1d])) by (alertname)

关键知识点

• 综合健康评分需要合理设置各指标权重

• SLO设置要基于业务需求和历史数据

• 错误预算是平衡可靠性和迭代速度的重要工具

实战经验

SLI/SLO实施建议：

• 从简单开始：先定义核心SLI

• 合理设置目标：SLO要具有挑战性但可达到

• 定期回顾：根据业务发展调整SLO

PromQL进阶技巧与最佳实践

1. 查询优化技巧

# 使用record规则预计算复杂指标
# recording rule示例
groups:
  - name: cpu_utilization
    rules:
    - record: instancerate5m
      expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)

# 使用标签选择器减少查询范围
sum(rate(http_requests_total{service="api", environment="prod"}[5m]))

# 合理使用聚合函数
sum by (instance)(rate(node_cpu_seconds_total[5m]))

2. 告警规则设计原则

# 告警规则应该包含for子句避免瞬时告警
- alert: HighCPUUsage
  expr: instancerate5m > 80
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "High CPU usage on {{ $labels.instance }}"
    description: "CPU usage is {{ $value }}% for more than 5 minutes"

# 使用增加和减少函数计算变化量
- alert: DiskSpaceRunningOut
  expr: predict_linear(node_filesystem_free_bytes[1h], 4*3600) < 0
  for: 5m
  labels:
    severity: critical

3. 性能优化建议

• 使用recording rules：预计算复杂查询

• 合理设置抓取间隔：根据指标变化频率调整

• 使用标签过滤：减少不必要的时间序列

• 避免高基数标签：防止内存占用过高

监控体系建设总结

通过以上10个实战案例，我们构建了一个完整的监控体系：

1. 基础设施监控：CPU、内存、磁盘、网络

2. 应用层监控：服务可用性、性能指标

3. 数据库监控：连接数、查询性能

4. 容器化监控：Pod状态、资源使用

5. 业务指标监控：关键业务流程

6. 综合性能大盘：全链路监控视图

监控体系建设要点

• 分层监控：从基础设施到业务应用

• 预防为主：通过监控预测和避免故障

• 快速响应：建立有效的告警机制

• 持续改进：根据实际情况优化监控策略

结语

作为运维工程师，掌握PromQL不仅仅是学会几个查询语句，更重要的是理解监控的本质：让系统状态可观测、可预测、可控制。

在数字化转型的今天，运维工程师的价值不再是简单的"救火队员"，而是要成为业务稳定性的保障者、系统性能的优化者、技术风险的预防者。

希望这篇文章能帮助你在PromQL的道路上更进一步。如果你觉得有用，请点赞、收藏、关注！我会持续分享更多运维实战经验。

关注我，获取更多运维干货：

• 微服务监控最佳实践

• Kubernetes生产环境运维指南

• DevOps工具链建设实战

• 云原生架构设计模式

作者简介：10年+运维经验，专注云原生、微服务、监控体系建设。曾负责日PV亿级系统的稳定性保障，在监控告警、故障处理、性能优化方面有丰富实战经验。

打开APP阅读更多精彩内容