3、告警创建与触发：基于设备数据的告警触发、基于时间窗口的告警、基于阈值的告警配置

好，咱们进入第三章。这一章是告警系统的核心——告警怎么创建，又怎么触发。

说实话，我在早期做物联网项目时，对告警的理解就是“超了就报警”。后来被现实狠狠教育了几次，才发现告警触发远没那么简单。你想想看，设备数据抖动、网络延迟、瞬时毛刺……这些都会导致误报。所以，ThingsBoard 提供了三种经典的触发模式：基于设备数据、基于时间窗口、基于阈值。咱们一个一个拆开讲。

3.1 基于设备数据的告警触发

这是最基础、最直接的触发方式。说白了，就是设备上报一条数据，系统判断这条数据是否满足告警条件。

核心逻辑： 设备上报遥测数据 → 规则引擎中的告警规则节点接收数据 → 判断条件 → 触发或清除告警。

我在项目中遇到过这样一个场景：一个温度传感器，要求温度超过 60°C 就报警。配置起来很简单，但坑也不少。

配置示例（规则链中的告警节点）：

// 告警规则节点配置（JSON格式）
{
  "name": "高温告警",
  "type": "alarm",
  "configuration": {
    "alarmType": "HIGH_TEMPERATURE",
    "severity": "CRITICAL",
    "condition": [
      {
        "key": "temperature",
        "value": 60,
        "valueType": "NUMERIC",
        "predicateType": "GREATER",
        "predicate": ">"
      }
    ],
    "clearCondition": [
      {
        "key": "temperature",
        "value": 50,
        "valueType": "NUMERIC",
        "predicateType": "LESS",
        "predicate": "<"
      }
    ]
  }
}

嗯，这里要注意：清除条件一定要设置。我见过不少新手只配了触发条件，忘了配清除条件，结果告警一直挂着，运维人员都麻木了。

我个人习惯是：触发阈值和清除阈值之间留一个回差区间。比如触发是 60°C，清除设成 50°C。这样能避免设备在临界点反复触发、清除，造成告警风暴。

3.2 基于时间窗口的告警

这个就高级一点了。有时候设备数据瞬间超标，但马上恢复正常，这种算不算故障？

我个人认为：不算。真正的故障应该是持续一段时间异常。时间窗口就是解决这个问题的。

什么是时间窗口？ 就是在一段连续时间内，统计设备数据的行为。比如“过去 5 分钟内，温度超过 60°C 的次数大于 3 次”，才触发告警。

我的经验： 时间窗口的长度要根据业务场景来定。工业设备抖动大，窗口可以设长一点（比如 5-10 分钟）；智能家居场景，用户对延迟敏感，窗口可以短一点（比如 1-2 分钟）。

配置示例（规则链中的时间窗口节点 + 告警节点）：

// 第一步：使用 "Time-based" 节点统计窗口内的数据
{
  "name": "5分钟温度统计",
  "type": "timebased",
  "configuration": {
    "timeRange": 300000,  // 5分钟，单位毫秒
    "aggregation": "COUNT",
    "condition": [
      {
        "key": "temperature",
        "value": 60,
        "predicateType": "GREATER"
      }
    ],
    "output": {
      "count": "high_temp_count"
    }
  }
}

// 第二步：判断统计结果是否触发告警
{
  "name": "高频高温告警",
  "type": "alarm",
  "configuration": {
    "alarmType": "FREQUENT_HIGH_TEMP",
    "condition": [
      {
        "key": "high_temp_count",
        "value": 3,
        "predicateType": "GREATER_OR_EQUAL"
      }
    ]
  }
}

为什么会这样设计？因为单次超标可能是传感器误报，但 5 分钟内超标 3 次，基本可以确定是真实故障了。我曾经在一个冷链物流项目里，就是因为没加时间窗口，导致冷藏车过减速带时的震动被误报成温度异常，一天几百条告警……后来加上 3 分钟窗口，告警量直接降了 90%。

3.3 基于阈值的告警配置

阈值告警是最常见的，但配置起来也有讲究。ThingsBoard 支持多种阈值类型：

阈值类型 说明 适用场景
固定阈值 一个固定的数值，比如温度 > 60 大多数简单场景
动态阈值 阈值来自另一个设备属性或遥测 多设备联动、自适应场景
变化率阈值 数据变化的速度，比如温度每秒上升 > 5°C 设备故障预判、趋势异常
复合阈值 多个条件组合，比如温度 > 60 且 湿度 < 30 复杂业务逻辑

固定阈值配置示例：

{
  "alarmType": "HIGH_HUMIDITY",
  "severity": "WARNING",
  "condition": [
    {
      "key": "humidity",
      "value": 85,
      "predicateType": "GREATER"
    }
  ]
}

动态阈值配置示例：

有时候阈值不是固定的。比如一个空调设备，它的目标温度是动态设置的。告警阈值应该跟着目标温度走。

{
  "alarmType": "TEMP_DEVIATION",
  "condition": [
    {
      "key": "temperature",
      "value": "${target_temperature} + 5",
      "predicateType": "GREATER",
      "dynamicValue": {
        "sourceAttribute": "target_temperature",
        "sourceType": "CURRENT_DEVICE"
      }
    }
  ]
}

避坑指南： 我曾经在配置动态阈值时，忘了检查动态值的来源是否存在。结果设备没有上报 target_temperature 属性，告警规则直接报错，所有告警都失效了。所以，使用动态阈值前，一定要确保源属性或遥测数据存在，或者加一个默认值兜底。

变化率阈值配置示例：

这个比较高级。比如监测电机振动，正常振动是缓慢变化的。如果振动值在 1 秒内从 10 跳到 50，说明可能发生了碰撞或断裂。

{
  "alarmType": "VIBRATION_SPIKE",
  "condition": [
    {
      "key": "vibration",
      "predicateType": "RATE_OF_CHANGE",
      "value": 20,  // 每秒变化超过20
      "timeUnit": "SECONDS"
    }
  ]
}

3.4 三种触发方式的组合使用

在实际项目中，这三种方式往往不是孤立的。我常用的组合策略是：

  1. 先做数据清洗：用时间窗口过滤掉毛刺数据
  2. 再判断阈值：用固定或动态阈值判断是否超标
  3. 最后触发告警：生成告警并通知

举个例子，一个水压监测系统：

  • 设备每 10 秒上报一次水压
  • 规则链中先经过一个 时间窗口节点，统计 1 分钟内的平均水压
  • 然后判断平均水压是否 低于 0.2 MPa（固定阈值）
  • 如果低于，再判断是否 持续低于 30 秒（时间窗口）
  • 满足所有条件，触发 低压告警

这样配置下来，误报率极低。我记得有一次客户说他们的水压告警太灵敏，我一看配置，就是少了时间窗口过滤。加上之后，客户反馈说“终于安静了”。

3.5 小结与建议

这一章的内容其实就三个核心点：

  • 基于设备数据：单条数据触发，简单直接，但容易误报
  • 基于时间窗口：统计一段时间内的数据行为，过滤毛刺，更可靠
  • 基于阈值：固定、动态、变化率、复合，灵活应对各种场景

我个人建议：能用时间窗口就用时间窗口。虽然配置稍微复杂一点，但能省去后期大量的误报排查时间。你想想看，运维人员每天被几百条假告警轰炸，真正出问题的时候反而没人看了——这就是“狼来了”效应。

下一章，我们会讲告警的传播与通知，包括邮件、短信、钉钉这些怎么配。到时候我会分享一个我踩过的坑：告警通知频率控制没做好，半夜把客户老板吵醒了……嗯，那场面，你懂的。

← 上一章 📖 返回目录 下一章 →