轻量服务器监控面板自建：Komari 面板部署与探针接入实战

背景

我手头有两台轻量云服务器，一台在境内、一台在境外，上面陆续跑着定时任务面板、自托管网盘、博客、浏览器容器等一堆小服务。服务一多，靠 SSH 逐台看负载、内存和磁盘就太慢了；之前两次内存耗尽导致整机假死，都是服务全断了才后知后觉。于是我决定搭一个轻量的服务器监控面板：服务端集中展示，每台机器装一个探针上报状态，内存、CPU、磁盘、流量一眼可见，出问题先看到曲线、再处理，而不是等失联了才抢救。

方案：面板 + 探针，两步搭起来

第一步，选型与部署面板。我选的是 Komari，一个 Go 写的轻量监控面板，服务端和探针（agent）分离，资源占用很小，适合 2 核 2G 这种小内存机器。服务端用 Docker 跑，数据目录挂载出来持久化，只把面板端口暴露给内网访问，面板本身也设好内存上限——监控自己不能先变成内存大户。部署时我先在一台机器上跑通，确认看板、探针上线、历史曲线都正常后，再把它迁移到主力机器上：停掉旧容器、把数据目录打一份快照留作冷备、在新机器上起容器、确认面板能打开、历史数据都在。

第二步，逐台接入探针。每台机器上跑一个 agent，填好面板地址和 token，agent 常驻上报 CPU、内存、磁盘、流量和在线状态。agent 本身非常轻，但我还是给它设了内存上限并配好开机自启。探针接完后逐台核对：面板上每台机器都显示在线、数据在更新，才算接完。除了默认指标，我还配了网络质量探测：从监控机定期测几个网络落点的延迟与丢包，用来判断线路质量。

踩坑

一是面板显示“丢包率 100%”，差点以为机器失联。第一次看到这个数字我以为那台机器挂了，结果 SSH 能连、负载很低、业务端口也通。排查后发现是服务商在公网侧禁了 ICMP，ping 包全被丢掉，机器本身好好的。教训：丢包率不能单独看结论，要结合“机器是否在线、业务端口是否通”一起判断；ICMP 不通不等于机器挂了，监控告警要分清是网络探测失败还是服务真出问题。

二是测速结果“假低延迟”。有个落点测出来只有 50 毫秒级，我一度以为这条线路质量很好，后来发现解析命中的是 CDN 节点，根本不是目标机房；另一个落点返回的是全国站点的地址，测的也不是我要的机房。教训：配探测之前，先在目标机器上确认解析结果，anycast 这类解析会给出假低延迟；后来我把其中一个落点改成直连 IP 地址，才拿到真实的延迟数字。监控数据要先验证再采信，否则就是拿着漂亮的假数字做判断。

三是迁移面板后漏改一台探针的指向。面板从一台机器迁到另一台之后，有台机器的 agent 还在往旧地址上报，面板上它显示“失联”，我一度以为是那台机器的 agent 崩了。教训：迁移清单里必须有一项“逐台改 agent 指向并确认上线”，迁完逐台核对，不要凭印象觉得都改完了。探针指向这种配置，漏一台就是一个监控盲区。

四是面板本身也要当成服务来运维。面板挂了等于监控全瞎，所以面板容器要设内存上限、数据目录定期备份快照；旧机器上我留了一份迁移前的数据快照做冷备，万一新面板出问题还能回滚。监控是用来兜底的，兜底的东西自己先得站得住。

总结

小内存机器搭监控，核心就三句话：选型要轻，面板和探针都别吃太多内存；部署要逐台核对，迁移时探针指向一台都不能漏；数据要先验证再采信，丢包率和延迟数字背后可能是禁 ping、CDN 解析这些干扰项。搭好之后的好处很实在：以前是服务挂了才知道，现在是内存曲线往上走、某台机器掉线，面板上第一时间就能看到，先处理再出事。监控本身不产生价值，它产生的是提前量——而对只有 2G 内存的机器来说，这点提前量往往就是“处理一下”和“强制重启”的区别。