Uptime Kuma：先你一步发现设备掉线

它到底解决什么

Uptime Kuma 是一款自建的设备在线监控与告警工具。官方仓库对自己的定性很直白：一个"花哨的自托管监控工具"。这里先说清楚"自托管"这个词——软件不装在你的展厅设备上，而是单独找一台机器（公司里的一台服务器、一台云主机，都行）把它跑起来，数据留在这台机器上，不经过任何第三方公司的服务器中转。这跟前面讲过的 RustDesk 是同一个思路：能力自己攥在手里，不看别人脸色。

它干的事情说穿了很简单：按你定的节奏，反复去"敲"一遍你告诉它的每一个目标——可以是一个网页地址、一个网络端口、一条 ping。敲得通，记一笔"正常"；连续几次敲不通，判定为"离线"，立刻把消息发到你指定的地方。

放到展厅场景里理解更直接：每天有人巡场，看设备指示灯有没有灭、屏幕有没有黑，这是人工在做的事。Uptime Kuma 就是把这件事交给一台机器，让它一天二十四小时不间断地做，而且它能做到比任何巡场的人都更早发现问题——设备一掉线，它立刻知道，人巡场最快也要等到下一轮。

展厅哪道工序会用到它

第一道，也是最核心的一道：交付后的无人值守运维。 展厅验收完，机柜里的播控主机、中控主机常年锁在门后没人守着。深夜死机、断网，最先知道的往往不是你，而是第二天开馆前来巡视的甲方工作人员——这通电话打过来的时候，责任已经在你这边坐实了。装了监控，这通电话变成你打给甲方，告知情况已经在处理。

第二道，大型项目的设备清单太长，人工盯不过来。 一个稍大的展厅，网络摄像机、核心交换机、投影机的管理网口、拼接控制器可能有几十台，分散在好几个弱电间。靠人一台台去点确认状态，效率低还容易漏。把这些目标全部登记进监控系统，谁掉线了，界面上和消息里都会直接标出来。

第三道，售前阶段把"远程运维响应"写进方案。 报价单上写"我们提供 7×24 小时远程运维响应"这句话，甲方凭什么信？靠的就是背后这套东西——第五节会展开讲这笔账怎么算。

第四道，验收交付时的证据材料。 系统稳不稳定，嘴上说没用，监控记录下来的连续在线时长、故障发生和恢复的时间点，是能拿出来给甲方看的凭证，比一句"我们的设备很稳定"有说服力得多。

怎么获取，装在哪台机器上

先纠正一个容易想岔的地方：它不是一款装在自己电脑上给自己用的软件，是一套"服务"。拿到手第一件事不是双击安装，而是先决定这套服务放在哪台机器上跑——这个决定本身就是个技术判断，展开在第五节讲，这里先说获取渠道。

官方只有一个可信来源：GitHub 上的开源仓库，代码完全公开、免费，本页 frontmatter 里的 homepage 就是这个入口。跟前面几篇软件页强调的一样，第三方下载站打包的同名版本一律不要碰，来路不明的部署脚本风险太大。

部署方式官方给了两条路，交给做实施或运维的技术同事去执行即可，这里说清楚各自的适用场景：

• 容器化部署——把整套软件连同它需要的运行环境打包成一个独立的"盒子"，跑在这台机器上但不会跟机器里其它软件互相干扰，官方文档把这条路放在最前面推荐。适合已经有一台 Linux 服务器打底、平时也用这种方式管其它服务的团队。
• 直接在系统里跑——不用打包，但要求这台机器提前装好几样开发工具环境。官方明确写了平台范围：主流 Linux 发行版和 Windows 系统都支持直接这样装；一些小众的类 Unix 系统和几个特定的云函数托管平台不支持。投标前如果甲方指定了操作系统环境，这条清单值得提前核对一下，免得答标之后才发现装不上。

费用上不用为它单独报价：完全开源免费，官方没有另外卖一套加强版。官网上能看到接受捐赠的入口，但那只是赞助渠道，不解锁任何额外功能——报价时可以明确告诉甲方，这部分软件本身成本是零，真正要收费的是部署实施和后续维护这两块人工。

最短可用路径

跑起来之后，你会得到一个网页管理界面——注意这个界面是装在"监控机"这一台机器上的，不需要在每台被监控的设备上装任何东西，被监控的那些机器只是被动地"被敲门"。

1. 先定好监控机放哪。 这一步比后面所有操作都重要，理由第五节详细讲，这里先记住结论：不能跟被监控的设备挤在同一条网络、同一个电源上。
2. 按官方文档跑起服务。 这一步交给做部署的同事，一条命令的事，不用自己摸索命令细节。
3. 打开管理页面，设个账号密码，登记第一个要盯的目标。 填上目标地址、选一种检测方式（网页、端口、ping 之类）、定一个检测节奏，保存。
4. 配上告警接收方式。 从官方支持的一长串渠道里选一个，填上对应的接入信息，这一层的取舍在第五节展开。
5. 故意断开一次那台被监控的设备，看告警是不是真的到手机或群里了。 这一步官方操作说明里不会专门提，但每个项目交付前都必须做——配置界面上显示"已启用"不代表现场真的会响。这跟前面 RustDesk 篇讲的断电测试是一个道理：亲眼看到告警落地，才算数。

展厅工程里真正要弄明白的那几件事

这一节是全篇的重点。机制细节不用记，下面这几条判断，现场实施和售前答标都用得上。

监控什么，才对得起这套系统

值得挂上去的对象：播控主机、中控主机的网络接口，网络摄像机，核心交换机、路由器，联网型号投影机的管理网口，拼接控制器——凡是"断电、断网会让甲方比你先发现问题"的东西，都该进这份清单。

但必须单独强调一条最容易被忽略的局限：能连上不等于展项正常。 Uptime Kuma 常用的探测方式，说白了大多是问一句"你还活着吗"——只要对方那台机器的系统还在跑、网口还通，它就会答"活着"。可现场真实发生的故障，往往是屏幕已经卡死、播放软件早就白屏崩溃了，操作系统本身却一点事都没有，网络也照样通——这种情况下，最基础的探测方式一样会得出"一切正常"的结论。这条边界报价和验收时都必须讲清楚：这套系统证明的是"设备在线"，不是"展项好看"。

官方给了两条能往前多走一步的路子。一是对带网页管理界面的设备，检测时不光看"打得开打不开"，还能额外核对返回的网页内容里有没有出现指定的一段文字，这样能多抓一部分"网页打得开、但内容不对"的情况。二是反过来，让被监控的那个程序自己按节奏"打卡"上报"我还活着"，而不是外部去猜——这个模式对播控软件这类没有网页界面、外部探测不到内容的黑盒程序尤其有用：只要请负责开发播放程序的同事在里面加一小段定时打卡的逻辑，就能把"进程没退出但其实已经卡死不动"这种最麻烦的一类故障也纳入监控范围。这已经超出现场实施能改动的范围，需要在项目立项时就把这条需求提给软件开发同事，写进播控软件的规格里。

告警发到哪，才算真的有人看见

发出去和有人看见，是两码事。见过不少项目监控是装了，告警配置的是一个没人查的邮箱，最后跟没装一样。

官方支持的告警接收渠道单子相当长，实测核对过官方仓库的源码目录，钉钉、企业微信、飞书这几个国内团队日常真在用的渠道都在列表里——这一点不是每一款监控软件都覆盖到，选型时值得确认。选哪个渠道不是技术问题，是团队习惯问题：先搞清楚团队平时出故障是在哪个工作群里喊人处理的，把告警接进那个群，而不是另开一个没人加的新群。

售前建议按两级配：第一级接进项目日常沟通群，负责现场响应的人第一时间能看到；第二级留一份给自己的管理群或个人，作为兜底——只配一级的话，负责响应的人请假或者换人交接的空档期，告警等于发给了空气，没人接。

装在哪台机器，这个判断现场最容易搞反

核心判断题只有一个：监控机装在展厅现场，还是装在公司或云上？

装在展厅现场机柜里，看着方便，隐患也最大——现场一旦整体断网、断电，或者机柜本身就是这次要盯防的对象出了问题，监控软件自己也跟着一起哑掉。最该被第一时间发现的那次故障，恰恰是监控系统自己也说不出话来的那一次，这就本末倒置了。

正确的判断是：监控机不能跟被监控的东西挤在同一条网络、同一个电源上。放在公司内部服务器或者云主机上，是更合适的位置——只有"人在展厅之外"的这台监控机，才能在展厅整体掉线这种最严重的情况下发出告警。

如果甲方明确要求"数据不能出内网"（政务、金融类项目常见），那就只能把监控机放在甲方内网里的另一台机器上，退而求其次也要守住一条底线：跟被监控设备至少不共用同一路电源，条件允许的话再接一条独立的网络出口。

售前价值：能写进报价单的一项服务

"远程运维响应"这句话能不能单独收费，取决于背后有没有真东西撑着，不是一句口头承诺就能报价的。前面这套自建监控，加上另一篇讲过的 RustDesk 这类远程接管工具，合在一起才是"设备出问题我们能第一时间知道、并且不用跑现场就能处理"这句承诺的技术底座。报价单上可以把它单独列成一个条目，而不是含含糊糊塞进"交付后免费维保"里，让甲方以为这本来就是白送的。

踩坑与排错清单

什么时候别用它

展项本身白屏、播放软件卡死，但操作系统和网络都还正常的场景。 前面反复强调过：默认的探测方式回答不了这个问题，除非按第五节接了应用自己打卡的模式，否则这类监控天然发现不了内容层面的故障，别把它当成能包打一切的哨兵，跟甲方交底时也要说清楚这条边界。

需要秒级、毫秒级实时联动的场景。 比如安防报警这类分秒必争的用途，它是周期性反复探测的思路设计的，检测节奏调得再密也是"隔一段时间问一次"，不是逐帧监听，指望它做到消防、安防级别的实时联动不现实，这类需求应该走专门的联动系统。

甲方内网明令禁止部署第三方开源软件、必须先过安全审批的项目。 跟前面 RustDesk 篇一个道理：这是流程问题，技术上再合适也没用，先谈审批流程，别先装上再想着补手续，展厅项目最怕这类事后被查出来。

完全不打算为它准备一台常年开着的机器、也不接受自己维护这台机器的项目。 它没有官方运营的长期免费在线版本可以白嫖——官网那个体验环境是限时试用性质，数据会被清空，不能当生产环境用。真不想自己扛这一摊，不如直接用现成的第三方在线监控服务。

与本站的衔接

• 监控发现设备掉线之后，怎么不跑现场就把问题处理掉，见 RustDesk 软件页——一个负责先知道，一个负责能远程动手，两个配合起来才是完整的运维闭环。
• 展厅远程运维的整体思路，不同网络环境、有人无人值守该怎么选路子，见 远程运维专题。
• 把"7×24 小时监控告警"这类服务条目写进投标方案和报价单，可以参考行业方案里各类展厅项目的运维章节写法。

从「能连进去」到「先于甲方知道」

远程接入解决的是「我要看到那台机器」，它的价值上限取决于你多快知道该看。展厅出故障到集成商知晓之间，往往隔着甲方发现、内部反馈、打电话这几个环节，延迟以天计。

企服君的运维体系是主动上报模式：设备状态、异常事件由系统推给你，远程接入只是最后的处置手段。集成商如果想把运维从售后成本变成可以向甲方收费的服务，见集成商年费方案。

出处

• Uptime Kuma 官方 GitHub 仓库主页：https://github.com/louislam/uptime-kuma
• 官方仓库 README（功能列表、部署方式、平台支持范围）：https://github.com/louislam/uptime-kuma/blob/master/README.md
• 官方 Wiki《How to Install》（容器化部署与直接部署两种方式、平台支持清单、反向代理注意事项）：https://github.com/louislam/uptime-kuma/wiki/%F0%9F%94%A7-How-to-Install
• 官方仓库通知渠道源码目录（核实钉钉、企业微信、飞书等国内渠道是否在官方支持列表内）：https://github.com/louislam/uptime-kuma/tree/master/src/components/notifications

本文所述的功能、部署方式与限制均来自上述官方材料；文中涉及的展厅工序判断（监控对象取舍、告警分级、监控机选址）属于工程经验总结，具体项目请以现场实际情况为准。