跳转至

09 可观测性

难度:中级|前置:网络、异步任务|目标:从外部信号推断系统内部状态

三种核心信号

日志 Logs

记录具体事件,适合回答:

  • 哪个设备发生了什么?
  • 某个工具为什么失败?
  • 参数校验拒绝了什么?

日志应结构化,并包含 trace_idtask_iddevice_id 等关联字段。

指标 Metrics

对大量事件聚合,适合回答:

  • 每秒处理多少消息?
  • P95 延迟多少?
  • 错误率是否上升?
  • 在线设备数是多少?
  • Token 成本是否异常?

不要把 device_id、user_id 直接作为指标标签。高基数会产生大量不同组合,增加内存和存储成本。

Trace

描述一次请求或任务跨组件的路径:

API
→ Agent Node
→ Model
→ Tool
→ Database

适合定位时间花在哪里、错误发生在哪个依赖。

四个黄金信号

  • 延迟;
  • 流量;
  • 错误;
  • 饱和度。

不同系统再补业务指标:

  • IoT:连接数、心跳延迟、消息积压、离线误判;
  • Agent:任务完成率、工具正确率、Token、人工接管率。

告警应该可行动

坏告警:

CPU 高。

更好的告警:

状态服务 P95 延迟连续 10 分钟高于 500ms,同时 Redis 超时率超过 2%。

收到告警的人应该知道:

  • 影响什么;
  • 严重程度;
  • 从哪里排查;
  • 是否需要立即处理。

关联

统一使用上下文:

trace_id
task_id
tenant_id
device_id / tool_call_id

敏感数据不要直接写日志,尤其是 Token、密钥、学生数据和完整 Prompt 中的隐私内容。

自测

  1. 日志、指标、Trace 分别适合回答什么问题?
  2. 为什么 device_id 不适合直接作为指标标签?
  3. “错误率升高”之后如何用 Trace 和日志继续定位?
  4. 一个好告警需要包含哪些信息?

完成标准

  • 能为一个 API 定义日志、指标和 Trace
  • 能解释高基数指标风险
  • 能为 IoT 和 Agent 各列五个核心指标
  • 能设计一个可行动告警

延伸阅读:OpenTelemetry Signals

下一单元:权限与安全