logbrew login。
问题与发生记录
问题列表返回的是分组摘要，而不是完整的事件。打开详情之前，先查看这些字段：
发生次数不是受影响的用户数。计数和时间只针对返回的范围，而不是完整的错误历史。
--since 或 --until 筛选条件会限制 LogBrew 统计的发生记录。报告某个计数时，同时说明得出该计数所用的筛选条件。
状态值
archived 以前叫 ignored。两个名称选中的是同一批问题，作为输入都可以接受。logbrew read、logbrew issues 以及 API 第 2 版和第 3 版显示 archived。API 第 1 版（默认版本）、实时查看（watch）数据流和问题排查响应显示 ignored。控制台中，这些状态显示为“未解决”“已解决”和“已归档”。
状态作用于整个问题，而不是某一条发生记录。严重程度表示紧急程度，状态记录的是决定，两者要分开看待。经过验证的修复之后，critical 问题也可以是 resolved。archived 问题会保留采集时的严重程度。
LogBrew 不会自动重新打开已解决的问题。如果问题解决后又出现新的发生记录，排查结果会把 lifecycle.effective_status 报告为 regressed。在有人重新打开该问题之前，status 仍为 resolved。
优先级
优先级决定团队分诊问题的先后顺序：
每个问题都有优先级。如果没有人设置，优先级会跟随问题的严重程度：
error 和 critical 对应 high，warning 对应 medium，info 对应 low。当问题规则更改了严重程度时，优先级跟随 triage.effective_severity，此时 priority_source 为 derived。由人设置的优先级保持不变，priority_source 为 manual。
列出需要首先检查的问题：
分配问题
分配问题，以表明由谁负责下一步。一个问题有 0 或 1 个负责人：一个账号或一个团队。1
查找可分配的人
assignees 包含所有可以读取该项目的账号，带有 user_id、name 和 email。teams 包含该项目所属组织的所有团队，带有 team_id、slug 和 name。不能把问题分配给无法读取该项目的账号，也不能分配给其他组织的团队。2
分配问题
me 代替用户 ID，即可把问题分配给自己。使用 logbrew issues unassign "<issue_id>" --json 移除负责人。添加 --project，可以一次更改同一项目中最多 100 个问题。3
查看分配给你的问题
--assignee my_teams 查看你所在团队的问题，使用 --assignee "team:<team_id>" 查看某个团队的问题，使用 --assignee none 查找没有负责人的问题。--assignee none 的读取结果中。如果该成员重新获得访问权限，这些问题会再次显示该成员为负责人，除非在此期间有人更改或移除了负责人。
查找问题的所有者
suggested_assignee。每个所有者都有一个 source：
inputs 统计 LogBrew 检查过的堆栈帧路径、模块、路由模板、标签和规则的数量。如果列表为空，而 inputs 中也没有路径，说明这个问题没有可供匹配的证据，而不是没有所有者。
把所有权规则写在一个文本文件中，每行一条：
path 模式匹配堆栈帧路径的末尾，所以无论部署目录是什么，src/payments/** 都能匹配其下的堆栈帧。* 匹配任意文本。所有者可以是账号邮箱，也可以是 #team-slug。最后一条匹配的规则排在最前面。然后发送这些规则、GitHub CODEOWNERS 文件，或两者都发送：
@org/team-slug 表示具有该 slug 的团队。如果规则指定了没有项目访问权限的账号或不存在的团队，请求会以 422 失败。CODEOWNERS 中找不到对应对象的所有者会出现在 unresolved_owners 中。发送空文件会清空对应的文本。
查看问题的变更历史
first_seen。失去项目访问权限的账号只保留其 ID。使用 --limit 和 next_cursor 中的值读取更多记录。
查看收件箱
unread 统计你的已读标记之后的分配数量。logbrew inbox read 会把已读标记移到当前时间。LogBrew 不会为这些分配发送邮件。收件箱只显示你当前可以读取的项目。
推荐工作流
1
在单一范围内列出未解决的问题
2
读取问题详情
3
排查一条发生记录
subject.project_id、event.occurred_at、版本和环境与你的范围进行比较。推荐的发生记录可能早于最新的那条。完整的证据审查，按照排查问题进行。4
仅在链路证据可用时查看链路
只有当 链路读取没有时间筛选条件。如果状态为
correlations.trace.status 为 available 时，才读取链路。使用响应中的 Trace ID，绝不要自行编造。not_linked，继续使用问题证据。5
验证候选部署
把已排查的发生记录作为基准。从部署证据或你的发布流程中获取部署 ID。观察时间范围内没有复发，并不能证明问题已永久修复。如果
status 为 insufficient_traffic 或 unavailable，让问题保持 unresolved。按照返回的下一步建议处理。6
更改状态、优先级或负责人
运行其中一条命令。这些命令不会请求确认，所以先核对问题 ID。不带
--project 时，每条命令只接受 1 个问题 ID。检查退出码，以及返回的 status、priority 和 assignee。如果没有返回结果，进行下一次更改之前，先重新读取该问题。旧脚本可以使用 logbrew set issue "<issue_id>" resolved，以及 resolve、ignore 和 reopen 快捷命令。ignore 会把状态设置为 archived。一次更改多个问题
添加--project，可以用一条命令更改同一项目中最多 100 个问题：
每个条目都有
issue_id、outcome 和 issue。issue 是该问题的当前状态，结果为 not_found 时为 null。网络故障后，可以再次运行同一条命令，已经更改过的问题会显示 unchanged。超过 100 个问题时，分多条命令运行。对于 not_found 结果，从该项目的问题列表中重新复制 ID。API 请求的说明见批量更新问题。
选择下一个状态
- 保持
unresolved：故障仍在发生，或修复尚未验证。缺少链路不是归档问题的理由。 - 设置为
resolved：团队认可修复证据之后。建议的修复不算证据。 - 设置为
archived：适用于已接受的情况或仅用于测试的信号。该决定作用于该问题的所有发生记录。该命令没有原因字段，所以在团队的工作记录中写明原因。 - 用
unresolved重新打开：问题解决后又出现新的发生记录时。lifecycle.regression.first_reappeared_occurrence标识了这条记录。把它与解决问题时依据的发生记录进行比较。不要创建另一个问题。
交接排查工作
给下一个人提供引用信息，而不是原始事件的完整转储：- 问题 ID、状态、优先级、负责人和严重程度。
- 项目、服务、环境和版本。
- 首次出现时间、最近出现时间和发生次数。
- 所选发生记录 ID 和
occurrence_selection.reason。 fix.status、cause.status以及它们的provenance。- 链路状态和 Trace ID（如果有）。
- 复现状态和缺失的证据。
- 候选部署的验证结果。
- 响应返回的下一步建议。
从 CLI 错误中恢复
解析输出之前，先检查进程的退出码。成功时，JSON 输出到标准输出。解析错误以退出码2 退出。运行时错误以退出码 1 退出。JSON 错误输出到标准错误，包含 ok: false、error、message 和 next。把 next 当作建议展示，不要自动运行它。
例如，logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json 没有 --project。它会在发送请求之前以退出码 2 退出，并返回错误 invalid_issue_command。
API 拒绝请求时，error 为 api_error。从 status 读取 HTTP 状态码，从 api_code 读取 API 错误码。
响应失败并不能证明状态、优先级或负责人的更改没有生效。重试之前，先读取该问题。
怎样的问题才有用
- 清晰的标题和易读的消息。
- 稳定的指纹。
- 堆栈帧（如果有）。
- 版本、环境和服务上下文。
- 链路上下文（如果随发生记录一起采集）。
- 少量相关的属性，而不是完整的负载转储。