设备在线监控：怎么第一时间知道哪台挂了

一个真实的运维困境

展厅交付三个月，二十台设备。运维小李每天早上的工作是：挨个连远程桌面，看看画面在不在、软件跑没跑。连一台十几秒，二十台连完加上处理零星问题，半小时过去了。

这活儿的问题不在于累，在于它不可持续。设备涨到五十台就彻底盯不过来，而且人总有请假的时候。更要命的是，这种巡检只覆盖早上那一次——白天某台十点钟崩了，得等客户打电话来才知道。

监控要解决的核心问题是：把"客户告诉你出事了"变成"你先知道"。 这一节讲怎么设计这套机制。

判死活的三个层次

"这台设备还活着吗"这句话，其实有三种不同深度的答案。它们的实现成本递增，能发现的问题也递增。

第一层：网络层——ping 得通吗。

最简单，一条命令的事。能发现断电、断网、死机这类硬故障。

但它的盲区很大：机器活着不等于业务正常。主机好好开着、网络也通，播放软件却崩了、屏幕一片黑——ping 照样通，监控显示一切正常。只做这一层，等于只监控了"电源和网线"。

第二层：进程层——该跑的程序在跑吗。

进一步查关键进程是否存在。能抓到"软件崩了"这个展厅最高频的故障。

盲区是进程在不等于干活。程序卡死（无响应白屏）时进程还在，播放早就停了；或者程序在跑但读不到片源，界面停在错误提示上。

第三层：业务层——它真的在正常播吗。

最准，也最难做。判断依据可以是"播放进度在推进""日志在持续写入""最后一次上报的当前节目名是对的"。

这一层往往需要被监控的软件自己配合上报状态。如果软件不支持，退而求其次可以看间接指标——比如日志文件的修改时间是否在几分钟内。

现场怎么选？ 我的建议是：第二层是性价比最高的起点，第一层作为兜底，第三层对关键展项再单独做。 全场二十台都做第三层，投入产出不划算；但迎宾大屏、主展项这几台核心设备值得。

主动心跳还是被动轮询

知道了要看什么，接下来是"谁去看"。两种机制，区别在方向。

被动轮询是监控端主动去问：每隔一分钟 ping 一遍所有设备、或者逐台发查询指令。

主动心跳是设备自己定期报：每隔十秒往监控端发一个状态包，说"我还活着，音量 30，播放中"。

	被动轮询	主动心跳
被控端要求	无需改造	需要能上报的代理或软件
发现延迟	取决于轮询周期	取决于心跳间隔，通常更快
网络流量	设备多时集中爆发	分散，单包极小
能带的信息	只有"通不通"	可以带一整份状态快照
跨网段	需要能路由到每台设备	设备往固定地址发，穿透更容易

心跳的优势在于信息量。 轮询只能告诉你"通"，心跳可以顺带把音量、守护状态、当前播放内容、磁盘剩余空间一起报上来。这些信息在排障时价值极大——设备还没挂，但你能提前看到磁盘要满了。

实际做法通常是两者结合：心跳为主，对不支持心跳的老设备（投影机、矩阵之类）用轮询补上。前面远程管控实战那一节配的心跳上报，就是这一层的落地。

容忍窗口：别丢一次就报警

这是新手最容易配错的参数，也是告警系统被弃用的头号原因。

心跳走 UDP 的居多，UDP 本身不保证送达。网络抖一下、交换机忙一下、被控机 CPU 满载一秒，都可能丢一个包。如果你配成"没收到心跳就告警"，那么一晚上能收到几十条误报，第二天所有人都学会了无视告警——监控系统就此死亡。

正确做法是设容忍窗口：连续 N 个周期没收到才判离线。

经验值：N 取 3 起步。心跳间隔 10 秒的话，容忍窗口就是 30 秒——设备真挂了，你半分钟内知道；偶发丢包，静悄悄地过去了。

对稳定性要求不同的设备可以给不同的窗口。核心展项收紧到 2 个周期，边缘设备放宽到 5 个。别一刀切。

同理，恢复也要有确认：连续收到 2 次心跳才判定恢复，避免设备在临界状态时反复"离线-在线"刷屏。

告警设计：让人愿意看

告警的目标不是"发出去"，是"被处理"。这两件事差得很远。

分级。 至少分两档：

• 需要立刻处理——开馆时间内核心展项离线。发到手机、打电话都不为过；
• 知道就行——闭馆后某台离线（很可能就是正常关机了）、磁盘用到 80%。汇总进日报即可。

不分级的后果是：紧急的和不紧急的混在一起，接收者很快就会把整个通道静音。

抑制。 三种情况必须抑制：

1. 闭馆时段。每天 17:40 全场关机，如果不设静默期，每晚都会收到二十条"设备离线"。这是最经典的告警疲劳来源。
2. 重复告警。同一台设备持续离线，第一条告警之后不要每分钟重发一次，改成"状态未变则不再打扰"，恢复时再发一条。
3. 上游故障。交换机挂了导致挂在它下面的十五台全部离线——应该报"交换机故障"一条，而不是十五条设备离线。做法是给设备标注上游依赖，上游挂了就抑制下游告警。

第三条稍微复杂，小场子可以先不做；但一旦设备过了二三十台，不做这个，一次网络故障就能刷屏一百条。

告警要带上下文。 一条只写"设备离线"的告警，接收者还得去查这是哪台、在哪个展厅、平时归谁管。直接把这些写进告警文本里，处理速度能快一倍。

最小可用：先别急着搭平台

看到这里你可能觉得要上一套监控系统。先别。 二十台以内，一张表加一个脚本就能跑起来。

做法很简单：设备心跳统一往一个地址上报，接收脚本记下每台的最后上报时间，然后定期检查"谁超过容忍窗口没露面"，超了就发通知。

一个概念性的骨架长这样：

# 内存里记录每台设备的最后心跳时间
$lastSeen = @{}
$TIMEOUT  = 30      # 容忍窗口（秒）

# 收到心跳时更新（实际接收循环见远程管控实战那一节）
# $lastSeen[$agentId] = Get-Date

# 每 10 秒检查一次谁掉线了
while ($true) {
    $now = Get-Date
    foreach ($id in $lastSeen.Keys) {
        $gap = ($now - $lastSeen[$id]).TotalSeconds
        if ($gap -gt $TIMEOUT) {
            Write-Host "[告警] $id 已 $([int]$gap) 秒无心跳"
        }
    }
    Start-Sleep -Seconds 10
}

这个东西二十行不到，却能覆盖八成的监控需求。先用它跑三个月，你会清楚地知道自己真正需要什么——是要历史曲线？要多人协作？要工单流转？带着真实需求再去选平台，比一上来就搭一套大而全的东西靠谱得多。

真要往平台走时，架构、采集方式、数据存储这些，展厅设备集中监控平台搭建那篇讲得更细。

几个常见误区

只监控设备，不监控业务。 所有设备都在线，但播的是上个月的旧内容——监控一片绿，客户很生气。关键展项要有内容层面的核对。

监控系统自己没人管。 接收脚本挂在某台机器上，某天那台机器重启了，脚本没自启，监控静默失效两周没人发现。监控系统本身也需要被监控——最土也最有效的办法是让它每天定时发一条"我还活着"的日报，哪天没收到就说明它挂了。

只在开馆时间监控。 闭馆后的异常同样重要：定时关机没执行、UPS 报警、机房温度异常。这些不用即时告警，但要记录，第二天看日报能发现。

告警发给了不负责的人。 告警要落到具体的人和具体的动作。发到一个几十人的大群里，结果就是所有人都以为别人会处理。

小结

监控这件事的本质是把不确定变成确定：不用猜设备好不好，看一眼就知道。

落地的顺序建议是：先做进程层判活 → 配心跳和容忍窗口 → 用最简脚本跑起来 → 攒够真实需求再上平台。别倒过来，先买平台再想需求，大概率买到一堆用不上的功能。

设备状态能看见之后，下一个问题自然是"看见了故障能不能自动处理掉"——那是故障自愈设计那一节的事。而设备一多，台账和配置也得管起来，见设备资产台账与配置管理。