PromQL實戰(zhàn)：10個常用查詢案例 - 運維工程師必備技能

前言：在云原生時代，Prometheus已經成為監(jiān)控領域的事實標準。作為一名資深運維工程師，我見過太多團隊在PromQL查詢上踩坑，也見過太多因為監(jiān)控不到位導致的生產事故。今天分享10個實戰(zhàn)中最常用的PromQL查詢案例，每一個都是血淚經驗的總結。

為什么PromQL是運維工程師的必備技能？

在微服務架構盛行的今天，系統(tǒng)復雜度呈指數級增長。傳統(tǒng)的監(jiān)控方式已經無法滿足現代化運維的需求。PromQL作為Prometheus的查詢語言，具有以下優(yōu)勢：

?強大的時間序列處理能力：支持復雜的數學運算和聚合函數

?靈活的標簽選擇器：精確定位目標指標

?豐富的內置函數：滿足各種監(jiān)控場景需求

?實時查詢能力：支持即時查詢和范圍查詢

掌握PromQL不僅能提高工作效率，更能在關鍵時刻快速定位問題，避免生產事故的擴大。

案例1：CPU使用率監(jiān)控與告警

場景描述

CPU使用率是最基礎也是最重要的監(jiān)控指標之一。在生產環(huán)境中，我們需要實時監(jiān)控各個節(jié)點的CPU使用情況，并在使用率過高時及時告警。

實戰(zhàn)查詢

# 查詢單個實例的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%減去空閑率得到使用率

實戰(zhàn)經驗

在實際應用中，建議設置多級告警閾值：

?警告級別：CPU > 70%，持續(xù)5分鐘

?嚴重級別：CPU > 85%，持續(xù)2分鐘

?緊急級別：CPU > 95%，持續(xù)1分鐘

案例2：內存使用率精確計算

場景描述

內存監(jiān)控比CPU更復雜，因為Linux系統(tǒng)的內存管理機制導致簡單的(總內存-可用內存)/總內存計算方式并不準確。我們需要考慮緩存、緩沖區(qū)等因素。

實戰(zhàn)查詢

# Linux系統(tǒng)準確的內存使用率計算
(
 (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使用率監(jiān)控
(
 (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使用率過高通常表明系統(tǒng)存在內存壓力

實戰(zhàn)經驗

內存告警策略建議：

?預警：內存使用率 > 80%

?告警：內存使用率 > 90% 或 Swap使用率 > 30%

?嚴重告警：內存使用率 > 95% 且 Swap使用率 > 50%

案例3：磁盤空間與I/O監(jiān)控

場景描述

磁盤問題是生產環(huán)境中最常見的故障原因之一。磁盤空間不足會導致應用無法寫入數據，磁盤I/O過高會嚴重影響系統(tǒng)性能。

實戰(zhàn)查詢

# 磁盤空間使用率
(
 (node_filesystem_size_bytes - node_filesystem_free_bytes) /
 node_filesystem_size_bytes
) * 100

# 排除系統(tǒng)文件系統(tǒng)的磁盤使用率
(
 (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"過濾掉虛擬文件系統(tǒng)

?node_disk_io_time_seconds_total表示磁盤忙碌時間

? IOPS和帶寬是衡量磁盤性能的重要指標

實戰(zhàn)經驗

磁盤監(jiān)控建議：

?空間告警：使用率 > 85%

?性能告警：I/O使用率 > 80% 持續(xù)5分鐘

?預測告警：基于歷史數據預測磁盤空間耗盡時間

案例4：網絡流量與連接數監(jiān)控

場景描述

網絡監(jiān)控對于web應用和微服務架構至關重要。網絡異常往往是服務不可用的第一個征兆。

實戰(zhàn)查詢

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

# 網絡發(fā)送流量（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連接狀態(tài)統(tǒng)計
node_netstat_Tcp_CurrEstab

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

關鍵知識點

? 使用device!~"lo|docker.*|veth.*"過濾掉回環(huán)和容器網絡接口

? 網絡錯誤包率異常通常表明硬件或驅動問題

? TCP連接數過多可能導致端口耗盡

實戰(zhàn)經驗

網絡監(jiān)控要點：

?流量監(jiān)控：關注突發(fā)流量和異常流量模式

?連接數監(jiān)控：防止連接池耗盡

?錯誤率監(jiān)控：網絡錯誤率應接近0

案例5：應用服務可用性監(jiān)控

場景描述

對于web應用，我們需要監(jiān)控服務的可用性、響應時間和錯誤率。這些指標直接關系到用戶體驗。

實戰(zhàn)查詢

# 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

# 按狀態(tài)碼統(tǒng)計請求量
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結果

? 監(jiān)控不同狀態(tài)碼的請求分布有助于快速定位問題

實戰(zhàn)經驗

服務可用性SLA建議：

?可用性：99.9%（年停機時間 < 8.77小時）

?響應時間：P95 < 500ms，P99 < 1s

?錯誤率：< 0.1%

案例6：數據庫性能監(jiān)控

場景描述

數據庫是應用系統(tǒng)的核心組件，數據庫性能直接影響整個系統(tǒng)的性能。我們需要監(jiān)控連接數、查詢性能、鎖等待等關鍵指標。

實戰(zhàn)查詢

# 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%以上

實戰(zhàn)經驗

數據庫監(jiān)控策略：

?連接數告警：> 80%最大連接數

?QPS監(jiān)控：關注QPS突增或驟降

?慢查詢優(yōu)化：定期分析慢查詢日志

案例7：容器與Kubernetes監(jiān)控

場景描述

在容器化環(huán)境中，我們需要監(jiān)控Pod的資源使用情況、容器狀態(tài)以及Kubernetes集群的健康狀態(tài)。

實戰(zhàn)查詢

# 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節(jié)點可調度Pod數量
kube_node_status_allocatable{resource="pods"}

# Deployment副本數監(jiān)控
kube_deployment_status_replicas_available /
kube_deployment_spec_replicas

# PVC使用率監(jiān)控
(kubelet_volume_stats_used_bytes /
kubelet_volume_stats_capacity_bytes) * 100

關鍵知識點

? 容器指標需要過濾掉系統(tǒng)容器

? Kubernetes狀態(tài)指標通過kube-state-metrics采集

? 資源配額和使用情況的監(jiān)控對于集群穩(wěn)定性至關重要

實戰(zhàn)經驗

K8s監(jiān)控要點：

?資源監(jiān)控：防止資源爭搶

?Pod狀態(tài)監(jiān)控：及時發(fā)現異常Pod

?集群容量規(guī)劃：基于歷史數據預測資源需求

案例8：應用性能指標（APM）監(jiān)控

場景描述

除了基礎設施監(jiān)控，我們還需要關注應用層面的性能指標，如JVM性能、垃圾回收、線程池等。

實戰(zhàn)查詢

# 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"}

# 應用啟動時間監(jiān)控
process_start_time_seconds

# 類加載數量
jvm_classes_loaded

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

關鍵知識點

? JVM指標需要應用集成相應的metrics庫

? 垃圾回收時間過長會影響應用響應時間

? 線程數過多可能導致上下文切換開銷

實戰(zhàn)經驗

JVM調優(yōu)建議：

?堆內存：使用率保持在70-80%

?GC頻率：控制在合理范圍內

?GC時間：單次GC時間 < 100ms

案例9：業(yè)務指標監(jiān)控與異常檢測

場景描述

技術指標只是監(jiān)控的一部分，業(yè)務指標的監(jiān)控更能反映系統(tǒng)的真實健康狀態(tài)。我們需要結合業(yè)務場景定義合適的監(jiān)控指標。

實戰(zhàn)查詢

# 用戶注冊成功率
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

# 用戶活躍度監(jiān)控
increase(active_users_total[1h])

# 錯誤日志增長率
rate(log_messages_total{level="error"}[5m])

# 業(yè)務指標趨勢預測（使用predict_linear）
predict_linear(revenue_total[1h], 3600)

關鍵知識點

? 業(yè)務指標需要應用主動上報

?predict_linear()可用于簡單的趨勢預測

?avg_over_time()用于計算時間窗口內的平均值

實戰(zhàn)經驗

業(yè)務監(jiān)控實踐：

?核心業(yè)務流程：每個關鍵環(huán)節(jié)都要有監(jiān)控

?異常檢測：基于歷史數據建立基線

?實時告警：業(yè)務指標異常需要立即響應

案例10：綜合性能大盤與SLI/SLO監(jiān)控

場景描述

將各種指標整合到綜合性能大盤中，實現全鏈路監(jiān)控，并基于SLI/SLO建立服務質量保障體系。

實戰(zhàn)查詢

# 系統(tǒng)整體健康評分
(
 # 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

# 告警疲勞度監(jiān)控
sum(increase(prometheus_notifications_total[1d])) by (alertname)

關鍵知識點

? 綜合健康評分需要合理設置各指標權重

? SLO設置要基于業(yè)務需求和歷史數據

? 錯誤預算是平衡可靠性和迭代速度的重要工具

實戰(zhàn)經驗

SLI/SLO實施建議：

?從簡單開始：先定義核心SLI

?合理設置目標：SLO要具有挑戰(zhàn)性但可達到

?定期回顧：根據業(yè)務發(fā)展調整SLO

PromQL進階技巧與最佳實踐

1. 查詢優(yōu)化技巧

# 使用record規(guī)則預計算復雜指標
# 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. 告警規(guī)則設計原則

# 告警規(guī)則應該包含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. 性能優(yōu)化建議

?使用recording rules：預計算復雜查詢

?合理設置抓取間隔：根據指標變化頻率調整

?使用標簽過濾：減少不必要的時間序列

?避免高基數標簽：防止內存占用過高

監(jiān)控體系建設總結

通過以上10個實戰(zhàn)案例，我們構建了一個完整的監(jiān)控體系：

1.基礎設施監(jiān)控：CPU、內存、磁盤、網絡

2.應用層監(jiān)控：服務可用性、性能指標

3.數據庫監(jiān)控：連接數、查詢性能

4.容器化監(jiān)控：Pod狀態(tài)、資源使用

5.業(yè)務指標監(jiān)控：關鍵業(yè)務流程

6.綜合性能大盤：全鏈路監(jiān)控視圖

監(jiān)控體系建設要點

?分層監(jiān)控：從基礎設施到業(yè)務應用

?預防為主：通過監(jiān)控預測和避免故障

?快速響應：建立有效的告警機制

?持續(xù)改進：根據實際情況優(yōu)化監(jiān)控策略

結語

作為運維工程師，掌握PromQL不僅僅是學會幾個查詢語句，更重要的是理解監(jiān)控的本質：讓系統(tǒng)狀態(tài)可觀測、可預測、可控制。

在數字化轉型的今天，運維工程師的價值不再是簡單的"救火隊員"，而是要成為業(yè)務穩(wěn)定性的保障者、系統(tǒng)性能的優(yōu)化者、技術風險的預防者。

希望這篇文章能幫助你在PromQL的道路上更進一步。如果你覺得有用，請點贊、收藏、關注！我會持續(xù)分享更多運維實戰(zhàn)經驗。

關注我，獲取更多運維干貨：

? 微服務監(jiān)控最佳實踐

? Kubernetes生產環(huán)境運維指南

? DevOps工具鏈建設實戰(zhàn)

? 云原生架構設計模式

作者簡介：10年+運維經驗，專注云原生、微服務、監(jiān)控體系建設。曾負責日PV億級系統(tǒng)的穩(wěn)定性保障，在監(jiān)控告警、故障處理、性能優(yōu)化方面有豐富實戰(zhàn)經驗。