Log 学习：从噪声中找 execution、failure 与 acceptance

本地 log 是教材，但必须先分类，不能把 WARNING 数量当结果

发布于

2026年7月13日

Log inventory

下表是本轮实际扫描得到的文件库存；它说明“材料很多”，也说明不能把所有 log 全塞进一个 prompt。

Source pipeline sources configs main/error logs main/error bytes command/run/replay logs command/run/replay bytes
XARTATOMS 0900170101 3 11 178 8,099,898 119 15,714,109
M31CGM data tree 4 3 16 369,293,176 8 352
M31HotISM project 7 19 12 187,510 6 264
upstream ipynb tree 102 historical files 10 452 107,190,448 170 329,774

这些数字用于选择学习材料，不是 science result。upstream 的 102 个文件包括历史版本、backup 与 notebook artifacts；不能用 count 推断质量。

先把 log 分成五类

类别 应记录什么 例子 不能推断什么
launch log env、engine/config hash、command、PID XART clean-shell wrapper 产品已通过
engine log stage、SAS command、region conversion、runtime warnings LOG_esas_playground... 每个 WARNING 都是真失败
error log task stderr / exception M31CGM epchain / shell function import 整次 run 必然不可用
status pipeline RC、wrapper RC、state、timestamp XART .status; M31HotISM supervisor status 单一 RC 能替代 product QA
qualification FITS/product checks、hash、QPB/response、visual QA XART JSON; M31HotISM 84 gates fitting/physics 已成立

Case 1 — XARTATOMS: pipeline RC 0，但 wrapper RC 1 (XART-E04 + status)

代表性 log 开头：

4 passed in 0.27s
PILOT_RELEASE_HASH_GATE_PASS
<engine SHA-256>  esas_playground_v1.4.1.py
LAUNCH_REMAINING_SEVEN_MOS2_PIPELINE

engine 末尾：

PIPELINE_RC 0
STATUS_FILE ...remaining_seven...status

status 实际是：

pipeline_rc=0
wrapper_rc=1
state=failed

正确解释

  • engine 尝试完 regions 并返回 0；
  • wrapper 期待 7 个 output namespace，其中 S8 只有 CCD1、没有 QPB outer anchor；
  • wrapper fail-closed 返回 1；
  • 后续 inventory/qualification 证明六个新 region 可用，S8 unavailable；加上 Wind N pilot 最终是 7/8 qualified。

所以： wrapper_rc=1 不是“所有 extraction 失败”，pipeline_rc=0 也不是“所有 region 通过”。必须读 region-level qualification。

可改进的 log

同一个 1.79 MB wrapper log 尾部大量是 hardlink size/no-space-saved 输出，真正决定状态的只有最后几行。建议 future log 分开：

  • launch.log
  • engine.log
  • region_status.jsonl
  • qualification.json

你是否同意 wrapper 在部分 region unavailable 时整体 RC=1？还是应该返回 RC=0 + explicit PARTIAL state，只要所有可用 region 都 qualified？

Case 2 — M31CGM: 49,609,621-byte 单日志 (CGM-E03)

log 开头准确告诉我们：

obsID : 0800732701
mode : redu
cifbuild : yes
odfingest : yes
emchain : yes
epchain : yes
2.filter : yes
edetect_stack : yes
3B.background : yes
background : yes

这证明它是 full reduction，不是只抽一个 annulus。

但日志同时包含：

  • 完整环境变量；
  • 每个 SAS task 的全部参数；
  • repeated module/ml/which shell-function import warnings；
  • 大量 hardlink size metrics；
  • 早期/中途 error 内容；
  • 尾部没有独立 product qualification marker。

学习价值

  • 能重建 cluster 上的真实环境与失败；
  • 能看到 redu 跑了哪些 stage；
  • 能作为“哪些 log 以后不要全量打印”的反例；
  • 能挑选一条 golden full-reduction log 和一条 known-failure log。

不该做

不能通过搜索最后一个 ERROR 或看到若干 *-back.pi 就宣布 observation usable。应从 log 中抽出：

{
  "obsid": "0800732701",
  "mode": "redu",
  "stages": {},
  "tasks": [],
  "products": [],
  "fatal_error": null,
  "qualification": "not recorded"
}

请指定 M31CGM 里一条你认定成功、一条你认定失败的 golden log。Hermes 会按你的标签学习，而不是自己从 49 MB 文本猜。

Case 3 — M31HotISM: pipeline 0、supervisor bug、verifier rerun PASS (HOTISM-E009-QA)

真实 status：

pipeline_exit_status=0
postrun_supervisor_failure=zsh_reserved_status_variable
manual_repair=link_then_verify
manual_verifier_exit_status=1
manual_verifier_rerun_exit_status=0

final verifier：

status=PASS
checks_total=84
checks_failed=0

正确解释

  • extraction engine 成功；
  • postrun supervisor 自己有 shell variable bug；
  • 第一次 verifier 有 false negative / link handling；
  • 修复后同一真实 product set 通过 84/84；
  • 不能把 attempt count 当 science workflow，也不能删除这段 audit history。

值得保留的 log 设计

  • attempt directories 不覆盖；
  • rejected attempt 明确隔离；
  • final verification 独立 JSON；
  • source/QPB/response/hash 与 exact region 一起记录。

应从 routine runner 移出的内容

  • compatibility recovery；
  • engine runtime copy；
  • manual link repair；
  • zsh-specific supervisor workaround。

M31HotISM 的 84 gates 中，哪些是你的 universal contract？如果只保留 15 个，请按优先级列出。

Case 4 — upstream engine log: 先清 bootstrap noise

v1.4.1 production log 启动时仍会出现：

  • test INFO/ERROR/CRITICAL；
  • touch test.txt；
  • PATH/环境 setup 展开；
  • locale 为 ASCII 时中文 log 的 UnicodeEncodeError；
  • final rProfile/sync 的长输出。

这些不会自动说明 science product 错误，但会遮蔽真正 failure。建议 engine logger 输出 structured event：

{"stage":"region","camera":"mos2","region":"R4-7_S3","event":"start"}
{"stage":"mos-spectra","camera":"mos2","region":"R4-7_S3","rc":0}
{"stage":"mos_back","camera":"mos2","region":"R4-7_S3","rc":0}
{"stage":"product","camera":"mos2","region":"R4-7_S3","state":"qa_pending"}

Hermes 应该如何读 log

  1. 先读 wrapper/status，确定 run boundaries；
  2. 再读 config snapshot，确定 mode 和 regions；
  3. 只抓每个 SAS task 的 command、RC、fatal exception；
  4. 建立 camera×region ledger；
  5. 对每个 output 跑 product validator；
  6. 最后才决定 PASS / PARTIAL / REJECT；
  7. 保留原 log hash，不用摘要替换原证据。
警告凭据卫生

M31CGM historical job script 中存在 hard-coded notification credential。网站和下载只写 [REDACTED]；任何 future training set 都必须先做 secret scan。

下载