Incus 脚本审阅与验收 · 第 7 / 8 篇
把六台小鸡接进一个监控面板，能减少来回登录的次数。但监控页面的一个在线标记，不能自动证明 SSH、业务端口和备份都正常。这篇把 Agent 安装、面板接收与故障恢复分开验收。
这份管理器负责什么
incus_komari_manager.sh 从当前 Incus 远端与项目中列出名称为 vps数字 的实例，要求目标运行中，再进入对应容器安装或卸载 Agent。它不是扫描整个互联网的发现工具，也没有遍历所有 Incus 项目。
安装流程先在宿主机下载官方安装脚本，再推送进目标容器执行。容器里的 systemd 负责服务生命周期，Agent 再向 Komari 服务端上报。宿主机能下载 GitHub，不代表容器一定能连接面板；两段网络都要验证。
为什么关闭 Web SSH
现有配置明确带有 --disable-web-ssh，把监控上报和远程终端能力分开。对当前需求而言，先建立状态可见性，系统管理继续使用已有通道，能减少需要解释和维护的访问路径。它不表示关闭所有远程执行能力，也不应被写成完整安全审计结论。
其他参数包括采集间隔 10 秒、最大重试 5、重连间隔 10 秒和信息报告间隔 15 秒。它们是脚本传入的配置意图；究竟哪个参数作用于连接、采集或上报，应与安装时的 Agent 版本及 --help 一起保存，不要把参数名字推导成 SLA。Komari Agent 官方仓库
测试密钥为什么不能进入公开教程
现存脚本含有明文自动发现测试密钥。公开稿件不保留它的值，也不提供含该值的脚本下载。TEST ONLY 注释不会自动撤销密钥；若它仍有效，应由实际管理员在服务端轮换或撤销，再更新受保护的部署配置。
下一版可以从权限为 600 的配置文件读取面板地址和接入凭据，避免写进公开源码与终端截图；实际日志也要脱敏。这里是配置管理的演进建议，本次编写文章没有擅自更换面板密钥。
active 和在线是两层证据
incus exec vps3 -- systemctl is-active komari-agent
incus exec vps3 -- systemctl status komari-agent --no-pager
incus exec vps3 -- journalctl -u komari-agent -n 50 --no-pager
第一条证明服务被 systemd 判断为 active。然后还要检查日志是否有鉴权、TLS 或连接错误，并在面板核对正确节点的最后上报时间是否持续更新。日志可能包含连接信息，分享之前先检查敏感内容。
最后再做一个应用层检查，例如外部访问容器内的 HTTP 服务。Agent 上报依赖的出站路径和用户访问业务的入站路径不同；一种正常，不足以推断另一种正常。
容器监控的数字应该怎样理解
系统容器共享宿主机内核。CPU、内存、磁盘和网络指标是否按容器限制口径呈现，取决于 Agent 的采集实现及环境。不能看到面板上一个数字，就宣称它代表独占硬件、计费流量或完整的资源隔离。
可在测试实例中对照 incus info vps3、容器内 /proc 与 cgroup 信息、Agent 版本和面板显示，记录口径差异。轻负载、压力负载和重启后分别观察，才有依据决定告警阈值。本文没有现成压测数据，因此不填写虚构的 CPU 占用或内存开销。
卸载以后为什么面板上仍有节点
代码停止并禁用服务，删除官方默认的 unit、程序目录与日志，再检查本地文件和服务状态。面板保存的节点记录属于服务端数据，不会因为容器删了程序就必然消失。教程应分别写清本地卸载与面板清理。
卸载路径是硬编码的；如果用户曾自定义安装位置，不能直接保证清理完整。更稳妥的版本先读取 unit 和实际二进制路径，再显示拟删除清单。容器重装后，Agent 也需要重新部署；还应确认自动发现是否生成重复节点，而不是让面板记录越积越多。
合理的最终效果：选中正确实例、服务运行、面板持续接收、断线后可恢复、重装后节点归属清晰。现有脚本能执行相关操作，但这组结果仍需凭版本、日志和面板时间戳验证。