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

前言：在云原生時(shí)代，Prometheus已經(jīng)成為監(jiān)控領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。作為一名資深運(yùn)維工程師，我見過太多團(tuán)隊(duì)在PromQL查詢上踩坑，也見過太多因?yàn)楸O(jiān)控不到位導(dǎo)致的生產(chǎn)事故。今天分享10個(gè)實(shí)戰(zhàn)中最常用的PromQL查詢案例，每一個(gè)都是血淚經(jīng)驗(yàn)的總結(jié)。

為什么PromQL是運(yùn)維工程師的必備技能？

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

?強(qiáng)大的時(shí)間序列處理能力：支持復(fù)雜的數(shù)學(xué)運(yùn)算和聚合函數(shù)

?靈活的標(biāo)簽選擇器：精確定位目標(biāo)指標(biāo)

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

?實(shí)時(shí)查詢能力：支持即時(shí)查詢和范圍查詢

掌握PromQL不僅能提高工作效率，更能在關(guān)鍵時(shí)刻快速定位問題，避免生產(chǎn)事故的擴(kuò)大。

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

場景描述

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

實(shí)戰(zhàn)查詢

# 查詢單個(gè)實(shí)例的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

關(guān)鍵知識(shí)點(diǎn)

?rate()函數(shù)用于計(jì)算Counter類型指標(biāo)的變化率

?node_cpu_seconds_total是累積指標(biāo)，需要用rate計(jì)算實(shí)時(shí)使用率

?by (instance)用于按實(shí)例分組聚合

?mode="idle"表示空閑時(shí)間，用100%減去空閑率得到使用率

實(shí)戰(zhàn)經(jīng)驗(yàn)

在實(shí)際應(yīng)用中，建議設(shè)置多級(jí)告警閾值：

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

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

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

案例2：內(nèi)存使用率精確計(jì)算

場景描述

內(nèi)存監(jiān)控比CPU更復(fù)雜，因?yàn)?a target="_blank">Linux系統(tǒng)的內(nèi)存管理機(jī)制導(dǎo)致簡單的(總內(nèi)存-可用內(nèi)存)/總內(nèi)存計(jì)算方式并不準(zhǔn)確。我們需要考慮緩存、緩沖區(qū)等因素。

實(shí)戰(zhàn)查詢

# Linux系統(tǒng)準(zhǔn)確的內(nèi)存使用率計(jì)算
(
 (node_memory_MemTotal_bytes - node_memory_MemFree_bytes -
 node_memory_Buffers_bytes - node_memory_Cached_bytes) /
 node_memory_MemTotal_bytes
) * 100

# 內(nèi)存可用率計(jì)算
(
 (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

# 內(nèi)存壓力告警（使用率>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
)

關(guān)鍵知識(shí)點(diǎn)

?node_memory_MemAvailable_bytes是最準(zhǔn)確的可用內(nèi)存指標(biāo)

? Cache和Buffer在內(nèi)存緊張時(shí)可以被釋放，不應(yīng)計(jì)入已用內(nèi)存

? Swap使用率過高通常表明系統(tǒng)存在內(nèi)存壓力

實(shí)戰(zhàn)經(jīng)驗(yàn)

內(nèi)存告警策略建議：

?預(yù)警：內(nèi)存使用率 > 80%

?告警：內(nèi)存使用率 > 90% 或 Swap使用率 > 30%

?嚴(yán)重告警：內(nèi)存使用率 > 95% 且 Swap使用率 > 50%

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

場景描述

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

實(shí)戰(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])

關(guān)鍵知識(shí)點(diǎn)

? 使用fstype!~"tmpfs|fuse.lxcfs|squashfs"過濾掉虛擬文件系統(tǒng)

?node_disk_io_time_seconds_total表示磁盤忙碌時(shí)間

? IOPS和帶寬是衡量磁盤性能的重要指標(biāo)

實(shí)戰(zhàn)經(jīng)驗(yàn)

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

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

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

?預(yù)測告警：基于歷史數(shù)據(jù)預(yù)測磁盤空間耗盡時(shí)間

案例4：網(wǎng)絡(luò)流量與連接數(shù)監(jiān)控

場景描述

網(wǎng)絡(luò)監(jiān)控對(duì)于web應(yīng)用和微服務(wù)架構(gòu)至關(guān)重要。網(wǎng)絡(luò)異常往往是服務(wù)不可用的第一個(gè)征兆。

實(shí)戰(zhàn)查詢

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

# 網(wǎng)絡(luò)發(fā)送流量（bytes/s）
rate(node_network_transmit_bytes_total{device!~"lo|docker.*|veth.*"}[5m])

# 網(wǎng)絡(luò)接收包速率（packets/s）
rate(node_network_receive_packets_total{device!~"lo|docker.*|veth.*"}[5m])

# 網(wǎng)絡(luò)錯(cuò)誤包率
rate(node_network_receive_errs_total[5m]) +
rate(node_network_transmit_errs_total[5m])

# TCP連接狀態(tài)統(tǒng)計(jì)
node_netstat_Tcp_CurrEstab

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

關(guān)鍵知識(shí)點(diǎn)

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

? 網(wǎng)絡(luò)錯(cuò)誤包率異常通常表明硬件或驅(qū)動(dòng)問題

? TCP連接數(shù)過多可能導(dǎo)致端口耗盡

實(shí)戰(zhàn)經(jīng)驗(yàn)

網(wǎng)絡(luò)監(jiān)控要點(diǎn)：

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

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

?錯(cuò)誤率監(jiān)控：網(wǎng)絡(luò)錯(cuò)誤率應(yīng)接近0

案例5：應(yīng)用服務(wù)可用性監(jiān)控

場景描述

對(duì)于web應(yīng)用，我們需要監(jiān)控服務(wù)的可用性、響應(yīng)時(shí)間和錯(cuò)誤率。這些指標(biāo)直接關(guān)系到用戶體驗(yàn)。

實(shí)戰(zhàn)查詢

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

# HTTP請求錯(cuò)誤率
sum(rate(http_requests_total{status=~"4..|5.."}[5m])) /
sum(rate(http_requests_total[5m])) * 100

# 按狀態(tài)碼統(tǒng)計(jì)請求量
sum(rate(http_requests_total[5m])) by (status)

# 平均響應(yīng)時(shí)間
sum(rate(http_request_duration_seconds_sum[5m])) /
sum(rate(http_request_duration_seconds_count[5m]))

# P95響應(yīng)時(shí)間
histogram_quantile(0.95,
 sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

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

關(guān)鍵知識(shí)點(diǎn)

?histogram_quantile()用于計(jì)算百分位數(shù)

?topk()函數(shù)用于獲取Top-K結(jié)果

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

實(shí)戰(zhàn)經(jīng)驗(yàn)

服務(wù)可用性SLA建議：

?可用性：99.9%（年停機(jī)時(shí)間 < 8.77小時(shí)）

?響應(yīng)時(shí)間：P95 < 500ms，P99 < 1s

?錯(cuò)誤率：< 0.1%

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

場景描述

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

實(shí)戰(zhàn)查詢

# MySQL連接數(shù)使用率
mysql_global_status_threads_connected /
mysql_global_variables_max_connections * 100

# MySQL QPS（每秒查詢數(shù)）
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復(fù)制延遲
mysql_slave_lag_seconds

# PostgreSQL活躍連接數(shù)
pg_stat_activity_count{state="active"}

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

關(guān)鍵知識(shí)點(diǎn)

? 數(shù)據(jù)庫連接數(shù)不能超過最大連接數(shù)的80%

? 慢查詢率應(yīng)該控制在1%以下

? 緩沖池命中率應(yīng)該在95%以上

實(shí)戰(zhàn)經(jīng)驗(yàn)

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

?連接數(shù)告警：> 80%最大連接數(shù)

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

?慢查詢優(yōu)化：定期分析慢查詢?nèi)罩?/p>

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

場景描述

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

實(shí)戰(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內(nèi)存使用率
sum(container_memory_usage_bytes{pod!=""}) by (pod) /
sum(container_spec_memory_limit_bytes{pod!=""}) by (pod) * 100

# 每個(gè)Namespace的Pod數(shù)量
count(kube_pod_info) by (namespace)

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

# Node節(jié)點(diǎn)可調(diào)度Pod數(shù)量
kube_node_status_allocatable{resource="pods"}

# Deployment副本數(shù)監(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

關(guān)鍵知識(shí)點(diǎn)

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

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

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

實(shí)戰(zhàn)經(jīng)驗(yàn)

K8s監(jiān)控要點(diǎn)：

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

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

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

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

場景描述

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

實(shí)戰(zhàn)查詢

# JVM堆內(nèi)存使用率
jvm_memory_bytes_used{area="heap"} /
jvm_memory_bytes_max{area="heap"} * 100

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

# JVM垃圾回收平均時(shí)間
rate(jvm_gc_collection_seconds_sum[5m]) /
rate(jvm_gc_collection_seconds_count[5m])

# 線程池活躍線程數(shù)
jvm_threads_current{state="runnable"}

# 應(yīng)用啟動(dòng)時(shí)間監(jiān)控
process_start_time_seconds

# 類加載數(shù)量
jvm_classes_loaded

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

關(guān)鍵知識(shí)點(diǎn)

? JVM指標(biāo)需要應(yīng)用集成相應(yīng)的metrics庫

? 垃圾回收時(shí)間過長會(huì)影響應(yīng)用響應(yīng)時(shí)間

? 線程數(shù)過多可能導(dǎo)致上下文切換開銷

實(shí)戰(zhàn)經(jīng)驗(yàn)

JVM調(diào)優(yōu)建議：

?堆內(nèi)存：使用率保持在70-80%

?GC頻率：控制在合理范圍內(nèi)

?GC時(shí)間：單次GC時(shí)間 < 100ms

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

場景描述

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

實(shí)戰(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調(diào)用量異常檢測（基于歷史數(shù)據(jù)）
(
 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])

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

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

關(guān)鍵知識(shí)點(diǎn)

? 業(yè)務(wù)指標(biāo)需要應(yīng)用主動(dòng)上報(bào)

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

?avg_over_time()用于計(jì)算時(shí)間窗口內(nèi)的平均值

實(shí)戰(zhàn)經(jīng)驗(yàn)

業(yè)務(wù)監(jiān)控實(shí)踐：

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

?異常檢測：基于歷史數(shù)據(jù)建立基線

?實(shí)時(shí)告警：業(yè)務(wù)指標(biāo)異常需要立即響應(yīng)

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

場景描述

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

實(shí)戰(zhàn)查詢

# 系統(tǒng)整體健康評(píng)分
(
 # CPU權(quán)重0.3
 (100 - avg(100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100))) * 0.3 +
 # 內(nèi)存權(quán)重0.3 
 (100 - avg((node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100)) * 0.3 +
 # 網(wǎng)絡(luò)權(quán)重0.2
 (100 - avg(rate(node_network_receive_errs_total[5m]) + rate(node_network_transmit_errs_total[5m])) * 100) * 0.2 +
 # 應(yīng)用權(quán)重0.2
 (avg(sum(rate(http_requests_total{status=~"2.."}[5m])) / sum(rate(http_requests_total[5m])) * 100)) * 0.2
)

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

# SLI計(jì)算：延遲（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

# 錯(cuò)誤預(yù)算消耗速率
(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)

關(guān)鍵知識(shí)點(diǎn)

? 綜合健康評(píng)分需要合理設(shè)置各指標(biāo)權(quán)重

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

? 錯(cuò)誤預(yù)算是平衡可靠性和迭代速度的重要工具

實(shí)戰(zhàn)經(jīng)驗(yàn)

SLI/SLO實(shí)施建議：

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

?合理設(shè)置目標(biāo)：SLO要具有挑戰(zhàn)性但可達(dá)到

?定期回顧：根據(jù)業(yè)務(wù)發(fā)展調(diào)整SLO

PromQL進(jìn)階技巧與最佳實(shí)踐

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

# 使用record規(guī)則預(yù)計(jì)算復(fù)雜指標(biāo)
# recording rule示例
groups:
 - name: cpu_utilization
  rules:
  - record: instancerate5m
   expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)

# 使用標(biāo)簽選擇器減少查詢范圍
sum(rate(http_requests_total{service="api", environment="prod"}[5m]))

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

2. 告警規(guī)則設(shè)計(jì)原則

# 告警規(guī)則應(yīng)該包含for子句避免瞬時(shí)告警
- 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"

# 使用增加和減少函數(shù)計(jì)算變化量
- alert: DiskSpaceRunningOut
 expr: predict_linear(node_filesystem_free_bytes[1h], 4*3600) < 0
? for: 5m
? labels:
? ? severity: critical

3. 性能優(yōu)化建議

?使用recording rules：預(yù)計(jì)算復(fù)雜查詢

?合理設(shè)置抓取間隔：根據(jù)指標(biāo)變化頻率調(diào)整

?使用標(biāo)簽過濾：減少不必要的時(shí)間序列

?避免高基數(shù)標(biāo)簽：防止內(nèi)存占用過高

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

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

1.基礎(chǔ)設(shè)施監(jiān)控：CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)

2.應(yīng)用層監(jiān)控：服務(wù)可用性、性能指標(biāo)

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

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

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

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

監(jiān)控體系建設(shè)要點(diǎn)

?分層監(jiān)控：從基礎(chǔ)設(shè)施到業(yè)務(wù)應(yīng)用

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

?快速響應(yīng)：建立有效的告警機(jī)制

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

結(jié)語

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

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

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

關(guān)注我，獲取更多運(yùn)維干貨：

? 微服務(wù)監(jiān)控最佳實(shí)踐

? Kubernetes生產(chǎn)環(huán)境運(yùn)維指南

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

? 云原生架構(gòu)設(shè)計(jì)模式

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