Checkmk 实战：用免费开源监控管住整个家庭实验室

家庭实验室的痛点从来不是「没有东西可监控」，而是「东西太多、太杂」。Linux 服务器、Docker 容器、Proxmox 虚拟机、NAS、交换机和 AP、Plex、Home Assistant，再加上最近冒出来的一堆 AI Agent——每一样都可能在某天悄悄挂掉，而你毫无察觉。Checkmk 社区版给出的答案是：用一个免费开源平台把这些全部收进来，再让 AI 接管告警和配置。

Checkmk 是什么，为什么值得装

Checkmk 是一套开源监控系统，社区版免费。它的覆盖面相当夸张：主机、服务、虚拟机、容器、网络设备、网站、甚至你自己写的脚本输出，都能变成统一的监控项。据 YouTube 频道 NetworkChuck 的完整实操演示，从下载到跑起来不到五分钟。

它的核心机制是「插件 + Agent + 特殊 Agent」三条腿走路。Agent 装在目标机器内部，负责上报 CPU、磁盘、进程等本地数据；特殊 Agent 不落地安装，而是通过 API 主动拉取（比如 Proxmox、HTTP 网站、UniFi 控制器）；插件则决定哪些服务能被自动发现并纳入监控。三者可以叠加使用——同一个主机既跑 Agent 又配特殊 Agent，等于从内外两个视角同时观察。

社区版的门槛在于「要动手」：不少高级插件默认不启用，需要手动下载、赋权、配置。这是免费的代价，但流程一旦走通，后续扩展就很顺。

特殊 Agent（Special Agent）与 Agent 的区别：普通 Agent 以守护进程形式常驻目标主机，主动采集并推送数据；特殊 Agent 则完全不在目标主机上安装任何东西，而是由 Checkmk 站点定期调用一个本地脚本，通过目标系统的 API（HTTPS、SNMP、数据库协议等）拉取数据。因此特殊 Agent 适合那些不方便安装 Agent 的设备，比如网络设备、虚拟化平台、SaaS 服务和各种 Web API。它采集到的数据同样会经过服务发现流程，只是数据来源是“拉”而非“推”。

服务发现（Service Discovery）：Checkmk 不会预先假定一台主机上有哪些监控项，而是先运行一次发现流程，枚举出 Agent 或特殊 Agent 实际能上报的所有检查项，再由用户确认哪些纳入监控。这一机制的好处是主机角色变化（新增容器、新挂载文件系统、新起进程）后可以重新发现并增量纳入，而不是手工逐条添加。

从裸机到容器：主机监控的三种典型接入

最基础的接入是添加 Linux 主机。填入 IP 后，Checkmk 会提示你安装对应发行版的 Agent 包，装完在界面点「测试 Agent 连接」，通过后执行服务发现——它会自动列出这台机器上所有可监控项，包括被插件识别出的异常，比如演示中就当场发现一个 NFS 服务处于 critical 状态。

Docker 监控需要多绕一步。虽然 Agent 能装、主机能加，但 Docker 容器信息依赖 mk_docker.py 插件，社区版不会自动启用。流程是：在 Docker 主机上装 Python3-Docker 依赖，下载插件到 Agent 的插件目录并 chmod +x，再从示例配置生成一份 docker 配置文件，然后重新服务发现。容器本身还需要通过「piggyback」机制挂到父主机上——新建一个不分配 IP、不启用 Agent 的文件夹，设置「始终使用并期望 piggyback 数据」，再把容器名以 CSV 批量导入。听起来繁琐，但这套逻辑让容器指标能正确归属到宿主机。

Windows 端反而简单：界面上直接下载 Agent 安装包，装完如果连不通，多半是防火墙没放行，加规则后重启 Agent 服务即可。演示中接入 Windows 录制机后，立刻暴露出网卡协商速率低于预期、系统盘接近写满、Windows 时间服务未运行等问题——这些平时完全不会注意到的隐患。

Piggyback 数据机制：在 Checkmk 中，某些监控数据并不是由被监控主机自己上报，而是由另一台主机“捎带”过来——数据里携带了真正归属的主机名，Checkmk 据此把指标挂到对应主机上。Docker 容器就是典型场景：容器指标由宿主机上的 Agent 采集，但每条数据标注了容器名，因此需要为每个容器创建一个“ piggyback 主机”（不分配 IP、不装 Agent），并声明它只从 piggyback 数据中获取信息。这样容器就能像独立主机一样拥有服务、告警和视图，而实际采集负担仍落在宿主机上。

网络设备与 Web 服务：SNMP 与 HTTP 检查

网络设备靠 SNMP。在交换机或控制器上启用 SNMP（v2 或 v3），配好 community string，然后在 Checkmk 里建一个网络文件夹、开启网段扫描并填入 SNMP 凭据。扫描会自动发现子网内的设备，界面会弹出「发现新主机」的变更提示，确认后即可批量纳入。演示中一台 24 口 UniFi 交换机被发现后，立刻能看到所有接口状态、CPU 利用率、运行时长，其中某个端口已连续在线超过一年，属于该重启的典型。

网站监控走 HTTP 规则：新建规则、添加 endpoint、填 URL，可以校验状态码，也可以搜索页面正文里的特定字符串——这招能防页面被篡改或劫持。演示里把期望字符串改成不存在的词，服务立刻转为 critical，改回来又恢复。Proxmox 则通过用户名密码接入其 API（默认 8006 端口），无需在宿主机上装任何东西，就能拿到虚拟机、存储、快照年龄等数据。把 Docker 主机的名称改成与 Proxmox 内一致后，Checkmk 还能识别出「这台 Docker 主机其实是一台 VM」，补上内存占用等虚拟化层指标。

SNMP 与 community string：SNMP（简单网络管理协议）是网络设备最通用的带外管理协议，交换机、路由器、AP、UPS 普遍支持。Checkmk 通过 SNMP 轮询设备上的 MIB 对象（接口状态、流量计数、CPU、温度等）来生成监控项。v2c 使用明文 community string 作为“密码”，配置简单但安全性弱；v3 支持用户名、认证和加密，适合对安全有要求的环境。网段扫描时，Checkmk 会向子网广播 SNMP 请求，凡是有响应且凭据匹配的设备都会被识别为候选主机。

插件生态：从官方集市到 AI 现写

内置插件只能覆盖常见场景，真正的上限在插件集市 exchange.checkmk.com。演示中从集市下载了 UniFi 控制器插件，用 mkp add 和 mkp enable 安装启用（注意要先切换到监控站点用户），再配规则、做服务发现，就能看到每个 AP 下所有 SSID 的性能。

更激进的做法是让 AI 现写插件。演示中让 AI 基于 Plex token 生成一个脚本，实现「谁在看、看什么、几个流」的监控，然后用「集成 Nagios 插件」规则以命令行方式挂上去，几分钟就跑通了。同理还接了 Home Assistant（摄像头在线数、实体数量、灯光开关、空气质量）和自建的 Hermes Agent——后者通过 Agent 本地脚本目录里一个自定义脚本上报 cron 状态、网关存活、模型登录有效期、使用量等指标。这意味着：只要你能写成脚本并输出指标，Checkmk 就能监控，边界只剩下想象力。

Checkmk 插件包（MKP）：集市上的插件以 .mkp 包形式分发，本质是一个打包了检查脚本、规则集、WATO 配置和元数据的压缩包。安装分两步：mkp add 把包注册到站点，mkp enable 激活其中的组件；两步都必须在监控站点用户（通常是 omd 站点用户）下执行，否则文件权限和站点路径会对不上。启用后还需要在界面里配置对应规则并重新做服务发现，插件才会真正产出监控项。

告警闭环：从 Slack 通知到 AI 自动修复

监控的价值在告警。Checkmk 的通知规则支持 Slack、Mattermost 等通道，配 webhook 即可。演示中手动停掉一个 Agent 网关，约一分钟后 Slack 收到告警，恢复后同样推送恢复通知。

再往前一步是把告警变成工单交给 AI。演示中通过脚本把指定主机、指定服务的告警推送到一个 AI IT 部门系统，生成任务后由 AI 自动执行修复——重启网关、确认服务恢复，全流程无需人工介入。这一步把「发现问题」和「解决问题」串成了闭环。

最后是反向操作：给 AI 开一个自动化账号（automation secret，管理员角色），让它直接调用 Checkmk API 批量添加剩余主机、生成定制仪表盘。演示中 AI 一次性纳入了全部主机，并生成了按问题聚合的概览看板。这等于把监控系统本身也变成了可编程对象。

免费版与商业版的边界

需要说清楚的是，社区版虽然功能完整，但很多自动化步骤要手动完成，比如 Docker 容器的批量导入。Checkmk 另有 Pro、Ultimate（含多租户 MT 版本）和 Cloud 三个商业版本，能把这些繁琐环节自动化。官方还提供 Ultimate 的免费试用，单站点 750 个服务以内不收费——对中小规模家庭实验室来说，这个额度相当宽裕。

总体判断：Checkmk 不是那种装完就忘的轻量工具，它要求你理解 Agent、特殊 Agent、插件、piggyback 这几个概念。但一旦搭好，你获得的是对整座实验室的完整可见性，而且能顺手把 AI Agent 也纳入同一套监控和自动化体系。对于已经有相当规模基础设施、又不想为监控付费的家庭实验室玩家，这大概是目前性价比最高的选择。