系统监控浮窗glenngit/dsh-top

dsh-top

一个用于 DeepSeek Harness（DSH）Web GUI 的插件：一个系统监控工具，在固定于右上角的浮动可折叠面板中显示实时系统状态。

dsh.so security

功能

- CPU — 实时利用率（根据 os.cpus() 的 tick 增量计算）+ 核心数
- MEM — 已用 / 总量，带百分比条（来自 os.totalmem() / os.freemem()）
- DISK — 已用 / 总量，带百分比条（平台相关）
- NETWORK — 下载 / 上传吞吐量（平台相关的字节增量）
- 前 6 个进程 — PID、名称、CPU%、MEM%（平台相关）
- 深色配色方案（青色 CPU、品红色 RAM、黄色磁盘、蓝色/绿色网络），等宽字体
- 可通过标题栏拖动，可通过 – / + 按钮折叠
- 临时监控进程（ps、awk、head 等）会从进程列表中过滤掉

工作原理

| 部分 | 文件 | 作用 |
|---|---|---|
| 宿主端 | lib/index.js | 注册 GET /api/dsh-top-stats；CPU + 内存使用 Node os API，并带有容器感知的 cgroup 覆盖；磁盘、网络和进程使用各平台收集器，在不可用时降级为 null。 |
| 浏览器端 | lib/client.js | dsh.client Web 包；将面板注册到全框架的 shell.overlay 插槽；每 2 秒轮询一次（折叠时暂停）。 |
| 组合 | cordis.patch.yml | dsh.bundle 补丁层，用于插入加载器条目。 |

平台支持

DSH 宿主代码运行在 Linux 上，但 DSH 服务器可以运行在 Node.js 支持的任何操作系统上。dsh-top 是多平台的：它始终至少报告 CPU + 内存（Node os，无子进程），并在平台允许的情况下填充磁盘 / 网络 / 进程。缺失的部分在组件中显示为 n/a，而不是让整个请求失败。

| 平台 | CPU | MEM | DISK | NETWORK | PROCESSES |
|---|---|:---:|:---:|:---:|:---:|
| Linux | ✅ | ✅ | df | /proc/net/dev | ps |
| macOS | ✅ | ✅ | df | netstat -ib | ps (BSD) |
| Windows | ✅ | ✅ | PowerShell Get-PSDrive | PowerShell Get-NetAdapterStatistics | PowerShell Get-Process† |
| 容器（cgroup） | ✅* | ✅* | df* | /proc/net/dev* | ps* |
| 其他 / 未知 | ✅ | ✅ | n/a | n/a | n/a |

† Windows 进程 CPU 是生命周期平均百分比 — Get-Process.CPU（累计 CPU 秒数）除以进程存活时间，与 Linux ps pcpu 报告的语义相同 — 而 MEM% 由真实 RSS 字节数推导，而非原始工作集值。每个外部收集器（ps、df、powershell 等）都以 5 秒超时运行，因此卡住的工具会将其部分降级为 n/a，而不是挂起请求。

\* 容器支持是容器感知且优雅降级的：
- 内存 — 当设置了 cgroup 内存限制（Docker --memory、Kubernetes limit、systemd unit limit）时，MEM 计量器报告的是容器的限制和当前使用量（cgroup v2 memory.max/memory.current，或 v1 memory.limit_in_bytes/usage_in_bytes），而不是主机的总量。在无限制的 cgroup 上，它会回退到主机的 os.totalmem() 视图。
- CPU 核心数 — 当 cgroup 限制 CPU 时（v2 cpu.max quota/period，或 v1 cpu.cfs_quota_us/period_us），核心数反映该配额；否则使用 os.cpus().length。
- 最紧的祖先生效，哨兵值安全 — 限制文件是通过向上遍历我们自己的 cgroup 路径读取的（而不仅仅是 cgroup 根），因此主机级上限之下的 Docker 限制会被正确报告。内核默认的哨兵值被视为“无限制”：v2 max、v1 CFS -1，以及 v1 memory.limit_in_bytes 在无限制根上报告的约 2^63 字节 — 因此无限制的主机绝不会被误读为拥有 EB 级内存。
- 缺少 df/ps 的精简/distroless 镜像仍会报告 CPU + 内存；缺失的 DISK/NETWORK/PROCESSES 部分渲染为 n/a。

CPU + 内存计量器可在所有 Node 平台上工作。磁盘、网络和进程计量器依赖于所列命令/伪文件的存在 — 否则这些部分渲染为 n/a，而其余部分继续工作。

测试

npm test

对纯收集器解析器运行零依赖测试套件（node --test），使用真实夹具：Linux（df、/proc/net/dev、ps）、macOS（netstat -ib、BSD ps）和 Windows（PowerShell JSON 输出 — 包括 CPU 秒数→百分比和 RSS 字节→百分比的转换），以及 cgroup 文件解析器（memory.max、cpu.max、CFS quota 和“无限制”哨兵值）和实时容器内存/CPU 回退契约。macOS/Windows 解析器在此处验证，无需实时的 Mac 或 Windows 机器 — 只有它们周围的薄命令执行包装器与平台绑定。

安全

由于它是一个系统监视器，主机部分会读取主机范围的 CPU、内存、磁盘、网络和进程状态。跨平台核心（CPU + 内存）使用 Node 内置的 os 模块 — 无子进程，也无操作系统特定的伪文件。Linux /proc 读取通过 Node 自带的 fs.readFileSync 进行。只有需要系统工具的平台收集器才会调用它们 — ps、df，以及在 Windows 上的 powershell — 每次都通过 execFileSync 使用静态 argv 数组（绝不是 shell 字符串，不会对不可信数据进行 shell -Command 插值），因此没有 shell 注入面，也没有攻击者控制的输入。在 Windows 上，PowerShell 子命令是固定的脚本字面量；其值均不来自 HTTP 请求。没有数据离开主机，不读取任何凭据，并且每次读取都是只读的。
dsh.so 的静态扫描器将 node:child_process 标记为“严重”。这只是一个针对进程访问是否存在的启发式信号——并非漏洞。进程访问是监控工具的内在特性；请自行审查（少量）源代码：收集器按平台白名单限定、参数受限且为只读，任何失败都会降级为“n/a”，而不会导致请求失败。

安装

dsh plugin --profile web add dsh-top

然后重启 Web 应用并刷新页面——面板会出现在右上角。

许可证

MIT