我用 Pulse 替换了四个监控仪表盘，但有一个工具死活离不开

每次我坐到工作站前，都会本能地打开多个仪表盘查看我的家庭实验室状态，然后才开始做其他事情。这已经成了一种习惯，我几乎都没注意到自己在这么做。我通常先打开Beszel 查看服务器健康状况，接着再看 Uptime Kuma；如果发现什么不对劲，就打开 Portainer 看整体服务器状态，再打开 Scrutiny 看磁盘相关的情况。

我对这些监控工具本身没有任何意见。但我花在来回看仪表盘上的时间，比真正干活的时间还多。我需要的只是一个仪表盘，扫一眼就知道一切是否正常，然后接着干别的。就在那时，我发现了 Pulse。看起来它一个就能替代其他所有仪表盘——但也不尽然。

折腾家庭实验室最难的部分不是搭建。而是出了问题知道该上哪儿看。

实际上什么都没有坏

我只是检查了太多地方。

随着我的家庭实验室不断扩展，我开始更加认真地对待正常运行时间和健康状况。监控是我后来根据需要慢慢加上去的，不是一开始就有的。最初我只运行了几个服务，而且用户只有我自己，所以觉得搞监控有点多余。我只需偶尔打开 Portainer 查看一下情况即可。但随着容器数量从几个到十几个，再到二十几个，一个个手动去看根本不现实。

不仅是容器状态，我的服务器健康状况也让我操心。先说一下背景，我拿一台8年前的老笔记本废物利用搭的家庭实验室服务器。这台笔记本是戴尔Latitude 7480，配备酷睿i5-6300U处理器、大约12GB内存和256GB固态硬盘。所以往上塞20多个容器，感觉真是把它榨得一点不剩。家庭实验室用了快一年之后，我逐渐添加了各种监控服务——Uptime Kuma用于面向公众的服务（通过Pangolin），Beszel用于服务器资源监控，Scrutiny用于磁盘SMART健康监测。Portainer本来就在管内部的Docker容器。

它们加在一起，把我对家庭实验室健康和在线状态的所有疑问都包了。无论是“我的公共服务是否在线？”还是“服务器是否负载过高？”哪个仪表盘对应哪个疑问，我就打开哪个，答案立马就有。但问题恰恰出在这儿。我拥有所有信息，但它分散在四个不同的仪表盘上。它们之间不打架，但谁也不搭理谁。

比如Portainer里显示某个容器跑得好好的，Beszel那边却显示服务器内存吃紧。与此同时，Uptime Kuma亮着绿灯，某个容器却在反复重启。这些仪表盘之间没有直接关联——全靠我自己手动把它们串起来。所以，很长一段时间里，我一直在找一样东西，能告诉我到底要不要去翻其他仪表盘。

Pulse 开始连接一切

一个仪表板替代了原先的两个。

我像往常一样，空闲时刷着 Reddit 帖子，偶然看到一个帖子，楼主在求推荐 GUI 监控和管理工具。我随手点进去翻了翻评论；大部分人推荐的是 Beszel 和几个基于 CLI 的工具。有人甚至推荐了 Komodo，另一个推荐了 Pulse。还有几个人也跟着推荐。于是，我决定去看看它的 GitHub 仓库和官网首页。

光看官网首页我就有一半心动了——首页顶部那句标语，“全天候监控你整个基础设施的系统管理员，”功不可没。另一半来自它提供的在线演示。于是我决定试一下，在自己的 homelab 上自托管了社区版。配置好之后第一次登录，我一眼就看到了平时得在好几个仪表板之间来回切换才能看到的信息。

光 Docker 仪表板就够说明问题了，比如主机健康、已停止的容器、需要更新的容器、启动/停止/重启操作，以及每个容器的指标。以前我得开好几个 Portainer 标签页，还得顺手瞄一眼 Beszel 仪表板。

告警标签页给我的信息量最大；在总共241条告警中，它已经将177条过滤为严重，64条过滤为警告，把无关的杂项告警排除在外。在我没有进行任何配置的情况下，它已经把更严重的问题标了出来，比如Pi-hole运行不健康，以及Meilisearch和cloudflared因OOM被终止。

这是我第一次觉得有个工具能在一个仪表盘上回答我的日常问题，比如“有什么需要我关注的吗？”不过它并不完美。

Pulse并没有取代一切

有一个仪表盘仍然有它的一席之地。

Pulse成了主页。Beszel没有被删除，Portainer也没有被冷落——它们只是不再是我打开的第一个标签页。我还有两个工具没有动过——Uptime Kuma和Scrutiny。我想看看Pulse能否接管Kuma正在做的事情。于是，我决定探索Pulse的设置。我发现了一大堆我还没用过的功能。正如我之前提到的，我主要用Uptime Kuma来监控对外服务的在线状态。我开始在Pulse的可用性监控功能里添加那些URL。我把五个站点全加上了——Jellyfin、Immich、Nextcloud、ntfy和Vaultwarden。

在添加服务的过程中，我注意到一件事：“低于500的HTTP状态码被视为可访问。”当时，我选择忽略它，因为我认为这不是什么大问题。当所有五个服务都添加完毕后，仪表盘开始为它们全部显示绿色对勾。由于我的服务都没有出现任何故障，我决定人为制造一次故障。我故意停掉了我的Vaultwarden容器，因为它是最不常用的一个。令人惊讶的是，它居然把它判定为在线。我查看了Pulse内部的容器仪表盘；那里也显示它已停止。我查看了Pangolin仪表盘；那里也显示它已宕机。

经过几次故障排查后，我尝试将线索串联起来。由于Vaultwarden在Pangolin中位于SSO之后，即使容器已停止运行，它仍然返回403状态码。而正如之前提到的，这时候我才想起前面说的：低于500的HTTP状态码也算在线。由于返回的是403而非502，Pulse还是把它当成在线的。一旦我绕过了Pangolin对/alive端点的SSO，Pulse立即正确地监控了它。之后，我通过webhook将告警连接到了ntfy实例。这样一来，从发现问题到通过ntfy实例发通知，整个流程就打通了。尽管Kuma提供了更细粒度的监控，比如超时和预期响应，但Pulse对我的配置来说已经足够了。

在完成所有这些之后，我仍然没有找到其中一个仪表盘的替代品。Pulse监控服务、容器和服务器，但它不像Scrutiny那样监控SMART数据。Pulse仪表盘只展示了基本的磁盘信息，如使用量、可用空间和总存储容量，但这跟一行终端命令能显示的信息差不多。

在寻找替代 Scrutiny 的工具时，我偶然发现了 Patrol。这是之前的工具都没有提供过的东西。它本质上就是对我服务器数据做 AI 分析。起初我忽略了它，因为我不想让我的家庭实验室去连云端 LLM。但深入探究后，我发现它支持通过 Ollama 集成本地 LLM。我之前实验时已经在家庭实验室里部署了一个小型 LLM（qwen2.5:1.5b），所以我马上就决定试试 Patrol。虽然我有点怀疑这个小模型能不能跑得动，但当我运行就绪检查时，我惊讶地发现它显示：“所选模型可以在当前安装环境中执行 Patrol 的任务。”

它成功完成了首次手动运行，尽管还没遇到过真实事件来真正检验它自己。它看起来很有前景，但还没让我真正信得过它。测试结束时，Pulse 虽然没有成为我唯一的监控仪表盘，但它已经成为我第一个打开的仪表盘。

习惯变了。技术栈还没变——至少目前没有。

当我决定尝试 Pulse 时，我本来没打算替换掉现有的任何监控工具。我只是想找个东西，让我不用每天打开两三个不同的监控仪表盘。试用 Pulse 几天后，技术栈虽然没变，但我的工作流程确实变简单了。对于我的家庭实验室来说，它让我不用每天再打开 Uptime Kuma、Beszel 和 Portainer（看容器健康状态）了。Scrutiny 保留了下来，因为 SMART 监控本来就不是 Pulse 要做的事。我还配置了 Patrol，它通过了就绪测试并顺利完成了首次运行，但我还没看出来它在长期服务器监控上到底能帮上什么忙。Pulse 并没有完全取代我任何一个监控工具，但它已经在我家庭实验室里站稳了脚跟，而且成了我每天第一个打开的仪表盘。