可观测性与 Tracing：把延迟打到时间线

1. 日志刷屏解决不了「谁堵了执行器」

控制环偶发 overshoot，节点里 RCLCPP_INFO 每周期打印「elapsed 12ms」——磁盘满、串口卡、仍不知道 12ms 花在哪个回调。ROS 2 tracing（LTTng + tracetools 插桩）把 executor 取任务、订阅回调、定时器触发、DDS 收包串成同一时间轴，用来回答「MutuallyExclusive 组里是不是图像解码拖死了控制定时器」。它是攻坚工具，不是日常默认全开——全量 trace 一次几分钟就数十 GB。

2. 三层分工：指标、日志、trace

层次	回答什么	典型手段
指标	趋势与 SLO	回调耗时直方图、topic hz
日志	离散事件	结构化 JSON、diagnostics
trace	因果时间线	LTTng、ros2 trace

三者不要重复建设：先把关键路径做成 Prometheus/diagnostics 直方图，仍无法定位再开短时 trace。在每个节点 printf 延迟是最贵的「可观测性」——干扰实时路径还丢上下文。

日常栈：rclcpp logger 带 node、callback 字段；diagnostic_updater 汇报 hz 与温度；关键 topic 用 ros2 topic hz 进 cron。

3. 短时 tracing 怎么开

Jazzy/Rolling 生态常用 ros2_tracing：

bash

ros2 trace -s session_001 \
  --session-name=my_debug \
  --all-events=false \
  --kernel-events=false
# 复现问题 30–60s 后 Ctrl+C
ros2 trace analyze session_001

开 trace 前写假设：「控制定时器与相机回调同组导致 jitter」。限定节点与时段，避免「录八小时再说」。分析时对齐时间基准：仿真用 /clock，多机用 PTP 或统一墙钟——轴不对齐的 trace 只能看单机内热图，不能硬比「机器人 A 比 B 慢 2ms」。

4. 与 Executor / QoS 联动分诊

延迟分诊顺序：先 ros2 topic info -v 证明 Offered/Requested QoS 匹配且有数据；再 metrics 看 hz 掉没掉；最后 trace 看回调排队。Tracing 常验证 callback group 假设：订阅回调是否真的互斥、定时器是否被饿死。QoS 不兼容时 DDS 层就没有样本——trace 里 executor 空闲，别误查控制算法。

MultiThreadedExecutor 与 SingleThreadedExecutor 在 trace 里形态不同：前者可见并行 take，后者所有回调串在同一 CPU 时间线。换 executor 类型前后各录 30s trace，比争论「该不该多线程」更有说服力。

bash

ros2 doctor --report
ros2 topic echo /rosout --once  # 确认无 QoS 警告

5. trace 会话要有结论

一次 tracing 交付物：假设、时间窗、关键截图（哪段 callback 超预算）、结论（拆组/降频/换 Best Effort）、是否跟进代码改动。没有结论的 trace 只是占盘，下次问题仍从零开始。归档进事故 ticket，比散在个人 ~/traces 可复用。

6. 插桩与发布开销

TRACETOOLS_STATUS 开启时，rclcpp 关键路径有纳秒级 overhead——上车短时可接受，常开不可接受。Release 包若 strip 符号，分析栈仍可读 kernel 侧；用户态符号需 -g 构建。CI nightly 可跑 60s trace 回归「baseline 回调预算」，PR 不跑全量。

Trace 事件名与版本绑定：升级 ROS 发行版后旧分析脚本可能找不到同名 event——把 ros2 trace list 输出随 baseline 一起版本化。内核事件（sched_switch）权限高，容器 CI 常关；用户态插桩足够回答 executor 问题时不强开 kernel。

7. 验收

复现一次已知「同组阻塞」：trace 时间线可见定时器启动延迟与长回调重叠。
故意 QoS 不匹配：trace 显示无 take，与 topic hz 为零一致。
跨机：两机 trace 用同一 PTP 源，事件可对齐到 1ms 内。
文档：团队 wiki 有「何时开 trace」决策树，不是每人自学 LTTng。

8. 案例：deadline 告警误报

某包 deadline 回调频繁触发，日志以为是网络丢包。trace 显示订阅回调本身耗时 40ms，executor 来不及在 deadline 内二次 take——根因是回调里同步写盘。改异步队列后 deadline 静默。若没有 trace，团队可能去调 DDS 参数白费一周。

9. 与录包复盘

事故录包应能对照 metrics 时间窗：若 bag 里只有 topic 没有回调耗时，trace 片段（或同窗口 metrics dump）应并进 ticket。证据链完整，才分得清是 DDS 延迟、executor 阻塞还是算法本身慢。

日常轻量可观测；攻坚短时 tracing；每次留下假设与结论。工具按问题升级，不按个人偏好堆栈。