[!info] 关联笔记

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

Rust 可观测性

这个概念为什么出现

线上问题需要：

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

三者用同一 request_id/trace_id 关联。

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

最小可运行示例

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

logs:   level=info request_id=... path=/orders latency_ms=...
metrics: http_requests_total{code=200}++
trace:   span GET /orders  (child: db.query)

fn main() {
    // 业务意图：定义上线最小可观测清单。
    println!("request_id=req-1 path=/orders latency_ms=12 code=200");
}

结合场景再看三个关注点

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

工程实践

1. 统一中间件埋点
2. 错误日志带错误链
3. 仪表盘与告警
4. 本地可关导出

本节总结

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

自测题

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

参考答案

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

延伸阅读与资料来源

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