监控与可观测性
没有监控的系统是盲飞的。面试主线：三支柱各解决什么、告警怎么设计、核心指标看什么。
三支柱
| 支柱 | 回答的问题 | 工具 |
|---|---|---|
| 指标（Metrics） | 系统现在什么状态 | Prometheus + Grafana |
| 日志（Logs） | 具体发生了什么 | ELK / Loki |
| 链路追踪（Traces） | 一个请求经过哪些环节 | Jaeger / OpenTelemetry |
- 指标：数值型，聚合查询，用于告警和趋势（QPS、延迟、错误率、资源使用）
- 日志：事件型，全文检索，用于排查细节（错误堆栈、请求参数）
- 链路追踪：请求级，串联跨服务调用（哪个环节慢、哪个环节错），OpenTelemetry 是事实标准
- 三者的关系：指标发现异常 → 日志看细节 → 链路定位环节。面试答出这个协作流程是加分项
核心指标方法
RED 方法（服务维度）：
| 指标 | 含义 | 看什么 |
|---|---|---|
| Rate | 请求速率 | QPS 波动、突增突降 |
| Errors | 错误率 | 4xx/5xx 比例，错误突增是故障信号 |
| Duration | 延迟 | P50/P99，长尾恶化 |
USE 方法（资源维度）：Utilization（使用率）、Saturation（饱和度）、Errors（错误）。CPU 使用率、内存、磁盘 IO、连接池饱和（见连接池篇）。
业务指标不能少：订单量、支付成功率、队列积压（lag）。业务指标异常往往是故障的第一信号。
告警体系
告警闭环: 触发 → 通知 → 处理 → 复盘
| 要点 | 说明 |
|---|---|
| 告警分级 | P0 电话+IM 立即响应，P1 IM，P2 日报。别全用电话 |
| 阈值设计 | 静态阈值 + 趋势告警（突增突降比绝对值更敏感） |
| 告警疲劳 | 告警太多会麻木。规则宁少勿滥，每个告警都要能行动 |
| 告警必带上下文 | 什么服务、什么指标、持续多久、预案链接 |
关键原则：告警要有行动项（收到告警知道干什么），恢复要通知（闭环），事后复盘（为什么告警、为什么没拦住）。
生产实践清单
- 服务健康：/healthz 探活（见冗余篇）、进程存活
- 基础设施：CPU/内存/磁盘/网络，节点级
- 应用层：QPS、RT 百分位、错误率（RED）
- 依赖层：Redis/DB/MQ 的连接数、延迟、命中率
- 业务层：核心业务指标、队列积压
面试追问
- 三支柱的关系？ 指标发现异常、日志看细节、链路定位环节。协作而非替代
- RED 是什么？ Rate/Errors/Duration：请求速率、错误率、延迟。服务健康三件套
- 告警怎么设计？ 分级通知、阈值加趋势、宁少勿滥、带行动项。告警疲劳是真实问题
- 链路追踪怎么实现？ OpenTelemetry 埋点，trace_id 贯穿请求，跨服务传递（HTTP 头）。采样控制成本
- 业务指标为什么重要？ 技术指标正常但业务挂了（如支付失败率升高）才是真故障。业务指标是第一信号