第 2 章 性能指标体系与监控分析
性能调优的第一步是建立统一的指标定义与监控体系。本章从指标分类、瓶颈定位到监控架构，拆解面试中常见的三大考察角度。
面试问答卡片
问题1：如何定义微服务的核心性能指标？
考察点：指标体系的完整性、对业务与技术指标的区分、是否了解 RED 与 USE 方法。
回答框架：
- 按层次分：用户端（延迟/体验）、服务端（吞吐/错误率）、基础设施（CPU/内存/IO）。
- 采用 RED 模型（Rate, Errors, Duration）定义每个服务的黄金指标。
- 补充 USE 模型（Utilization, Saturation, Errors）用于资源层。
简短示例回答：“黄金指标包括请求速率、错误率和延迟（P50/P99）。再加资源利用率、饱和度和错误率，形成分层指标体系。例如订单服务关注 P99 响应时间和 5xx 错误率。”
可能追问：P99 vs P50 什么时候用？如何避免平均值掩盖问题？
避坑提醒：不要只列出一堆指标名字，要说明为什么选这些指标，并举例业务场景。
问题2：如何诊断微服务中的性能瓶颈？
考察点：工具链熟练度、定位方法论、是否能区分代码级与系统级瓶颈。
回答框架：
- 从全局监控切入：先看整体延迟趋势和错误率，确认问题范围。
- 链路追踪定位具体服务：使用 Jaeger/Zipkin 找到慢调用链。
- 下钻到代码/资源：Profiling（火焰图）、DB 慢查询、GC 日志。
简短示例回答：“先查 Prometheus 看各服务延迟是否突增，再通过 Jaeger 发现用户服务调用订单服务耗时 800ms，进一步用 arthas 火焰图定位到 JSON 序列化热点。”
可能追问：如果某个服务自身指标正常但整体变慢，你怎么排查？
避坑提醒：避免直接说“用工具看”而不说具体流程；强调从外到内逐层收敛。
问题3：如何设计统一的微服务监控体系？
考察点：架构设计能力、指标聚合与告警策略、选型权衡。
回答框架：
- 分层采集：基础设施层（Node Exporter）、应用层（Micrometer/Prometheus Client）、业务层（自定义 Metrics）。
- 存储与可视化：Prometheus + Grafana 作为基础方案，引入 Loki 处理日志。
- 告警规则：基于 SLO 定义告警，避免告警风暴。
简短示例回答：“采用 Prometheus 抓取各服务指标，Grafana 统一看板。对每个服务设置‘错误率 > 1% 持续 5 分钟’告警，配合告警通知到钉钉群。日志用 Loki 集中查询。”
可能追问：如何保证监控系统本身的高可用？业务指标与系统指标如何关联？
避坑提醒：不要只提工具名，要说明数据流和选型理由（如社区活跃度、性能开销）。
知识结构：性能指标分类速查表
| 层面 | 典型指标 | 采集工具 | 常见问题 |
|---|---|---|---|
| 用户端 | 首屏时间、API 延迟 | Real User Monitoring | 网络波动、CDN 未命中 |
| 应用层 | QPS、错误率、P99 延迟 | Prometheus + Micrometer | 线程池阻塞、慢 SQL |
| 基础设施层 | CPU 使用率、内存、磁盘 IO | Node Exporter, cAdvisor | 流量突增、OOM |
高频提示：面试中遇到监控相关问题时，主动提及 SLO（服务等级目标） 和 错误预算 概念，能显著提升技术深度。