若目标是“尽量只看到与失败有关的日志，而不是把全部运行过程都打出来”，应使用官方日志级别里偏错误的档位，而不是去寻找文档中不存在的“只记录一次失败请求”独立开关。全局配置项是 log-level，日志仅在控制台和控制页面输出。级别会过滤输出类别；它不提供“每个失败请求只写一行、只记一次”的单独计数器。下面按官方定义，说明怎样把输出收束到失败相关内容，以及如何判断是否已经够用。
适用条件与能力边界
适用情况：你已经能复现失败，但不希望被大量一般运行内容淹没；或你只关心“是否已经无法使用”以及“是否有不影响运行的错误”。不适用的情况：你需要看成功路径是否走过——那属于 info 的“一般运行的内容”，收束到 error 后会看不到。也不要把 silent 当成“只记失败”：silent 的官方含义是静默、不输出，失败也不会出现。
官方五个取值里，与失败直接对应的是 error 与 warning。error：仅输出发生错误至无法使用的日志。warning：输出发生错误但不影响运行的日志，以及 error 级别内容。info 会追加一般运行内容。debug 会尽可能输出运行中所有的信息。文档示例为 log-level : info。因此，“只围绕失败来看日志”在现有能力下，就是把 log-level 设为 error 或 warning，并在控制台或控制页面观察复现当时的新增输出；不是再配置一个“次数=1”的参数。
按失败形态选择 error 或 warning
若失败已经导致无法使用，把 log-level 设为 error，然后只操作一次你要验证的失败请求（或一次完整复现）。判断依据：这一级按定义只收录“错误至无法使用”的日志，成功的一般运行内容不应成为主体。复现一次后，看控制台或控制页面是否出现对应该次失败的错误记录。若有，即可把该次输出当作这次失败的日志依据，无需升到 info 或 debug。
若服务仍能运行，只是某次请求失败或出现不影响运行的错误，应使用 warning 再复现一次。判断依据：warning 明确包含“发生错误但不影响运行”的日志，并覆盖 error。此时仍应只触发你关心的那一次失败，便于把屏幕上的新增行和这一次操作对应起来。官方并没有“自动去重、全局只留一条”的说明，所以“一次”靠的是你控制复现次数，加上级别把无关的一般运行内容滤掉。
不要为了“只记失败”而开 debug。debug 会尽可能输出运行中所有的信息，会把失败淹没在完整运行信息里，与收束目标相反。也不要在两次以上无关操作之后才去翻输出，否则即使级别正确，也难以证明某行属于“这一次”失败。
操作步骤、核验与失败时下一步
在全局配置写入 log-level : error 或 log-level : warning，保存并使当前内核使用该配置。清空或忽略控制台、控制页面里更早的内容，仅保留接下来的观察窗口。执行一次失败请求或一次最小复现。立即查看这两处是否出现与 error/warning 定义相符的新日志。若出现，记录该窗口内的内容，即可停止继续加压级别。
若一次复现后完全没有记录：先确认不是 silent；再确认观察的是控制台或控制页面；再确认拼写与加载的配置无误。若当前是 error 且现象其实“不影响运行”，改为 warning 后再只复现一次。若 warning 仍没有失败类输出，说明该事件可能未被这两级定义为错误，需要临时升到 info，查看是否出现一般运行内容中的相关行；info 能说明过程，但已不再是“只围绕失败”。若 info 仍不够，才短时使用 debug，并同样只复现一次，避免连续操作造成多段“所有运行信息”混在一起。
一旦已经从 error 或 warning 拿到与该次失败对应的输出，应把 log-level 改回 info 或你的日常取值，避免长期停留在过低（看不见其他问题）或过高（输出不再限于失败）。整个过程不依赖未在文档中出现的菜单或额外开关，只依赖 log-level 的过滤范围、官方指定的两处输出，以及你把复现次数控制在一次。