定义
Event Stream（事件流）展示设备上报的告警、故障等离散事件，支持按时间线展示与筛选，可关联设备详情与 Work Order。与 Telemetry 连续型数据互补。
事件类型与处理
事件流涵盖设备告警、状态变更、OTA 进度、配置变更、安全事件等。事件通常包含时间戳、设备 ID、事件类型、级别、描述、关联数据等。设备管理平台从 MQTT、规则引擎、系统内部等采集事件，经去重、聚合后写入事件存储。支持按设备、产品、时间、级别筛选；支持实时推送与历史查询。事件可触发告警通知、Work Order 工单创建、下游系统 Webhook 等联动。
与 DMP 的集成
平台在 Device Monitoring 设备监控、NOC 大屏、Fault Diagnosis 故障诊断等场景展示事件流。事件可关联设备详情、遥测历史、Log Collection 日志，形成完整的故障上下文。与 Report Analytics 报表分析对接，可统计告警趋势、MTTR 等运维指标。事件数据可导出供审计与合规分析。
应用场景
适用于运维人员实时监控设备态势、故障回溯分析、告警驱动工单、运维 KPI 统计等。事件流是设备管理平台从「数据」到「行动」的关键桥梁。
一条事件和一串采样点
事件流保存的是已经发生、并且值得被单独记住的事实：越限开始、越限恢复、认证失败、升级进入某一步、配置被改写。它和连续采样的差别在于，采样按周期或按变化不断到来，事件则在条件成立的那一刻记一笔，并带上类型、级别和关联对象。一条事件应当能回答哪台设备、在何时、发生了什么、是否需要人处理。若把每一次温度上报都写成事件，流会被采样点淹没，值班的人无法从中找到真正的状态变化。反过来，只留采样、不留事件，则告警何时触发、何时确认、何时关闭没有独立记录，事后只能从曲线上猜测。时序库适合放采样，事件存储适合放可筛选的离散记录，两者用设备标识和时间对齐，而不是互相替代。
值得单独落库的变化
适合进入事件流的，是会被检索、被关联工单或被审计的变化。级别要事先划分，避免所有记录都是同一级，筛选失去意义。去重窗口也要事先定义：同一设备、同一告警码在窗口内重复上报，应更新次数或最后发生时间，而不是无限追加新行。事件时间应以设备产生时间为准，同时保留平台接收时间，两者差得过大时要能被看出来。需要通知外部系统时，再用回调投递；回调失败应可重试，且不改变“事件本身已经入库”这一事实。纯调试输出、高频波形不适合直接进事件流，它们体积大、语义弱，应走日志或采样通道。没有稳定设备标识的报文，也不应先写入事件流再指望以后补齐。
时钟漂移和重复投递
设备时钟漂移时，事件会排到未来或排到几天之前，按时间线筛选会像数据丢失。只信平台接收时间，则离线补报的事件会挤在恢复联网的那一秒，故障过程被压扁。重复投递若没有事件标识，同一条告警会打开多张工单；有标识但不做幂等，重试仍会插入新行。级别在边缘侧和平台侧各定义一套，筛选“严重”时会漏掉或误含。把升级进度、配置变更和安全告警混在同一默认视图里，又不提供类型过滤，需要确认的条目会被噪声盖住。事件一旦被下游当成已处理，原始记录仍应保留，不能因为工单关闭就把发生事实删掉。归档应按设备与类型建索引，只做全文搜索会在故障当天把无关调试记录一起捞出。跨日查询要固定时区，否则同一条越限对不上当时的采样。级别一旦入库就不应被事后改写，否则无法知道当时为何把它当成需要处理的事件。导出给外部系统时应带上事件标识，方便对方去重。