09 可观测性¶
难度:中级|前置:网络、异步任务|目标:从外部信号推断系统内部状态
三种核心信号¶
日志 Logs¶
记录具体事件,适合回答:
- 哪个设备发生了什么?
- 某个工具为什么失败?
- 参数校验拒绝了什么?
日志应结构化,并包含 trace_id、task_id、device_id 等关联字段。
指标 Metrics¶
对大量事件聚合,适合回答:
- 每秒处理多少消息?
- P95 延迟多少?
- 错误率是否上升?
- 在线设备数是多少?
- Token 成本是否异常?
不要把 device_id、user_id 直接作为指标标签。高基数会产生大量不同组合,增加内存和存储成本。
Trace¶
描述一次请求或任务跨组件的路径:
适合定位时间花在哪里、错误发生在哪个依赖。
四个黄金信号¶
- 延迟;
- 流量;
- 错误;
- 饱和度。
不同系统再补业务指标:
- IoT:连接数、心跳延迟、消息积压、离线误判;
- Agent:任务完成率、工具正确率、Token、人工接管率。
告警应该可行动¶
坏告警:
CPU 高。
更好的告警:
状态服务 P95 延迟连续 10 分钟高于 500ms,同时 Redis 超时率超过 2%。
收到告警的人应该知道:
- 影响什么;
- 严重程度;
- 从哪里排查;
- 是否需要立即处理。
关联¶
统一使用上下文:
敏感数据不要直接写日志,尤其是 Token、密钥、学生数据和完整 Prompt 中的隐私内容。
自测¶
- 日志、指标、Trace 分别适合回答什么问题?
- 为什么 device_id 不适合直接作为指标标签?
- “错误率升高”之后如何用 Trace 和日志继续定位?
- 一个好告警需要包含哪些信息?
完成标准¶
- 能为一个 API 定义日志、指标和 Trace
- 能解释高基数指标风险
- 能为 IoT 和 Agent 各列五个核心指标
- 能设计一个可行动告警
下一单元:权限与安全