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億級系統的穩定性保障，在監控告警、故障處理、性能優化方面有豐富實戰經驗。