当温度、电压、转速、振动等设备数据持续写入 Apache IoTDB，下一步往往是：如何在异常发生时第一时间发现，并把准确的设备、产线和现场信息送到值班人员手中？
自夜莺 v9 发布起，Apache IoTDB 已正式成为其告警数据源之一。用户可以直接使用 IoTDB SQL 查询设备数据，由夜莺完成告警判定、事件生成与通知响应。
为什么工业时序数据需要“数据库 + 告警引擎”？
对工业数据而言，“存下来、查得到”只是第一步。真正进入生产现场之后，数据还需要持续参与状态监测、异常识别和运维响应。温度是否越限、设备是否异常、某条产线是否出现风险，都要求数据能够及时转化为可感知、可通知、可追踪的事件。
工业场景下的设备数据天然具有高频、多源、带标签的特点：一条时序记录往往包含温度、压力、转速等多个测点，同时携带设备编号、产线、工厂等上下文信息。在许多以 Prometheus 为核心的监控体系中，如果希望对 IoTDB 中的工业数据进行告警，往往需要增加一层数据转换或同步，将设备数据重新映射为指标和标签。对于已经在 IoTDB 中完成数据建模的用户而言，这意味着额外的数据链路和维护成本。
夜莺 v9 选择直接对接 IoTDB 的原生数据模型，让用户以最自然的 SQL 方式查询设备数据，并复用夜莺成熟的告警引擎完成周期性判定、事件生成、屏蔽、订阅和通知。由此，从 IoTDB 中的数据，到现场告警与运维响应，中间不再需要额外的数据搬运层。
这一能力也来自 Apache IoTDB 与夜莺两个开源社区的持续协作，相关功能通过多个前后端 PR 逐步完善，并在夜莺 v9 中正式面向用户提供。
从一条 SQL 到设备级告警，IoTDB 数据如何进入夜莺？
01直接查询 IoTDB，数据不搬家
夜莺通过 IoTDB Table Model REST API 查询设备数据。用户不需要把数据转换为 Prometheus 指标，也不要求改写成 PromQL，只需编写自己熟悉的 IoTDB SQL，例如：
SELECT time, temperature, plant, line, device
FROM factory.device_metrics对于已有 IoTDB 数据的工厂、园区和能源系统，这意味着原有数据模型和存储架构无需改变，即可直接增加告警能力。
02自动补全告警时间窗口
告警规则通常需要回看一段时间内的最新数据。用户只需要关注要查询的字段，夜莺会根据规则中的“时间间隔”自动补充时间条件。
例如，告警回看区间设置为 1 分钟时，夜莺会将查询补全为：
SELECT time, temperature, device
FROM factory.device_metrics
WHERE time >= 1784300000000
AND time <= 1784300060000如果用户编写的 SQL 已经包含 WHERE time 条件，则以用户编写条件为准；自动生成的条件会被插入到 GROUP BY、HAVING、ORDER BY、LIMIT 等子句之前，确保语义正确，方便用户继续使用聚合和排序逻辑。
03浏览 IoTDB 元信息，辅助完成字段配置
在数据源配置和告警规则编辑过程中，夜莺可以按“数据库 → 表 → 字段”浏览 IoTDB 元信息。选择数值型字段后，系统可辅助生成 SQL，并回填值字段和时间字段，极大降低查询及字段映射的配置成本。
这对字段数量较多、设备型号较复杂的工业场景尤其有帮助：配置人员可以先从元信息树定位目标字段，再完成查询和告警规则配置，减少手动查找字段和反复确认数据结构的工作，让告警配置从“猜字段”变成“点选即用”。
04一条 SQL，完成多设备分组告警
工业告警很少只关注一个孤立的数值，更重要的是判断：哪一家工厂、哪一条产线、哪一台设备出现了异常。
在夜莺中，IoTDB 查询返回的温度、电压、转速等数值列可以映射为 Field 字段，设备号、产线、工厂、区域等上下文信息则可以映射为 Tag 字段。每个“Field 字段 + Tag 组合”都会形成一条独立时序，分别进行告警判定。
例如：
SELECT time, temperature, plant, line, device
FROM factory.device_metrics这条 SQL 可以一次返回多台设备的温度数据。夜莺会按照 plant + line + device 的不同组合，将查询结果拆分为多条独立时序并分别进行告警判断。
因此，一条 SQL 可以覆盖一批设备，而每台设备仍然拥有独立的告警状态。
当其中一台设备温度超过阈值时，系统只会生成对应设备的告警事件，并保留其工厂、产线和设备等上下文信息，方便值班人员快速定位发生异常的具体设备及其所在现场。
05直接查询 IoTDB，数据不搬家
完成设备数据查询和分组之后，后续的告警能力可以直接复用夜莺现有体系。
其中，IoTDB 负责设备时序数据的持续写入、存储和查询，夜莺负责周期查询、阈值判定、事件生成、屏蔽、订阅、Pipeline 和通知，形成从设备数据到运维响应的闭环。
由此可以形成一条完整链路：
设备 / 传感器 → Apache IoTDB → SQL 查询 → 时序分组 → 阈值判定 → 告警事件 → Pipeline / 通知
从设备产生数据，到异常被识别，再到准确的设备、产线和现场信息送达值班人员，整个过程无需再增加额外的数据同步层。
演示案例：设备温度超温告警
场景：某工厂设备温度超过 80℃ 时触发告警。
SQL
SELECT time, temperature, plant, line, device
FROM factory.device_metrics值字段：temperature
标签字段：plant、line、device
时间字段：time
回看区间：1 分钟
告警条件：$A > 80
执行频率：例如每 30 秒一次
同一条 SQL 可以一次返回多台设备的数据。夜莺会根据 plant、line 和 device 标签拆分时序并逐台判定：当其中一台设备超温时，系统只生成对应设备的告警事件，并保留其工厂、产线和设备信息，不会与其他设备的告警状态混淆。
接入准备与注意事项
若您计划在夜莺 v9 中接入 IoTDB，请注意以下几点：
👉 IoTDB REST 服务需手动开启：配置 enable_rest_service=true，默认端口 18080，使用 Basic Authentication。详细参考 IoTDB REST API 文档。
👉 当前接入走表模型：路径为 /rest/table/v1/query，暂不支持树模型的直接告警查询（树模型数据可考虑通过视图映射）。
👉 正式告警 SQL 建议显式选择值字段和标签字段，避免在生产环境长期使用 SELECT *。
👉 时间字段默认是 time；返回秒、毫秒、微秒或纳秒时间戳时，夜莺会统一归一化后参与判定。
👉 查询中不建议使用宏（如 $__timeFilter），直接使用告警规则的“时间间隔”即可。
注：如同时从夜莺旧版本升级至 v9，请参考夜莺官方升级说明确认相关环境依赖。
从数据底座到告警响应
Apache IoTDB 擅长承载设备时序数据，夜莺擅长把数据变化转化为可管理、可通知、可追踪的运维事件。两者的集成，让工业数据告警不再需要额外的数据同步层，也让 IoTDB 用户可以直接复用夜莺成熟的告警与通知能力。
对于正在建设工业物联网、设备运维和能源管理平台的团队而言，接入夜莺 v9 后，可以沿用现有 IoTDB 数据模型，从一条 SQL 开始，逐步建立面向设备、产线和区域的统一告警体系。
未来，双方社区将继续探索更深入的合作，让数据留在最合适的地方，让告警能力以更低成本触达真实业务现场。
