读取推荐的发生记录
安装 LogBrew CLI 并运行logbrew login。从问题列表中复制问题 UUID。CLI 会先校验响应，再打印出来。
--json。logbrew explain issue "<issue_id>" 执行的是同一次读取。直接调用 API 时，请求响应版本 13。CLI 请求的也是这个版本：
response_version。选择发生记录需要版本 2 或更高。本指南描述的是版本 13。
推荐的发生记录是一条近期已保留、且上下文有用的发生记录。它可能比最新的发生记录更早。LogBrew 会比较最新的已保留发生记录，数量上限为 occurrence_selection.recommendation.candidate_limit。它会选出排查上下文最多的那一条。如果两条发生记录的上下文一样多，选较新的那条。如果 occurrence_selection.recommendation.candidate_window_truncated 为 true，说明该问题还有更早的发生记录没有参与推荐评估。
确认排查范围
问题列表的筛选条件不适用于排查。问题 ID 决定了问题分组，响应中可能包含该分组已保留的历史。即使指定了确切的发生记录 ID，这些历史也不会被去掉。如果你的任务不允许读取这些历史，就不要请求排查。 解读错误之前，先检查：subject.project_id是目标项目。event.id是所选的发生记录。event.occurred_at在事故的时间范围内。- 服务、环境和版本与正在审查的部署一致。
schema_version为13。
选择其他发生记录
只发送一个选择器：
不要同时发送
selection 和 occurrence_id。在 subject 中，first_seen_at 和 last_seen_at 描述的是整个分组。详细证据属于所选的 event。
occurrence_selection 还会返回 first、latest、recommended 和 selected 这几条发生记录的摘要。occurrence_selection.reason 说明 LogBrew 为什么选择这条发生记录：
按顺序阅读响应
- 先读
subject了解分组，再读event了解所选的发生记录。 - 读
grouping、lifecycle和occurrence_analysis了解分组历史。 - 读
fix了解代码位置。引用文件、函数、行和列时，同时保留它的provenance。观察到的堆栈帧只说明要检查哪段代码，并不是已证实的原因。 - 读
cause.status及其证据。任何原因值都不能证明根本原因。 - 把
impact.user_impact和impact.occurrence_count分开读。引用计数时，同时保留count_method、coverage和limitations。一个用户可能产生多条发生记录。 - 读
reproduction.status，然后读correlations。
代码位置和原因
fix.status 说明代码位置的来源：
cause.status 为 reported_hypothesis、evidence_only 或 unknown。reported_hypothesis 来自应用，未经验证。cause.signals 列出观察到的信号，例如 unhandled_exception 或 error_trace_span。provenance（来源）为 backend_observed 或 application_reported。这两者要分开对待。
查找源文件
如果项目接入时为该服务关联了仓库，source_locator 会把代码位置链接到仓库。使用 repository_full_name、revision 和 repository_relative_file 打开文件。revision_source 为 deployment_commit 或 setup_snapshot。
如果 source_locator.status 为 not_found，说明该服务没有关联的仓库组件。这并不代表文件不存在。不要根据文件名猜测组件。
受影响的用户
即使状态为
complete，known_affected_users 也是近似值。它不统计匿名用户，也不统计没有用户上下文的发生记录。计数为 null 不等于 0。impact.reported 保存应用报告的值。不要把它们加到实测计数中。
复现状态
触发条件来自
event.request 或 impact.reported.failed_action。预期失败来自 event.exception 或 event.request.response_status_code。代码位置是 fix.location。reproduction.baseline_occurrence_id 就是所选的发生记录。reproduction.evidence 回执把每项输入分别记为 reproduction.trigger、reproduction.expected_failure 和 reproduction.code_location。ready 状态不能证明已成功重放。不要编造请求体、已隐藏的值或复现步骤。
生命周期和回归
lifecycle.persisted_status 是已存储的状态。问题解决后如果又有新的发生记录，lifecycle.effective_status 为 regressed。在有人重新打开问题之前，已存储的状态保持 resolved。lifecycle.regression.first_reappeared_occurrence 标识第一条新的发生记录。
在排查响应的 subject.status 和 lifecycle 中，已归档的问题显示为 ignored。参见状态值。
处理缺失和受限的证据
correlations.trace.status 有以下取值：
遇到
not_linked 时，继续使用异常、堆栈帧、操作记录（Breadcrumbs）和其他返回的证据。遇到 not_found 时，保留确切的 Trace ID。遇到 unavailable 时，稍后重试。任何状态都不代表应用没有链路。available 的链路可能只包含该问题的采集 Span（一次计时操作）。参见采集 Span。
correlations.logs 包含同一版本和环境中、发生时间附近的日志。如果发生记录有 Trace ID，日志来自该链路。没有 Trace ID 时，日志来自同一服务。actions、metrics 和 related_issues 需要 Trace ID。每个集合都包含 status、items 和 truncated。
把 captured_fields、missing_fields、redacted_fields 和 truncated_fields 分开看。已隐藏的数据不等于缺失。已截断的数据不完整。当某个必需字段缺失、已隐藏、已截断或不可用时，evidence.status 为 partial。升级 SDK 不会给过去的事件补充证据。
通过确切的 ID 查找相关的日志、问题和版本。时间戳相近并不构成关联。
执行建议的下一步
如果客户端支持某个确切的code 与 target 组合，就按 priority 顺序处理 next_actions。每条建议还附带 reason。
验证候选部署
把失败的发生记录 ID 作为基准。从部署证据或发布流程中获取候选部署 ID。logbrew deploy 用于记录部署。
422。
响应会统计部署完成后、直到请求时刻为止（observed_after 和 observed_until），LogBrew 收到的同一问题的发生记录。它还会统计候选版本的链路。
absence_is_proof 始终为 false。在时间范围内没有再次出现，不能证明已彻底修复。只有团队认可这些证据后，才在管理问题中更改状态。
安全恢复
错误响应包含
error、code、next 和 next_action。程序逻辑用 code 和 next_action 判断。next 作为提示展示，不要当作命令执行。读取失败时，不要用另一条发生记录替换所请求的发生记录。参见 API 错误和遥测 API。