生產(chǎn)系統(tǒng)一定會(huì)崩。這不是悲觀，是物理定律。問題從來不是云原生應(yīng)用會(huì)不會(huì)出問題，而是你能不能趕在用戶感知之前定位并修復(fù)。

可觀測性（observability，指通過系統(tǒng)外部輸出推斷內(nèi)部狀態(tài)的能力）就是干這個(gè)的。它比傳統(tǒng)監(jiān)控多走一步：監(jiān)控告訴你"發(fā)生了什么"，可觀測性幫你搞懂"為什么發(fā)生"。對跑微服務(wù)的團(tuán)隊(duì)來說，這差的是5分鐘修復(fù)和3小時(shí)扯皮的距離。

三根支柱，互相打補(bǔ)丁

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

指標(biāo)是定量數(shù)據(jù)：響應(yīng)時(shí)間、錯(cuò)誤率、資源占用。系統(tǒng)的生命體征。

日志是定性上下文：發(fā)生了什么、什么時(shí)候、通常還有為什么。系統(tǒng)的日記本。

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

每根支柱都在給另外兩根補(bǔ)刀。指標(biāo)高效但沒上下文；日志有上下文但能淹死人；鏈路能看關(guān)系但數(shù)據(jù)量爆炸。

80%團(tuán)隊(duì)在指標(biāo)上犯的錯(cuò)：收集100個(gè)，只看3個(gè)

大多數(shù)團(tuán)隊(duì)的現(xiàn)狀是：指標(biāo)收了一堆，真正用的沒幾個(gè)。關(guān)鍵不是多收，是收那些跟用戶體驗(yàn)、業(yè)務(wù)結(jié)果直接掛鉤的。

起點(diǎn)是谷歌的四個(gè)黃金指標(biāo)，按你的場景改：

延遲（Latency）：服務(wù)響應(yīng)請求要花多久。不是平均數(shù)，要分位數(shù)——P99比平均值誠實(shí)100倍。

流量（Traffic）：系統(tǒng)承受多少需求。QPS、并發(fā)連接數(shù)、網(wǎng)絡(luò)帶寬。

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

飽和度（Saturation）：資源用了多少。CPU、內(nèi)存、磁盤、隊(duì)列深度——到100%就晚了，80%就該預(yù)警。

對跑在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

業(yè)務(wù)指標(biāo)：技術(shù)到錢的直線

基礎(chǔ)設(shè)施指標(biāo)之外，得盯對你生意真正重要的東西：

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

目標(biāo)是技術(shù)指標(biāo)到業(yè)務(wù)影響的直線距離。CPU飆了，你得立刻知道有沒有拖累結(jié)賬轉(zhuǎn)化率。

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