小龙虾(OpenClaw)源码分析12：可观测性与排障，线上问题怎么定位
文章目录
我们前面讲了架构、链路、并发、安全，最后一篇工程向收官：
线上出问题时，到底怎么定位。
先建立排障思维
我自己常用一个四步法：
- 先确认系统是不是“活着”（health/readiness）
- 再确认是不是“忙死了”（队列/并发/长回合）
- 再确认是不是“权限或配置错了”
- 最后看渠道侧和网络侧异常
这个顺序能避免一上来就淹死在日志里。
常用观察入口
命令侧：
openclaw statusopenclaw status --allopenclaw health --json
日志侧：
- 关注gateway启动日志
- 关注队列等待日志
- 关注插件加载失败日志
配置侧：
- 重点看auth/channel/queue/session相关关键项
三类高频问题
1) “没回复”
优先排查：
- 渠道连接是否在线
- 消息是否被allowlist/mention策略拦截
- 会话是否卡在长回合
2) “回复乱序/像串台”
优先排查：
- queue mode是否合适
- session key是否按预期分离
- 是否有并发打满导致延迟堆积
3) “回复很慢”
优先排查：
- 模型响应时间
- 工具调用耗时
- 频繁流式更新导致渠道限流
建议保留的最小观测面
即使是个人部署，也建议至少保留：
- 启动阶段关键日志
- 关键命令的状态快照
- 最近会话问题样本（可脱敏）
这样排障时不会全靠“感觉”。
小结
排障能力本质是系统能力的一部分，不是运维附属品。
做到“快速定位 > 盲目重启”，你的OpenClaw系统才算真正进入可长期维护状态。
下一篇番外，我们换个视角：不用完整工程，自己用Python写一个仅CLI交互的迷你版，把核心思想亲手跑起来。
