资源遥测¶
进程计数器来自一个独立的 Rust 监视器,使用 sysinfo。Electron 主进程提供主机功耗和 Electron 进程指标。将原生采集放在 Node 之外,可隔离采集器崩溃,并避免 Node/Electron 插件 ABI 矩阵。桌面端和 CLI 服务器使用相同的子进程协议。采集器缺失或失败时,服务器仍会继续运行。
采集开销¶
原生子进程负责采样并维护有界的内存历史记录。只有在诊断存在活跃订阅者时,它才会按定时器采样。若没有订阅者,服务器会发送采样间隔 0,子进程仅在收到请求时采样,因此空闲服务器从不会遍历进程表。唯一的例外是 OTLP 指标导出:导出指标的服务器每分钟请求一次采样,并按组导出进程总计(ProcessGroupMetrics),因为用户要求持续遥测。组是固定的集合,以服务器的直接子进程命名,绝不用进程 ID 或线程命名,因此随着代理进程的来去,序列数量保持有界。历史记录只覆盖存在活跃订阅者的时间段,外加按需采样和导出采样。为后台调度而消耗主机功耗,不得使诊断保持活跃。不存在遥测数据库,也没有定期 shell 探测作为回退方案。
历史记录对时长、快照数量、进程行数和保留字节数分别设有独立上限。当命令行大小各异时,仅靠数量限制无法约束内存。因此,较大的进程树会缩短可用的历史窗口。Linux 的任务枚举已禁用,因为遍历每个 /proc/<pid>/task/<tid> 目录会使采样本身变得昂贵。
Electron 的功耗更新通过私有继承管道传输,与渲染器连接无关。即使诊断功能关闭,功耗事件和慢心跳也会继续;app.getAppMetrics() 仅在实时需要时运行。接收方的过期时限必须超过最慢的已配置心跳加上调度宽限,否则有意的空闲轮询会让后台策略在受限与不受限状态之间反复切换。在无头服务器上,不可用的功耗数据保持未知。
测量陷阱¶
- 进程身份包含启动时间,因为操作系统会复用 PID。Electron 和原生进程的启动时间精度不同,因此合并时允许较小容差。进程信号发送会使用新采样重新检查原生身份。
- 快照序列号属于某一代监视器。跨重启比较它们会丢弃新监视器的样本,直到其序列号追上来。
- 采样可能漏掉在两次采样之间启动并退出的进程。对于跨样本观察到的进程,累计计数器仍能产生增量。
- Windows 进程 I/O 不仅包含磁盘流量。Unix 计数器报告的是存储 I/O,由于操作系统缓存,这可能与逻辑上的应用读写不同。请将已插桩的逻辑 I/O 与这些计数器分开。
- 组总计会累积自遥测开始以来观察到的增量。单进程累计计数器覆盖该进程在操作系统中的生命周期。
- 历史回放使用原生样本,不包含当前 Electron 的 CPU 或内存指标。合并最新的 Electron 值会覆盖过去的数据。
WSL 后端需要 Linux 监视器,即使 Electron 运行在 Windows 上。Windows 桌面包目前只提供 Windows 可执行文件,因此 WSL 后端的原生进程遥测不可用。继承的 Electron 功耗馈送仍然有效。
本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 t3/t3code