谷歌4個黃金指標被80%團隊用錯：K8s故障排查從3小時縮到5分

生產系統一定會崩。這不是悲觀，是物理定律。問題從來不是云原生應用會不會出問題，而是你能不能趕在用戶感知之前定位并修復。

可觀測性（observability，指通過系統外部輸出推斷內部狀態的能力）就是干這個的。它比傳統監控多走一步：監控告訴你"發生了什么"，可觀測性幫你搞懂"為什么發生"。對跑微服務的團隊來說，這差的是5分鐘修復和3小時扯皮的距離。

三根支柱，互相打補丁

行業把可觀測性拆成三塊：指標、日志、鏈路。Kubernetes官方文檔說得明白——這不是三個分類，是三種互補的數據源，拼起來才是一張完整的健康圖。

指標是定量數據：響應時間、錯誤率、資源占用。系統的生命體征。

日志是定性上下文：發生了什么、什么時候、通常還有為什么。系統的日記本。

鏈路是旅程記錄：請求怎么在分布式系統里流動、在哪卡殼、在哪掛掉。系統的GPS。

每根支柱都在給另外兩根補刀。指標高效但沒上下文；日志有上下文但能淹死人；鏈路能看關系但數據量爆炸。

80%團隊在指標上犯的錯：收集100個，只看3個

大多數團隊的現狀是：指標收了一堆，真正用的沒幾個。關鍵不是多收，是收那些跟用戶體驗、業務結果直接掛鉤的。

起點是谷歌的四個黃金指標，按你的場景改：

延遲（Latency）：服務響應請求要花多久。不是平均數，要分位數——P99比平均值誠實100倍。

流量（Traffic）：系統承受多少需求。QPS、并發連接數、網絡帶寬。

錯誤（Errors）：失敗請求的比例。顯式的HTTP 500和隱式的200里包著錯誤都算。

飽和度（Saturation）：資源用了多少。CPU、內存、磁盤、隊列深度——到100%就晚了，80%就該預警。

對跑在K8s上的電商API，Prometheus配置長這樣：

groups:

- name: ecommerce_sli

rules:

- record: http_request_duration_seconds:rate5m

expr: rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])

- record: http_requests:rate5m

expr: sum(rate(http_requests_total[5m])) by (service, method)

- record: http_requests_errors:rate5m

expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)

- record: pod_cpu_utilization

expr: rate(container_cpu_usage_seconds_total[5m]) / container_spec_cpu_quota * 100

業務指標：技術到錢的直線

基礎設施指標之外，得盯對你生意真正重要的東西：

電商看購物車放棄率、支付完成率、庫存同步延遲。SaaS看租戶創建時間、API配額使用率、數據導出時長。金融看交易處理延遲、對賬失敗率、欺詐檢測誤殺率。

目標是技術指標到業務影響的直線距離。CPU飆了，你得立刻知道有沒有拖累結賬轉化率。

Stack Overflow的分析顯示，工程師能直達根因而不用到處翻找時，開發效率顯著提升。