ProcessGuard — Critical Process Monitor & Auto-Restart

ProcessGuard 综合评估

核心用法

ProcessGuard 是一款面向 DevOps 场景的进程监控与自动重启工具。用户通过 JavaScript API 定义需要守护的进程列表，配置健康检查方式（HTTP/TCP/PID文件/Shell命令）、自动重启策略（最大重启次数、冷却时间）及告警渠道（回调函数/Webhook/JSON文件）。系统以固定间隔轮询检查，检测到进程异常时自动执行重启命令，同时提供可选的 CPU/内存阈值监控和 HTTP 状态仪表盘。

显著优点

1. 零依赖基础功能：核心监控与重启能力无需额外安装，降低部署门槛
2. 多重健康检查机制：支持网络层到系统层的多种探测方式，适应不同服务类型
3. 完善的可靠性设计：内置"看门狗心跳"机制，外部监控可感知 ProcessGuard 自身故障；支持命令白名单限制，降低误操作风险
4. 灵活的告警体系：分级告警（warning → critical）+ 多通道输出，便于集成现有运维体系
5. 开发友好：纯 JavaScript 实现，API 简洁，配置即代码，适合嵌入现有 Node.js 项目

潜在缺点与局限性

• 单点故障风险：作为单进程运行的监控器，若自身崩溃且未被外部系统发现，将失去对所有被监控进程的管理
• 资源监控功能依赖可选包：CPU/内存监控需手动安装 pidusage，并非开箱即用
• Node.js 生态局限：仅适用于 Node.js 环境，无法直接监控非 Node 进程的系统级状态
• 无内置持久化：重启计数、告警历史等状态仅存于内存，进程重启后数据丢失
• HTTP 仪表盘功能简单：仅提供基础 JSON 状态输出，缺乏可视化界面和权限控制

适合人群

• 需要轻量级服务保活方案的 Node.js 开发者
• 中小型项目的 DevOps 工程师，寻求比 PM2 更灵活的自定义监控逻辑
• 边缘计算或资源受限环境，无法运行重量级监控代理（如 Prometheus + Alertmanager）

常规风险

• 命令注入风险：restart 和 check 字段若接收外部输入，可能触发 Shell 命令注入
• 权限提升隐患：通常需以被监控进程同等或更高权限运行，一旦配置错误可能导致非预期进程重启
• 资源竞争：高频检查间隔 + 多进程监控可能在低配置服务器上产生 noticeable 的 CPU 开销
• 告警疲劳：过于激进的自动重启策略可能掩盖根因，导致问题反复出现却未被人工介入

核心用法

ProcessGuard 是一款面向 Node.js 环境的进程监控与自动恢复工具。用户通过 JavaScript 配置对象定义待监控的进程列表，指定健康检查方式（HTTP 端点、TCP 端口、PID 文件或自定义 Shell 命令），配置自动重启策略（重试次数、冷却间隔），并可选开启 HTTP 状态仪表盘。启动后，ProcessGuard 按设定周期轮询检测进程健康状态，发现异常时自动执行重启命令，同时通过回调函数、Webhook 或本地 JSON 文件发送分级告警。特有的"死亡开关"机制每 10 秒更新心跳文件，便于外部监控系统判断 ProcessGuard 自身是否存活。

显著优点

1. 零依赖架构：核心功能无需任何 npm 依赖，仅 CPU/内存监控模块需可选安装 pidusage，极大降低供应链攻击面和安装体积。
2. 多层安全设计：强制命令白名单或显式授权模式，构造时与运行时双重拦截 shell 注入操作符（; & | \ $ < > \n），即使开启 allowAnyCommand` 也无法绕过。
3. 灵活的告警体系：支持警告→危急两级告警，可通过同步/异步回调、HTTP Webhook 或本地文件持久化，适配从开发调试到生产集成的多种场景。
4. 可观测性完备：内置 HTTP 状态仪表盘输出实时 JSON，死亡开关心跳机制实现自监控闭环。

潜在缺点与局限性

1. 命令执行接口风险：使用 child_process.exec 而非 spawn 执行重启命令，虽有多层防护，理论上仍存在 shell 解释风险；高并发场景下同步文件操作可能阻塞事件循环。
2. 来源可信度限制：T3 级别个人开发者维护，无企业级 SLA 保障，生产环境需额外审查。
3. 网络配置完全开放：HTTP 健康检查与 Webhook 目标 URL 完全由用户配置，缺乏内置 HTTPS 强制或 URL 协议白名单，存在误配置导致明文传输的风险。
4. 无依赖锁定文件：缺少 package-lock.json，可选依赖 pidusage 版本未固定。

适合的目标群体

• 个人开发者与小型团队：需要轻量级、低资源占用的本地服务守护方案
• 边缘计算与 IoT 场景：零依赖特性适合受限网络环境
• 开发测试环境：快速搭建服务高可用验证，无需引入复杂编排工具
• DevOps 工程师：作为 systemd/supervisord 的补充，处理特定进程的特殊监控需求

常规使用风险

1. 性能风险：高频告警场景下同步文件操作可能阻塞 Node.js 事件循环；建议监控日志写入频率或改用异步 API。
2. 安全风险：若未配置 commandAllowlist 且误开启 allowAnyCommand: true，配合用户输入污染的配置项可能导致命令执行风险（尽管 shell 注入字符已被拦截）。
3. 依赖风险：pidusage 可选依赖若被恶意替换版本，可能引入供应链攻击；建议锁定版本并审计。
4. 监控盲区：HTTP 仪表盘默认明文传输，若暴露在公网且无反向代理，存在信息泄露风险；死亡开关文件路径需确保外部监控有读取权限。