![]()
生產系統一定會崩。這不是悲觀,是物理定律。問題從來不是云原生應用會不會出問題,而是你能不能趕在用戶感知之前定位并修復。
可觀測性(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的分析顯示,工程師能直達根因而不用到處翻找時,開發效率顯著提升。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.