这一章里,把可观测性看成“摄像头、传感器和报警中心”。城市不可能永远不出事,但至少你要第一时间知道哪条街出问题了。
#OpenTelemetry —— 统一埋点标准
trace / metric / logOpenTelemetry 不是最终产品界面,它更像统一车牌系统:
- 统一上下文
- 统一 trace / metric / log 语义
- Collector 可以把数据转发给不同后端
#Prometheus —— 指标采集中心
scrape metrics -> store -> alertPrometheus 擅长看“整体趋势”:
- QPS
- 延迟
- 错误率
- CPU / 内存
#Grafana —— 可视化大屏
Grafana 本身更像观测前台:
- 接多个数据源
- 做 dashboard
- 做统一告警面板
#Sentry —— 异常报警中心
Sentry 特别擅长:
- 线上异常告警
- stack trace
- release 关联
- 前后端错误定位
- 性能问题与用户影响关联
可观测性的本质:
| 维度 | 看什么 |
|---|---|
| Trace | 一次请求走过了哪些服务 |
| Metrics | QPS、延迟、错误率、CPU、内存 |
| Logs | 具体发生了什么 |
| Error Monitoring | 哪段代码炸了、影响谁 |
很多团队只做日志,不做 tracing;结果出了跨服务问题,只能在城市里一条街一条街地找人。
一条现实里的排障链路:
E2E 发现“下单失败”
-> Sentry 告诉你哪次异常炸了
-> Trace 告诉你卡在网关、库存还是支付
-> Prometheus 告诉你这是局部抖动还是系统性退化
-> Logs 补上细节