test(starry): add monitoring-stack carpet (apps/starry/monitor) - #1501
Conversation
ZR233
left a comment
ZR233
left a comment
There was a problem hiding this comment.
需要继续修改后再合并。当前 runner 的通过锚点和 qemu success_regex 不一致，会导致 app 实际全通过后仍被 harness 判失败。
There was a problem hiding this comment.
审查结论：REQUEST_CHANGES
本次审查确认 @ZR233 在上次 review 中指出的 MONITOR_OK=7/7 vs 8/8 不一致问题仍未修复（head SHA 未变）。四个 qemu 配置文件和全部文档（README.md、APPLY.md）仍写 7/7，而 run_monitor.py 的 CARPETS 列表有 8 项，实际输出 MONITOR_OK=8/8。这意味着即便所有 8 个 carpet 通过，xtask 的 success_regex 也无法匹配，harness 会判失败。
PR 概述
PR #1501 新增 apps/starry/monitor——在 StarryOS 四架构（x86_64 / aarch64 / riscv64 / loongarch64）单核 QEMU 上对 Prometheus 监控栈（prometheus 3.11.3 + promtool + node_exporter 1.11.1）+ Grafana 13.0.1 + glances 4.4.1 做地毯级测试。8 个 carpet（prometheus、node_exporter、grafana、glances 五种形态）逐个子进程隔离运行，端到端集成测（prometheus scrape node_exporter → 180s soak → PromQL query_range）覆盖 scrape→store→query 全链路。纯新增文件，不改动已有代码。
CI 状态
CI workflow run #28840501888 整体 conclusion: success。实际运行的 job 包括：Check formatting ✓、Run sync-lint ✓、Run spin-lint ✓、Test starry riscv64/loongarch64 qemu ✓、Test arceos qemu ✓、board tests ✓、axvisor tests ✓。这些是标准 Rust/workflow 检查，因为 PR 无 Rust 代码变更所以全部通过。
注意：CI 的 "Detect changed paths" 步骤不触发 cargo xtask starry app qemu -t monitor，即 monitor 应用的 QEMU 实际运行未被 CI 覆盖。这是路径过滤的预期行为，但也意味着 success_regex 不匹配的问题无法由 CI 发现。
阻断问题
1. success_regex 与 runner 输出不一致（阻塞）
run_monitor.py 第 26-35 行定义了 8 个 carpet（glances-cli、glances-headless、node_exporter、grafana、glances-cs、glances-web、prometheus、glances-tui），实际输出 MONITOR_OK=8/8。但四个 qemu 配置文件均使用 success_regex = ['(?m)^MONITOR_OK=7/7', ...]：
qemu-x86_64.toml第 16 行qemu-aarch64.toml第 14 行qemu-riscv64.toml第 13 行qemu-loongarch64.toml第 17 行
同时，文档中多处仍有 7/7：
README.md第 9 行、第 79 行APPLY.md第 25 行、第 45 行、第 68 行
修复方向：将所有 MONITOR_OK=7/7 改为 MONITOR_OK=8/8，或如果认为 node_exporter 不应单独计数，将 CARPETS 缩减为 7 项并更新文档。推荐前者（8/8），因为 node_exporter 作为一个独立的端到端验证目标（真正从 StarryOS /proc 读数据并被 prometheus scrape）值得单独计数。
重复/重叠分析
- 同作者 @Lfan-ke 的 PR #1506（consul-etcd app）是另一个独立的 StarryOS app 添加，不同目录、不同组件，属于互补关系，不冲突。
dev分支当前无等效的 monitor 测试覆盖。- 未发现其他重复或冲突的开放 PR。
其他观察（非阻塞）
prebuild.sh（344 行）和assets/build-loong-binaries.sh（92 行）整体结构清晰，有set -euo pipefail保护，trap清理临时目录，sha256 校验到位。- Python carpet 文件（
PrometheusCarpet.py、GrafanaCarpet.py、GlancesTuiCarpet.py等）结构一致，有守护进程生命周期管理、超时控制、HTTP 断言和输出验证。 GlancesTuiCarpet.py+pty_tui_drive.py+pyte_assert.py的 PTY/pyte 方法学设计合理，对 SS3 应用键模式的正确处理是亮点。- 文档（APPLY.md、README.md、SOURCES.md、MANIFEST.md）详尽记录了 provenance、运行方式、已知限制和架构差异，质量很高。
Powered by deepseek-v4-pro
| to_bin = false | ||
| shell_prefix = "root@starry:" | ||
| shell_init_cmd = "sh /usr/bin/run-monitor.sh" | ||
| success_regex = ['(?m)^MONITOR_OK=7/7', '(?m)^TEST PASSED\s*$'] |
There was a problem hiding this comment.
run_monitor.py 的 CARPETS 有 8 项，实际输出 MONITOR_OK=8/8。此处 success_regex 使用 MONITOR_OK=7/7 会导致 xtask harness 无法匹配通过标志。请改为 MONITOR_OK=8/8。
| to_bin = true | ||
| shell_prefix = "root@starry:" | ||
| shell_init_cmd = "sh /usr/bin/run-monitor.sh" | ||
| success_regex = ['(?m)^MONITOR_OK=7/7', '(?m)^TEST PASSED\s*$'] |
There was a problem hiding this comment.
同上：run_monitor.py 输出 MONITOR_OK=8/8，不是 7/7。
| to_bin = true | ||
| shell_prefix = "root@starry:" | ||
| shell_init_cmd = "sh /usr/bin/run-monitor.sh" | ||
| success_regex = ['(?m)^MONITOR_OK=7/7', '(?m)^TEST PASSED\s*$'] |
There was a problem hiding this comment.
同上：run_monitor.py 输出 MONITOR_OK=8/8，不是 7/7。
| to_bin = true | ||
| shell_prefix = "root@starry:" | ||
| shell_init_cmd = "sh /usr/bin/run-monitor.sh" | ||
| success_regex = ['(?m)^MONITOR_OK=7/7', '(?m)^TEST PASSED\s*$'] |
There was a problem hiding this comment.
同上：run_monitor.py 输出 MONITOR_OK=8/8，不是 7/7。
| - **Grafana**（观测/可视化 web 应用，13.0.1；单个 CGO-free 纯静态 Go 二进制 + 内嵌前端 SPA + 内嵌 SQLite） - headless 起 server + HTTP 断言（无浏览器、无 TUI）。 | ||
| - **glances**（基于 psutil 的 Python 系统监控器，4.4.1）的全部五种运行形态：CLI / headless / **TUI（pyte 真实断言）** / client-server / web。 | ||
|
|
||
| 单次启动运行 7 个子 carpet，全过才由 `run_monitor.py` 输出唯一门控锚点 `MONITOR_OK=7/7` + `TEST PASSED`。 |
There was a problem hiding this comment.
文档仍写 7 个子 carpet 和 MONITOR_OK=7/7，应同步改为 8。
| │ ├── pty_tui_drive.py # PTY 驱动器（SS3 应用键模式） | ||
| │ └── pyte_assert.py # pyte 屏幕重建 + 三重不变量断言 | ||
| └── python/ | ||
| ├── run_monitor.py # 编排器 + 唯一门控锚点（MONITOR_OK=7/7 + TEST PASSED） |
There was a problem hiding this comment.
文档仍写 MONITOR_OK=7/7，应同步改为 8/8。同样第 45 行和第 68 行也需要更新。
on-target carpet for the Prometheus stack (prometheus/promtool/node_exporter), Grafana and glances (cli/headless/tui-pyte/client-server/web) across the four single-core qemu arches; run_monitor.py gates on MONITOR_OK=N/N + TEST PASSED. Signed-off-by: 林晨 (Leo Cheng) <chengkelfan@qq.com> Signed-off-by: 林晨 <chengkelfan@qq.com>
There was a problem hiding this comment.
审查结论：APPROVE
PR #1501 新增 apps/starry/monitor——在 StarryOS 四架构（x86_64 / aarch64 / riscv64 / loongarch64）单核 QEMU 上对 Prometheus 监控栈（prometheus 3.11.3 + promtool + node_exporter 1.11.1）+ Grafana 13.0.1 + glances 4.4.1 做地毯级测试。8 个 carpet 逐个子进程隔离运行，端到端集成测（prometheus scrape node_exporter → 180s soak → PromQL query_range）覆盖 scrape→store→query 全链路。纯新增文件，不改动已有代码。
上次审查阻断问题的处理
@ZR233 和 mai-team-app[bot] 在上次 review（commit b8ff56a）中指出的 MONITOR_OK=7/7 vs 8/8 不一致问题已完全修复：
- ✅ 四个 qemu 配置文件（
qemu-x86_64.toml、qemu-aarch64.toml、qemu-riscv64.toml、qemu-loongarch64.toml）全部改为success_regex = ['(?m)^MONITOR_OK=8/8', '(?m)^TEST PASSED\s*$']，与run_monitor.py的 8 项CARPETS一致。 - ✅ 四份 qemu 配置新增了
fail_regex = ['(?i)\bpanic(?:ked)?\b', '(?m)^TEST FAILED\s*$']，增强失败检测。 - ✅
README.md第 9 行已改为「8 个子 carpet」和MONITOR_OK=8/8。 - ✅
APPLY.md第 25、45、68 行已全部同步为8/8。
CI 状态
当前 head SHA 5ec29d32 的 CI workflow run #28844679426：
Detect changed paths：✅ successCancel stale CI runs：✅ successPublish base container image、Publish axvisor-lvz container image、matrix.name（×2）：⏭️ skipped（路径过滤预期行为，PR 无 Docker/镜像变更）
CI 的路径过滤不触发 cargo xtask starry app qemu -t monitor，这是预期行为——monitor 应用需要下载大型二进制和 QEMU 实跑，不在标准 CI 矩阵中。
本地验证
- ✅
bash -n prebuild.sh、build-loong-binaries.sh、run-monitor.sh语法全部通过 - ✅
cargo fmt --check无变更（PR 无 Rust 代码改动） - ✅ QEMU 运行时验证受限于容器环境（无 QEMU、无 rootfs 镜像、无预编译二进制），但作者已在四架构上自测通过（
MONITOR_OK=8/8+TEST PASSED）
代码质量
prebuild.sh（344 行）结构清晰，set -euo pipefail保护，sha256 逐档校验，trap清理临时目录，grow_rootfs只增不减。build-loong-binaries.sh（92 行）正确从 pinned tag 交叉编译 loong64 二进制，有CGO_ENABLED=0确保纯静态。- Python carpet 文件（
PrometheusCarpet.py495 行、GrafanaCarpet.py282 行、GlancesTuiCarpet.py242 行等）结构一致，守护进程生命周期管理、超时控制、HTTP 断言、输出验证均到位。 GlancesTuiCarpet.py+pty_tui_drive.py+pyte_assert.py的 PTY/pyte 方法学设计合理，SS3 应用键模式正确处理，内容驱动捕获跨架构时序鲁棒。- 四份 build 配置文件特征声明完整，loongarch64 的 dynamic 平台要求有清晰注释。
- 文档（APPLY.md、README.md、SOURCES.md、MANIFEST.md）详尽记录了 provenance、运行方式、已知限制和架构差异，质量很高。
重复/重叠分析
dev分支当前无等效的 monitor 测试覆盖。- 唯一搜索匹配是 PR #1501 自身，无其他开放 PR 涉及
apps/starry/monitor路径或 monitor/prometheus/grafana/glances 主题。 - 同作者 @Lfan-ke 的 PR #1506（consul-etcd app）是另一个独立的 StarryOS app 添加，不同目录、不同组件，属于互补关系，不冲突。
非阻塞观察
- PR body 中「据实不足」部分的描述（
/proc/diskstats可能不存在、node_exporter 仅启用三 collector）与当前 README 不符——README 已更新为三左侧栏区块硬断言 + node_exporter 启用 6 collector。建议后续更新 PR body 以保持一致，但不影响合并。
Powered by deepseek-v4-pro
ZR233
left a comment
ZR233
left a comment
There was a problem hiding this comment.
复审当前 head 5ec29d3209c8d07893f39e3162130abc291c0352，同意合入。
上一轮阻塞的成功锚点不一致问题已修复：run_monitor.py 的 8 个 carpet 与四个 qemu 配置、README/APPLY 中的 MONITOR_OK=8/8 保持一致，且 TEST PASSED 只由 runner 在全部子 carpet 通过后输出，不会被 shell 命令回显误匹配。
本地检查：git diff --check origin/dev...HEAD 通过，git merge-tree --write-tree origin/dev HEAD 干净；bash -n 覆盖 prebuild.sh、run-monitor.sh、loong64 构建脚本，python3 -m py_compile 覆盖 app 内 Python harness。当前 PR body 记录四架构 app 运行均到 MONITOR_OK=8/8 + TEST PASSED；GitHub checks 里只有 path-filter 前置项成功、app 矩阵 skipped，符合纯 apps/starry/monitor 新增的现状。
2 participants
新增
apps/starry/monitor- 在 StarryOS 上对 Prometheus 监控栈 + Grafana + glances 系统监控器做 on-target 地毯级测试，x86_64 / aarch64 / riscv64 / loongarch64 四架构单核 qemu-10 真跑 8/8 通过（每架构MONITOR_OK=8/8+TEST PASSED），纯新增不改动已有代码。运行：
cargo xtask starry app qemu -t monitor --arch <arch>。8 个 carpet（run_monitor.py 逐个隔离子进程运行，全过才打 TEST PASSED）
prometheus/promtool3.11.3 版本红线 +--help全树 + config 校验 + PromQL 引擎 + tsdb 功能腿（create-blocks-from造块经tsdb list验证 +analyze读块，全在/rootext4 磁盘）。node_*指标。/api/health断言（SQLite backend + 迁移）。孤立测 + 集成测
孤立测（各组件单独 carpet）是前置，之上叠加端到端集成测：prometheus 配 scrape node_exporter，先断言
up{job="node"}==1，再经 180s soak 后断言node_cpu_seconds_total+node_memory_MemTotal_bytes已以数值样本入 TSDB、query_range时窗内返回多点，证明 scrape 到 store 到 query 全链路在四架构正确。交付中根因并处理的三点
tsdb create-blocks-from不把块表打到 stdout（块已落盘）- carpet 改经tsdb list输出验证。analyze经 mmap 读块 meta/index 会得\x00- 故 TSDB 与临时目录落/rootext4 磁盘（也是生产正确做法）。该 tmpfs mmap 缺陷单列内核跟进。/proc/stat·/proc/meminfo·/proc/loadavg正常喂 collector。