[!info] related notes

• 所属 MOC：系统与服务 · 学习路线
• 前置概念：日志与 tracing、HTTP
• 后续概念：部署、性能
• 容易混淆：仅日志

Rust 可观测性

这个概念为什么出现

线上问题需要：

• 日志：事件细节
• 指标：聚合健康与 SLO
• 追踪：请求跨服务路径

日志可记录 trace_id/span_id，追踪传播上下文跨越服务边界；指标通过时间窗口、低基数维度或 exemplars 与追踪关联，不把每个 request_id/trace_id 作为指标标签。

[!abstract] 一句话理解 可观测性是用信号理解系统内部状态；Rust 服务用 tracing/metrics 导出，并与平台后端对接。

最小信号设计

场景：为请求定义最小信号集

logs:   level=info request_id=... path=/orders latency_ms=...
metrics: http_requests_total{method="GET",route="/orders",status="200"} += 1
trace:   span GET /orders  (child: db.query)

这是一份信号契约草图，不是导出器实现。结构化事件的可运行示例见 日志与 tracing；指标需 recorder/exporter，追踪需 subscriber layer、传播器与后端配置，打印一行字段不等于三类信号已落地。

• 请求计数与耗时直方图按 method、路由模板、状态等有界维度聚合；使用 /orders/:id 模板而非原始 URL 或订单 ID。
• 错误率与延迟分位由采集后的计数/分布计算；不能平均各实例的 P99 得到全局 P99。
• request_id 可以是应用标识，trace_id/span_id 属于追踪上下文，两者不必相同。采样后可能找不到每个请求的完整 trace。

结合场景再看三个关注点

1. RED/USE 等指标方法论
2. 高基数标签危险
3. 采样平衡成本

工程实践

1. 统一中间件埋点
2. 错误日志带错误链
3. 仪表盘与告警
4. 本地可关导出；在隔离环境发送已知成功/失败请求，核对计数、耗时分布、关联事件与 trace 到达后端，并在关闭时等待 exporter flush/shutdown

本节总结

• 三大支柱
• 关联 ID
• 平台化导出

自测题

1. 指标与日志如何分工？
2. 为何避免 user_id 当指标标签？

参考答案

1. 指标聚合趋势；日志排细节。
2. 高基数爆炸。

延伸阅读与资料来源

资料	类型	支撑内容
OpenTelemetry	标准	可观测
tracing-opentelemetry	生态	集成