# 观测排障工作区 {#observe-troubleshooting}

应用概览显示业务信号与数据覆盖；排查范围在应用的概览、看板、日志、指标和告警标签页之间保留。复制排查链接会固定开始和结束时间；“此时段部署”打开同一窗口的部署记录。环境、服务名和实例 ID 使用实际上报的 OTel 身份。Grafana 自定义看板只有声明并使用相应变量才会应用这些筛选；固定查询的业务看板需由应用维护者更新。

平台状态入口为可观测 → 平台状态。Control 只做有并发、读取大小和超时限制的查询，短时缓存状态结果。空样本、失败、过期与真实零值分别展示。日志覆盖和 Alertmanager 告警是当前状态，不能用当前覆盖证明过去完整。HTTP 入口汇总按应用、最近五分钟计算；任务统计按所选窗口计算。未上报的 Broker 积压不推算。

`luma observe status/app/alerts/tasks` 暴露相同能力，`--format json` 保留各来源状态。CLI 返回的 `ok` 代表命令完成，不代表应用健康。命令和 Web 需要新版 Control，Collector 自监控、持久队列、日志字段与读取断点还需要单独部署新版 Observe；容器身份回填需要升级节点代理。不会自动修改业务 SDK。

日志保留 `_time` 为采集时间，兼容既有日志告警；另外记录 `observed_at`、可解析的 `event_time`、规范的 Trace/Span ID 和执行编号。只提取白名单字段，不把任意业务 JSON 展开成标签。旧日志继续保留原文检索路径。日志读取位置在批次完全写入成功后保存，异常重试与崩溃可能重放，因此语义为至少一次；节点日志轮转仍可能导致缺口。

Collector Trace 发送队列使用 file_storage，PRW 使用专用 WAL，两者只保护已进入导出队列的数据，不能恢复 SDK 或尾采样处理中的数据。新卷复用 Luma 的 `initialize: empty` 初始化方式，不清理已有路径。监控队列与磁盘可用空间；出现压力应减少非必要遥测或增加独立容量，不能删除运行中的 WAL。

Tempo 2.10.10 的本地存储列举实现会将并发消失的目录作为索引轮询错误。当前排查支持显示该错误计数和关联日志，但没有以改配置掩盖错误，也没有未经验证升级 Tempo。根因判定仍需比对具体 block ID 的删除记录。

Control 和 Alertmanager 仍各自拥有通知与静默；统一入口只读取外部告警，不产生第二次投递。重启规则使用各 Allocation/Task 的累计 Counter 在最近十分钟的增量，避免累计超过五次后长期误报“正在重启”。