谷歌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的分析显示，工程师能直达根因而不用到处翻找时，开发效率显著提升。