设备告警触发后如何恢复？讲清自动恢复、手动解除与设备告警状态

物联网设备的属性值超过阈值，或者告警规则指定的设备属性值长时间没有更新时，ThingsCloud 可以通过告警规则识别异常，让对应规则进入告警状态。异常处理完成后，这条规则还需要恢复为正常，平台才能准确记录本次告警已经结束。

理解设备告警恢复，应该先从一条具体的告警规则开始：规则如何进入告警状态，触发后怎样自动恢复，哪些情况需要人工手动解除。最后再看一台设备关联多条规则时，平台如何自动计算设备的总告警状态。

告警规则如何进入告警状态

ThingsCloud 告警规则可以将 设备属性变化 或 设备不活跃 作为触发类型。前者在设备属性值发生变化时触发检查；后者需要在触发条件中指定具体的受监测属性，当该属性的最后更新时间超过设定时长后触发检查。每台设备在每一条告警规则下都有独立的当前状态：

• 正常（Ok）：最近一次检查没有触发告警条件。
• 待定（Pending）：告警条件已经触发，但尚未达到设置的重复次数或持续时间。
• 告警（Alerting）：告警条件已经触发，并且达到已设置的重复次数和持续时间要求。
• 未知（Unknown）：规则暂时没有明确状态，例如规则创建后一直没有相关设备属性值上报。

对于 设备属性变化 类型，如果没有设置重复次数和持续时间，设备属性值变化并首次满足触发条件时，规则就会进入告警状态。如果设置了重复次数或持续时间，规则会先进入待定状态，连续触发达到要求后才进入告警状态；两者同时设置时，必须同时满足。

例如，温度大于 29℃ 触发告警：不设置防抖条件时，首次上报 29.4℃ 即可触发；如果设置连续重复 3 次，则需要后续数据连续满足条件；如果设置持续 10 分钟，则条件需要连续保持到设定时间。

规则进入告警状态后，平台会记录一条告警消息。如果规则已经关联告警通知组或启用用户通知，还会按照相应设置发送告警通知。此时需要恢复的是这台设备下的这条告警规则，而不是直接修改设备的总告警状态。

告警规则进入告警状态后，如何恢复

告警规则进入告警状态后，可以通过自动恢复或手动解除告警回到正常状态。通常应优先使用告警规则的自动恢复机制；只有当设备的属性值无法反映异常是否已经消失，或者现场必须由人员确认时，再使用手动解除。

自动恢复：下一次检查确认告警条件已经不成立

告警规则不需要另外设置一套恢复条件。对于 设备属性变化 类型，规则进入告警状态后，下一次相关属性值发生变化并触发告警检查时，平台会检查设备的当前属性值。如果当前属性值不再满足原来的触发条件，这条规则就会自动恢复为正常。

以下是几种常见的自动恢复情况：

• 数值恢复正常：温度大于等于 30℃ 时触发告警，设备先上报 32℃，后续上报 28℃，因为新的温度值不再满足触发条件，规则自动恢复。
• 故障标志复位：设备上报的故障属性值为开启并触发告警，故障排除后再次上报为关闭，规则在重新检查后自动恢复。
• 指定属性恢复上报：例如，设备不活跃规则监测的是电压属性，该属性长时间没有更新并触发告警后，只有设备再次上报电压属性值，规则才会自动恢复。设备上报其他属性值不会使这条规则恢复。

这里需要特别注意：设备不活跃 并不是判断设备的任意属性是否更新，而是判断告警触发条件中所选属性的最后更新时间。自动恢复同样以这个具体属性重新上报、恢复更新为依据。

告警恢复时，平台会记录一条告警恢复消息；如果告警规则配置了恢复通知，还会向相应人员发送通知。这样，一次规则告警就形成了“触发—处置—恢复”的完整状态记录。

为什么有时没有自动恢复

自动恢复需要再次触发相应的告警检查：设备属性变化类型需要相关属性值再次变化；设备不活跃类型需要规则所监测的具体属性重新上报、恢复更新。现场问题虽然已经解决，但出现以下情况时，平台可能还没有足够依据把规则恢复为正常：

• 相关属性值没有再次变化：设备属性变化规则没有重新触发检查，平台也就无法判断告警条件是否仍然成立。
• 不活跃规则所选属性仍未更新：即使设备上报了其他属性值，只要规则所监测的具体属性没有恢复更新，这条不活跃告警就不会自动恢复。
• 属性值无法反映处理结果：摄像头识别到可疑入侵、人工处理断路器故障等场景，现场风险是否排除可能无法仅靠后续属性值自动确认。
• 告警规则已经被禁用：规则被禁用后不会继续触发检查，原来的规则状态会保持不变。
• 当前处于规则无效时段：如果希望规则在无效时段也能恢复，需要在告警规则有效时段设置中开启“无效时段允许告警恢复”。

排查时应先确认相关属性值是否再次变化、规则是否可用，以及当前时段是否允许恢复。如果设备能够在异常消失后及时更新相关属性值，仍应优先使用告警规则的自动恢复机制，避免把本可自动闭环的告警变成人工操作。

手动解除告警：由人员确认异常已经处理

当设备无法自动恢复，或者故障是否排除必须由人员判断时，可以在规则的告警解除设置中开启允许解除告警。如需让设备所属用户执行该操作，还可以按需开启 允许用户解除告警。常见场景包括：

• 传感器发生误报，人员到现场排查后确认没有真实风险。
• 断路器异常分闸或设备发生故障，维修人员已经完成处理和手动复位，但设备无法上报能够表明故障已经排除的属性值。
• 摄像头识别到可疑入侵，后续是否安全需要人员查看现场后确认。

手动解除表示人员已经确认本次规则告警可以结束，但不能代替真实的现场处置。如果设备后续再次上报相关属性值，并且仍然满足告警条件，这条规则仍可能再次进入告警状态。

自动恢复和手动解除的区别可以概括为：

一个设备关联多条告警规则时，总告警状态如何恢复

一台物联网设备可以关联多条告警规则，例如温度过高、压缩机故障和设备不活跃。每条规则独立触发和恢复，设备本身还会根据这些规则计算一个总告警状态。

设备总告警状态不是另一条需要单独解除的规则。ThingsCloud 会根据设备下所有告警规则的状态自动汇总；当一条或多条规则处于告警状态时，设备总状态取其中最严重的告警级别：

• 无告警
• 普通告警
• 重要告警
• 紧急告警

例如，一台冷库设备当前有以下 3 条规则：

因为“压缩机故障”是紧急告警，所以设备总状态显示为 紧急告警。维修人员手动解除了这条规则后，“温度过高”仍处于告警状态，设备总状态会自动变为 重要告警，而不是直接变成无告警。等温度恢复、对应规则自动恢复正常后，设备下所有规则都已正常，设备总状态才会自动变为 无告警。

因此，设备总告警状态的恢复过程不需要单独操作：

1. 找到设备下仍处于告警状态的具体规则。
2. 对于能够由属性值判断的规则，确认相关属性值已经更新并触发检查，让规则自动恢复。
3. 对确实无法自动恢复的规则进行人工确认和手动解除。
4. 当导致告警的规则都恢复正常、不再有规则处于告警状态后，平台自动把设备总状态更新为无告警。

如果处理完一条规则后，设备列表仍然显示告警，应继续检查同一设备下是否还有其他普通、重要或紧急告警，而不是重复解除已经恢复的规则。

配置和排查建议

为了让物联网设备告警恢复更稳定，建议在项目上线前检查以下事项：

1. 为每条规则明确触发条件、告警级别、重复次数和持续时间。
2. 确认设备在异常消失后会及时更新相关属性值；对于设备不活跃告警，确保设备重新上报规则所监测的具体属性值。
3. 按业务时段配置告警规则，并确认是否需要在无效时段允许恢复。
4. 只为确实需要人工判断的规则开启手动解除权限。
5. 明确手动解除告警的适用条件、操作权限和处理流程。
6. 排查设备总告警状态时，逐条检查设备关联的所有告警规则。

总结

设备告警恢复应该按照清晰的层级理解：先由一条告警规则根据设备属性值变化或设备不活跃进入告警状态；对于属性变化规则，相关属性值不再满足触发条件并触发检查时自动恢复；对于设备不活跃规则，设备重新上报规则所监测的具体属性值时自动恢复；告警是否解除无法由设备上报判断或需要人员确认时，再手动解除告警。

当一台设备关联多条告警规则时，不需要直接恢复设备的总告警状态。平台会根据每条规则的状态和告警级别自动计算总状态。只要所有告警规则都恢复正常，设备的告警状态也会自动恢复为无告警。

继续了解 ThingsCloud 告警功能：

• 告警通知功能概览
• 告警规则
• 告警状态
• 告警消息
• 告警通知组
• 用户告警通知
• 告警通知 Webhook
• 告警语音通知
• 告警通知配额
• 更多第三方告警通知