设备掉线监控与告警
本文讲通用监控思路与协议选择，具体监控软件/脚本实现因环境而异，可按需选型；各设备的 SNMP 支持范围、端口、指标以厂商说明书为准。
周末上午十点，甲方在展厅接待重要客户，走到第三个展项面前，那块拼接大屏黑着。你手机没响、后台没告警，全靠客户一句”这屏怎么不亮”才知道出事了。等你赶到现场重启播控主机，五分钟过去，客户脸已经拉下来了。
这种”观众先于你发现故障”的局面，是展厅运维最丢人的场景。终端掉一台不可怕，可怕的是你不知道。这篇讲怎么给全场关键设备装一套”哨兵”——持续探测、异常告警，在观众开口之前就把问题摁下去。
掉线监控是什么，为什么必须做
说白了，掉线监控就是让一台常开的机器替你不间断盯着全场设备：“你还在吗？服务还活着吗？“设备一旦失联或指标异常，它立刻把消息推到你手机上。
为什么非做不可？展厅无人值守是常态，一个项目十几二十台终端分布在各展项里，靠人一台台巡检根本盯不过来，故障又往往发生在没人的时候。被动等观众反馈，等于把发现故障的时间拖到最坏那一刻。装了监控，你就把”救火”变成”防火”——闭馆后能看到哪台没正常关，开馆前能提前发现哪台起不来。
探测手段从粗到细分四层：ICMP（ping）看主机在不在线，TCP 端口看服务活没活，SNMP 读温度电源等底层指标，应用心跳让程序自己报”我还正常”。靠谱的监控是这几层叠着用，而不是只靠一个 ping。
前置条件
动手前先落实这几件事，能省掉后面一大半误报和排错：
- 被监控设备有固定 IP 或可解析设备名，纳入统一网络规划。IP 乱跳的设备没法长期监控，先在路由器上做 DHCP 保留绑死地址。
- 一台常开的监控主机或服务，能访问各设备所在网段。这台机器自己不能掉链子，最好放在机房或值班室里，配 UPS。
- 理清探测协议的分工：网络可达用 ICMP，端口存活用 TCP，设备指标用 SNMP，连接原理见 TCP/UDP 基础。
- 设备端把 SNMP 打开（若要采指标）。交换机、UPS、投影这类支持 SNMP 的，得先在设备菜单里启用，设好团体名，放行 161 端口，否则怎么采都读不到。
最小可用：先 ping 通一台
别一上来就搭大平台。咱们先用最土的办法，手动确认监控这条链路能跑——对一台播控主机做一次持续 ping，让你先看到”它在线”这个结果。
假设播控主机 IP 是 192.168.1.20。在监控主机上打开命令行，Windows 上执行：
ping -t 192.168.1.20
Linux/Mac 上就是 ping 192.168.1.20（默认就一直发）。你应该看到一行行滚动的回复：
来自 192.168.1.20 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.20 的回复: 字节=32 时间=1ms TTL=64
时间几毫秒、不丢包，说明这台主机网络层是通的。现在把那台主机关机，回头看命令行——它应该开始刷：
请求超时。
请求超时。
看到”请求超时”连续出现，就是掉线被探到了。这个手动过程正是后面自动监控的内核：周期性探测 + 判断超时。跑通了它，剩下就是把它自动化、加上告警。
完整步骤
手动验证过了，下面把它做成一套能长期跑的监控。
- 梳理监控清单：列出每台关键设备的 IP、端口、所属展项、重要级别，区分”挂了立刻告警”（如主展项播控）和”可延后处理”（如次要辅屏）。这张表是整套监控的地基，你应该得到一份”设备名—IP—端口—展项—级别”的表格。
- 选探测方式，按设备类型搭配：
- Ping（ICMP）：判断主机/设备是否在线，最基础的一层。
- TCP 端口探测：ping 得通但端口连不上，说明网络在、服务挂了。探测播放程序或中控服务的监听端口，比只 ping 更贴近业务真相。
- SNMP 采集：对支持 SNMP 的交换机、UPS、投影读取流量、温度、灯泡时长、电源状态，详见 SNMP 协议速查。
- 应用级心跳：让播控/中控程序定时上报”我还活着”，最能反映业务是否正常。
- 设阈值与超时：定好心跳间隔（如 30 秒）和连续失败次数（如连续 3 次才判掉线）。配好后监控界面对稳定在线的设备应显示绿色、不误报。
- 配告警通道：异常时推送到运维群/短信/邮件，注明设备、展项、时间。你应该在故意关掉一台测试设备后，几十秒内收到一条带明确定位信息的告警。
- 联动处置：收到告警先判断能不能远程拉起——WOL 唤醒 远程开机，再用 VNC 或 向日葵/ToDesk 连入处理。这一步把”监控发现”接上”远程修复”，闭环才算成型。
关键参数速查表
| 探测方式 | 用什么 | 判断依据 | 典型阈值 |
|---|---|---|---|
| ICMP Ping | ping / 监控软件 | 是否有回复 | 连续 3 次超时判掉线 |
| TCP 端口 | telnet / 探测脚本 | 端口能否建连 | 连超时 5s、连续 3 次失败 |
| SNMP | snmpget / 监控平台 | OID 值是否异常 | 温度、电源状态越界即告警 |
| 应用心跳 | 程序主动上报 | 是否按期收到心跳 | 心跳间隔 30s、缺 2 次告警 |
阈值不是抄来的，得按现场网络的实际抖动调。网络稳的场子可以收紧到连续 2 次就报，网络杂的适当放宽，核心是在”漏报”和”误报”之间找平衡。
故障排查表
监控搭起来，最常见的麻烦不是探不到，而是探得太吵或探不准。对照下表定位：
| 现象 | 可能原因 | 解决 |
|---|---|---|
| 频繁误报 | 阈值太敏感 / 现场网络抖动 | 放宽连续失败次数与超时，区分”丢一两个包”和”真掉线” |
| 能 ping 通但画面黑 | 网络在、业务挂了 | 加应用级心跳或端口探测，别只靠 ping |
| SNMP 读不到 | 团体名/版本不对 / 设备没开 SNMP / 161 被防火墙拦 | 核对 v2c 团体名或 v3 凭据，设备开启 SNMP，放行 161 |
| 告警风暴 | 交换机/上联一断，一片设备同时报 | 做依赖收敛，上联挂了只报上联 |
| 心跳一直缺失 | 程序没接心跳上报 / 上报地址错 | 检查心跳配置与监控端接收地址端口 |
| 告警收不到 | 推送通道配置错 / 机器人 webhook 失效 | 手动触发一次测试推送验证通道 |
单独说说告警风暴——这是最容易忽略的坑。一台上联交换机断了，它下面挂的十几台设备会同时探不到，你手机瞬间被几十条告警刷爆，真正的根因反而被淹没。解决办法是做依赖收敛：告诉监控”这些设备都挂在这台上联下”，上联一挂就只报上联那一条，下游全部静默。
进阶：从告警到自愈
单台探测跑顺了，还能再往上做两层。
依赖拓扑建模。 把网络层级关系喂给监控——交换机在上、设备在下，让它理解”谁依赖谁”。这样不光能收敛告警风暴，还能一眼定位根因：报的是上联，你就直奔机房，而不是在下游十几台里瞎猜。
告警联动自愈。 把”发现”和”处置”用脚本串起来：探到某台播控掉线，先自动发一次 WOL 魔术包 试着唤醒，唤醒后再探一遍，还是不行才升级成人工告警。很多”深夜掉一下、天亮自己好了”的小故障，这套自愈就能悄悄兜住。这类把监控接进无人值守的整体做法，见 展厅无人值守实操 与 远程运维方案总览。
动手清单
跟着这张单子走一遍，一套能报警的监控就立起来了：
- 整理出全场关键设备的”设备名—IP—端口—展项—级别”清单
- 给每台设备在路由器上绑定固定 IP
- 在监控主机上手动
ping -t一台，验证在线/掉线都能探到 - 按设备类型配好 ping / TCP 端口 / SNMP / 心跳四类探测
- 设好阈值与连续失败次数，观察不误报
- 配好告警通道，故意关一台测试设备，验证能收到定位清晰的告警
- 做依赖收敛，上联挂了只报上联
- 把告警接上 WOL/VNC，跑通”发现—拉起”闭环
小结
掉线监控的价值不在于探测本身多复杂，而在于它把”观众先于你发现故障”这件最丢人的事，变成了”故障还没影响观众你就处理完了”。先手动 ping 通一台建立信心，再按层次搭起四类探测，用依赖收敛和自愈脚本把它升级成能自己兜底的哨兵——一步步来，不难。
延伸阅读：SNMP 协议速查、TCP/UDP 通信基础，把监控接入无人值守闭环见 展厅无人值守实操 与 远程运维方案总览。
希望设备状态实时回传、异常自动联动场景？了解 SoftControl 展厅中控，或浏览 远程运维专题。