展厅设备半夜掉线，怎么让自己比甲方先知道

那通让人下不来台的电话

展厅交付验收，机柜锁上，大家都松了口气。真正的考验从这一刻才开始：播控主机、中控主机、一屋子网络设备，此后大部分时间没人守着。某天半夜，某台机器死机、断网，第一个知道的不是你，是第二天早上开馆前来巡场的甲方工作人员——电话打过来的时候，责任已经在你这边坐实了，你连”什么时候坏的、坏了多久”都答不上来。

这篇要解决的就是这一件事：怎么让自己先知道，而不是等甲方打电话来问。

先说清楚监控什么

不是所有设备都值得挂上监控。真正该进这份清单的，是”断电、断网会让甲方比你先发现问题”的那一类：播控主机、中控主机的网络接口，网络摄像机，核心交换机、路由器，联网型号投影机的管理网口，拼接控制器。这些设备要么是展项能不能跑起来的关键节点，要么是甲方一眼就能看出异常的门面，掉线了藏不住。

监控的做法说穿了很朴素：找一台机器，按你定的节奏反复”敲”一遍这份清单里的每一个目标——可以是一个网页地址、一个网络端口、一条 ping。敲得通，记一笔”正常”；连续几次敲不通，判定为”离线”，立刻把消息发出去。这跟人工巡场是同一件事，区别是它一天二十四小时不间断地做，而且比任何巡场的人都发现得早。

站内这套自建监控用的是 Uptime Kuma，后面几节讲的判断都以它为准，不重复介绍它怎么部署，直接看它的软件页。

一条必须讲透的局限：能ping通，不等于展项正常

这是全篇最容易被忽略、也最不该被忽略的一条边界，必须老实说清楚，不能把监控吹成万能。

监控最常用的探测方式，说白了大多是问一句”你还活着吗”——只要那台机器的系统还在跑、网口还通，它就会答”活着”。可现场真实发生的故障，往往是屏幕已经卡死、播放软件早就白屏崩溃了，操作系统本身却一点事都没有，网络也照样通。这种情况下，最基础的探测方式一样会得出”一切正常”的结论。监控面板上一片绿，展厅里那块屏可能已经黑了半小时。

这条边界报价和验收时都必须讲清楚：这套系统证明的是设备在线，不是展项好看。监控发现不了软件层面的故障，这不是这套工具做得不够好，是它这套方法论天生管不到那一层。

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

装在哪，是现场最容易搞反的一道判断题

监控机放在哪，比配置本身重要得多，也是现场最容易搞反的一步。

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

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

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

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

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

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

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

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

网络得先打通，监控才有路可走

前面几节的前提是：监控机能连到被监控的设备。如果甲方机房没有公网 IP、也不开端口映射，这个前提根本不成立——不是监控软件不好用，是网络这一层压根没打通。

这种情况下，先解决链路问题，指路 frp：它能在不需要甲方开任何端口映射的前提下，让内网机器”喊”出来，是这类死结的标准解法。但这里有一条比技术细节更重要的红线：内网穿透在政企、金融、涉密类展厅项目里常被明令禁止，装之前必须先拿到甲方 IT 的书面同意，不能想着先装上再说，反正甲方也不懂——这不是免责套话，是真实会出事的流程问题，投标和签合同阶段就该把这层沟通做完。

网络打通之后，监控要连的是哪一层，也要分清楚：如果只是要”先知道掉没掉线”，监控探测本身走通网络就够；如果掉线之后还想不跑现场就能处理，那还需要一层能连上去动手的工具，这部分不在本文展开，见下一节的衔接。

售前价值：能写进报价单，但别把话说满

“远程运维响应”这句话能不能单独收费，取决于背后有没有真东西撑着，不是一句口头承诺就能报价的。前面这套自建监控，是”设备出问题我们能第一时间知道”这句承诺的技术底座。报价单上可以把它单独列成一个条目，而不是含含糊糊塞进”交付后免费维保”里，让甲方以为这本来就是白送的。

但要把话收住：监控解决的是”知道”，不是”响应速度”。告警多快能送到手机或群里，取决于网络和渠道配置，这一层可以说清楚；但从收到告警到有人真正动手处理、处理完需要多久，取决于谁值班、人在不在、要不要跑现场，这是人和流程的事，不是监控软件能保证的事。答标时可以承诺”我们会第一时间知道”，不该承诺”多少分钟内必然处理完”这种监控软件本身兜不住的时效数字。

小项目和多点位项目，配置思路不一样

单点小项目，如果甲方能开端口映射、或者本来就有公网 IP，直接在监控机上装 Uptime Kuma，把前面说的那几类关键设备登记进去，配好告警渠道，基本就够用，不需要额外折腾内网穿透这一层。

几十台展项设备分散在好几个楼层弱电间、甲方机房又没有公网 IP、还要求交付后长期无人值守的大项目，思路是三层叠着用：frp 先把内网机器”喊”出来打通网络，监控软件（Uptime Kuma）负责先于甲方发现掉线，另外还需要一层能连上去动手处理的远程工具负责把问题真正解决掉。三层各管一段——网络通不通、掉线知不知道、问题能不能远程解决，缺一层，这条无人值守的闭环就是漏的。这三类工具怎么分工、怎么组合，站内已经整理成一张对比表，见下一节。

与本站的衔接

• 掉线之后不跑现场怎么处理，以及监控、远控、内网穿透这几类工具各自的边界与组合思路，站内已经整理成一篇选型对比，见 展厅工程机远程运维，六种方案怎么选——本文不重复它的对比表格，只讲”怎么先知道”这一件事，两篇配合着看。
• 监控告警只解决”设备在不在线”这一层，网络层面的丢包、延迟排查是另一件事，怀疑是网络问题时可以参考 PingPlotter 软件页。
• 掉线之后要不跑现场就把问题处理掉，见 RustDesk 软件页。
• 展厅可用性怎么定指标、故障怎么分级响应，这套更系统的机制设计见展厅可用性 SLA 与无人值守保障。

把这套做法变成可复用的能力

上面这些做法，靠的是有经验的人记得去做。而展厅项目会换人、会有多个并行、会在两年后被回头维护——依赖个人记忆的做法迟早会漏。

企服君把状态采集、异常告警、批量操作与设备档案做成标准能力，让交付质量不取决于具体是谁在做。集成商如果想把运维从售后成本变成可以向甲方收费的服务，见集成商年费方案。

出处

本文所述的监控对象、探测方式局限、告警渠道、装机位置判断，均来自本站 Uptime Kuma 软件页、frp 软件页、RustDesk 软件页与远程运维对比页已核实的官方材料；具体一手出处链接见各页面各自的”出处”栏。文中涉及的售前报价与响应时效的取舍属于工程经验总结，具体项目请以现场实际情况为准。