可观测性
可观测性通过日志、指标与 Trace 解释系统行为。本文负责信号分工、上下文、采样和聚合边界。
1. 面试核心
先记住这几条，再读正文- 三类观测信号。 指标保存聚合趋势，日志记录事件，Trace 连接调用路径。卡 · 指标
- 技术与业务关联。 Trace ID 关联技术调用，业务 ID 关联跨请求流程。
- 延迟分布聚合。 Histogram 可聚合分布，多个实例的 P99 无法直接取平均。卡 · 分位数聚合
- 尾部采样范围。 Tail sampling 仅能选择已到达采样器的数据。卡 · 尾部采样的完整性
- 标签基数。 高基数标签会增加时间序列数量与存储成本。
2. 指标
Counter 记录累计量，gauge 记录当前值。Histogram 记录观测值分布，可用于计算延迟分位数。
告警优先关注成功率与延迟等用户 SLI。CPU、队列与连接池用于解释资源饱和。
route、region 和 version 适合作为受控标签。用户 ID 与订单号会生成大量时间序列。它们更适合放入有权限控制的日志或 Trace。
3. 结构化日志
日志用稳定字段记录时间、服务、版本与事件。错误类型、Trace ID 和必要业务键用于检索。
完整异常栈在负责处理的边界记录。逐层重复打印会放大存储与错误计数。
日志过滤 token、密码和敏感请求内容。预期业务拒绝使用对应事件级别。调试日志需限定范围和持续时间。
4. Trace
Trace 由多个 span 组成。span 记录父子关系、时间、状态和受控属性。
跨 HTTP、RPC 和消息边界传播上下文。已埋点阶段可呈现调用耗时与重试次数。未埋点的队列与线程等待需另加观测。
异步消费和批量消息可用 span link 关联来源。并行 span 会重叠，耗时相加会重复计数。
5. 关联 ID
Trace ID 用于一次技术调用的追踪。订单或任务 ID 跨多次请求保持业务关联。
外部 request ID 需验证格式与长度。内部可生成可信标识并保存映射。查询权限同时约束这些业务标识的使用范围。
6. 采样
Head sampling 在入口阶段作出决定。它成本较低，但无法预知后续错误。
Tail sampling 等待更多 span，再按错误或延迟选择。它需要缓冲、状态管理和额外资源。
核心请求量与错误率由独立指标完整统计。安全审计使用明确的留存管道。故障时提高 Trace 采样率，也需限制范围与时间。
7. 上下文传播
W3C traceparent 传递 Trace 与父 span 标识。baggage 则传递额外属性，例如受控实验标签。
baggage 会传播到下游，应限制大小与敏感字段。授权使用独立安全机制。
线程池、Future 与消息回调需传播上下文。任务完成后清理上下文，防止串到后续任务。
8. 告警下钻
- 用指标确认时间窗口、区域和服务版本。
- 选择慢或错误 Trace，定位关键路径。
- 按 Trace ID 查询事件日志与异常详情。
- 核对对应组件的资源与依赖指标。
- 修复后比较同一 SLI 和等待指标。
单条 Trace 用于解释样本。整体影响范围需回到聚合指标验证。
9. 遥测管道
应用使用有界队列与批量导出。后端变慢时按预设策略丢弃普通遥测，保护业务延迟。
监控 dropped spans、队列容量和 exporter 错误。审计数据使用单独的可靠性与留存策略。
10. 分位数聚合
分位数来自分布，实例 P99 平均后失去请求权重。Prometheus 经典 histogram 可先聚合 bucket，再计算分位数。
histogram_quantile(
0.99,
sum by (le, route) (rate(http_request_duration_seconds_bucket[5m]))
)
该示例假定实例使用相同 bucket 边界。结果是按 route 聚合的五分钟 P99 估计值。精度取决于 bucket 分布与请求数量。
Summary 预先算出的分位数无法这样合并。Histogram 的 bucket 应覆盖业务延迟目标附近。
11. 尾部采样的完整性
Tail sampling 只能处理收到的 span。上游 head sampler 已丢弃的请求无法恢复。
同一 Trace 的 span 需汇聚到同一决策节点。等待窗口过短会遗漏迟到 span。缓冲溢出也会降低错误样本保留率。
因此，采样结果需结合丢弃指标判断。未查到 Trace 时，还应检查采样与导出链路。
12. 常见问题
12.1 Trace 与事件日志
Trace 展示调用关系，日志保存状态变化与异常细节。按 Trace ID 关联两者即可。重复复制完整日志会增加成本和敏感信息扩散。
12.2 Correlation ID 与 Trace ID
单次同步请求可使用同一个关联标识。跨请求业务流程更适合使用独立业务 ID。标准 Trace ID 继续用于技术链路追踪。
13 · 面试题卡片
13.1 日志、指标和 Trace 各自能证明什么，如何关联排障
出现公司：月之暗面
考察重点
- 理解聚合趋势、事件详情和单请求因果链。
- 理解trace context、业务关联 ID 和异步传播。
- 理解高基数、采样、隐私与遥测背压。
参考回答
指标描述总体趋势，Trace 解释调用样本，日志补充事件细节。
三者按时间、版本和 Trace ID 关联。排障从 SLI 确认范围，再看慢 span 与对应日志。
业务 ID 连接跨请求流程，避免作为无界指标标签。Trace 采样控制成本，完整请求统计由独立指标承担。遥测导出使用有界缓冲，并监控丢弃情况。
13.2 多个实例的 P99 可以直接取平均吗？
出现公司：暂无已核验的公开来源（本站自测）
考察重点：分布聚合、bucket 与估算误差。
相关内容：分位数聚合。
参考回答
应聚合延迟分布后重新计算 P99。
实例 P99 的平均值缺少完整分布与请求权重。经典 histogram 先按相同 bucket 求和，再用 histogram_quantile 计算。Summary 的预计算分位数无法直接合并。
13.3 使用尾部采样后，为什么仍会查不到错误 Trace？
出现公司：暂无已核验的公开来源（本站自测）
考察重点：前置丢弃、汇聚与等待窗口。
相关内容：尾部采样的完整性。
参考回答
错误 Trace 仍会因前置采样或导出丢失而缺失。
Tail sampler 只能选择收到的数据。同一 Trace 还需汇聚到同一决策节点。排查时核对 head 采样、等待窗口和缓冲丢弃。