可观测性¶

面试追问地图¶

一、信号与指标¶

日志、指标和链路各解决什么问题？¶

• 指标适合低成本聚合趋势、看板与告警，回答“是否异常、影响多大”。
• 链路记录一次请求跨服务的因果路径，回答“慢或错在哪一段”。
• 日志保留离散事件和诊断细节，回答“当时具体发生了什么”。

三者应通过 trace_id、span_id、服务名和版本等上下文关联。不要把用户 ID、订单 ID 等无界值作为 Prometheus label，否则时序基数会失控；这些高基数字段更适合日志或按需检索的链路属性。

Prometheus 四种指标类型如何选择？¶

• Counter：只增不减（进程重启归零）的累计量，如请求数、错误数；通常配合 rate()。
• Gauge：可升可降的瞬时值，如队列长度、在用连接数。
• Histogram：按桶统计分布，并提供 count/sum；可在服务端聚合后用 histogram_quantile() 估算分位数。桶边界要围绕 SLO 设计。
• Summary：客户端在滑动窗口计算分位数；分位数通常不能跨实例正确聚合，适合聚合要求低且需客户端精度的场景。

平均值会掩盖长尾，延迟通常关注 p95/p99。但分位数也不能替代请求量和错误率：低流量服务的 p99 抖动不一定值得唤醒值班人员。

二、告警与可靠性目标¶

怎样设计可行动的告警？¶

告警应优先反映用户可见症状，如高错误率和高延迟，而不是为每个底层原因都发 Page。规则要包含持续时间，过滤短暂抖动，并附负责人、影响、看板和 Runbook。

• Page：正在造成显著用户影响，需要立即人工处理。
• Ticket：尚不紧急，但趋势会耗尽容量或可靠性预算。
• Dashboard：仅用于诊断，不主动通知。

Alertmanager 负责分组、路由、抑制和静默；这些机制用于减少重复通知，不能修复一条本身不可行动的告警。还需从外部黑盒探测监控链路本身，避免“监控和服务一起失明”。

SLI、SLO、SLA 和错误预算是什么？¶

• SLI：可测量的用户体验指标，例如成功请求比例、低于 300 ms 的请求比例。
• SLO：在明确时间窗口内对 SLI 的内部目标，例如 28 天可用性 99.9%。
• SLA：对客户的承诺，通常包含违约后果，不应与内部 SLO 混用。
• 错误预算：1 - SLO。99.9% 的 SLO 允许窗口内 0.1% 的不合格事件。

预算消耗过快时，应把工程资源从功能发布转向可靠性。告警可使用短窗口和长窗口的燃烧率组合：短窗口发现快速故障，长窗口过滤偶发噪声；它比固定 CPU 阈值更贴近 SLO 是否会被耗尽。

三、APM 与排障¶

APM 如何定位一次慢请求？¶

一次 trace 由多个 span 构成，每个 span 记录操作、父子关系、耗时、状态和必要属性。上下文通过 HTTP/RPC/消息头传播，异步消费还要保留生产与消费的关联。

排查顺序通常是：从 SLO/告警确定影响范围 → 按服务、版本、区域切分指标 → 打开代表性慢/错 trace 找关键路径 → 用关联日志确认参数、重试和异常。采样必须明确：头采样成本可控但可能漏掉罕见错误；尾采样能优先保留慢和错链路，但需要集中缓冲与更高资源成本。

参考资料¶

• Prometheus Metric Types
• Prometheus Alerting Practices
• Google SRE Workbook: Error Budget Policy
• OpenTelemetry Concepts