1. 项目概述与核心价值在数据中心IDC的日常运维中我们常常面临一个两难困境一方面我们需要对机房环境、服务器健康状态、能耗等海量指标进行实时、精准的监控任何一个环节的疏忽都可能导致服务中断或硬件损坏造成巨大损失另一方面传统的集中式监控架构将所有数据汇聚到中心平台处理随着设备数量的指数级增长网络带宽压力剧增数据处理延迟也变得越来越不可接受预警的实时性大打折扣。这就像在一个庞大的工厂里每个车间的传感器数据都要先送到总部的控制室分析等指令再传回来时可能局部过热的问题已经发生了。边缘计算的出现为这个困境提供了一个优雅的解决方案。它的核心思想很简单把计算能力下沉到数据产生的地方。不再把所有原始数据都千里迢迢地传回云端而是在网络边缘、靠近设备侧就完成初步的过滤、聚合和分析只将关键结果或异常信息上报。这极大地减轻了网络负担并实现了毫秒级的本地响应。我这次分享的“基于边缘计算的IDC智能运维监控平台”就是这一理念在数据中心运维场景下的一个完整工程实践。我们构建了一个分布式监控体系利用无线传感器网络WSN采集环境数据通过IPMI接口获取服务器硬件状态并在机柜旁部署边缘服务器我们用的是树莓派进行实时处理与预警。这个平台不仅实现了对环境温湿度、烟雾、光照、非法入侵以及服务器CPU、内存、功耗等指标的全面监控更重要的是它通过边缘侧的智能处理让预警从“事后通知”变成了“事中干预”真正为数据中心的稳定、高效、绿色运行提供了保障。无论你是运维工程师、物联网开发者还是对分布式系统架构感兴趣的朋友相信这个从硬件选型、网络搭建到软件实现的完整案例都能给你带来不少启发。2. 平台整体架构与设计思路拆解设计一个系统尤其是涉及硬件、网络和软件协同的复杂系统第一步永远是顶层架构设计。我们的目标很明确构建一个低延迟、高可靠、易扩展的IDC监控平台。传统的“传感器-中心服务器”两层架构显然无法满足要求因此我们引入了边缘计算层形成了“感知层-边缘层-汇聚层”的三层架构。2.1 三层架构解析各司其职协同工作感知层这是系统的“神经末梢”负责采集原始数据。主要包括两类节点环境传感器节点由Arduino主板搭配各类传感器如DHT11温湿度、MQ2烟雾、红外对射、光敏电阻和ZigBee无线模块构成部署在机房的各个关键位置如机柜间冷热通道、空调回风口、消防重点区域等。它们负责采集物理环境数据。服务器管理接口通过服务器的IPMI智能平台管理接口带外管理通道直接读取CPU温度、风扇转速、电源功耗等硬件健康信息。这是一种标准化的、独立于操作系统的高可靠性数据采集方式。边缘层这是系统的“区域大脑”是边缘计算理念的核心体现。我们在每个机柜群或一个物理区域称为一个“网格”部署一台边缘服务器如树莓派。它的核心职责包括数据汇聚接收本区域内所有ZigBee传感器节点上传的数据。协议解析与预处理对原始字节流进行解析、校验、格式化并过滤掉无效或异常数据。本地分析与告警在边缘侧实时计算指标如5分钟平均温度、比对预设阈值。一旦发现异常如温度持续超过28℃立即在本地触发声光报警并可通过短信网关直接通知值班人员实现秒级响应无需等待中心平台判断。数据聚合与上报将清洗、聚合后的有效数据如每分钟的均值、最大值上传至中心的汇聚服务器极大减少了上行数据量。汇聚层这是系统的“指挥中心”通常位于数据中心的核心网络区域。它接收来自所有边缘服务器的聚合数据进行全机房范围的全局分析、数据持久化存储、历史趋势展示并运行更复杂的算法模型如基于深度学习的能耗预测、故障根因分析。同时它提供统一的Web监控门户给运维人员。注意这个架构的关键优势在于“去中心化”和“责任下沉”。边缘层处理了80%以上的常规、高频率的监控逻辑让汇聚层可以专注于全局策略和深度分析系统整体的健壮性和可扩展性得到了质的提升。即使汇聚层网络暂时中断各个边缘单元也能独立工作保障本区域的基本监控功能。2.2 关键技术选型背后的考量在技术选型上每一个决定都围绕着稳定性、低功耗、易开发和成本这四个核心维度。1. 无线传感网络协议为什么是ZigBee无线传感网络WSN的协议选择很多比如Wi-Fi、蓝牙、LoRa。在机房环境监控这个特定场景下我们最终选择了ZigBee主要基于以下几点低功耗传感器节点通常由电池或能量采集装置供电ZigBee在休眠模式下功耗极低一节电池可工作数月甚至数年非常适合长期部署。自组织网络ZigBee支持Mesh网状网络节点可以自动组网、多跳路由。这意味着某个节点故障或信号被遮挡时数据可以通过其他节点中继网络鲁棒性很强非常适合机房内复杂、多障碍物的环境。适中的速率与距离250kbps的速率足以传输温湿度等小数据包室内几十米的传输距离也完全覆盖机柜区域。相比LoRa它的延迟更低相比Wi-Fi它的功耗和组网复杂度更优。成本与生态ZigBee模块如Digi的XBee成本可控且与Arduino等开源硬件平台集成度很高开发资源丰富。2. 边缘服务器硬件为什么是树莓派边缘服务器需要一定的计算能力来运行数据接收、处理和告警逻辑同时要求体积小、功耗低、接口丰富、稳定性好。树莓派几乎是这个场景下的“标准答案”性价比与生态极低的成本提供了完整的Linux计算环境丰富的GPIO、USB、网络接口便于连接各种硬件。低功耗通常功耗在3-5W无需特殊散热可以轻松部署在机柜内。稳定性作为成熟的嵌入式平台其系统稳定性经过大量工业场景验证。我们通过配置看门狗、日志循环、只读文件系统等手段进一步增强了其在7x24小时运行环境下的可靠性。3. 数据采集端为什么是Arduino IPMIArduino对于环境传感器我们需要一个可靠、简单的数据采集和初步封装单元。Arduino开发门槛低社区库丰富能快速将模拟/数字传感器信号转换为串口数据并通过ZigBee模块发送是连接物理世界和数字世界的理想桥梁。IPMI对于服务器硬件监控我们必须采用带外Out-of-Band管理方式。这意味着即使服务器操作系统崩溃、无响应我们依然能通过独立的BMC基板管理控制器获取硬件状态。IPMI是服务器行业的通用标准通过ipmitool等命令行工具可以稳定、安全地获取电压、温度、功耗等关键信息可靠性远高于在操作系统内安装代理软件的方式。3. 核心模块实现与实操要点有了清晰的架构和选型接下就是动手实现。我将分模块拆解其中的关键步骤和那些“教科书上不会写”的实操细节。3.1 无线传感器网络的搭建与调优这是整个系统中最具挑战性的硬件部分难点不在于单个节点的编程而在于让几十上百个节点稳定、协同地工作。硬件连接与节点配置 我们使用Arduino Mega 2560作为主控板因为它串口多便于同时连接传感器和XBee模块。以温湿度传感器DHT11为例数据引脚接数字口供电接5V和GND。XBee模块通过USB转TTL适配器或专用扩展板与Arduino连接。每个传感器节点需要配置一个唯一的16位网络地址并设置相同的PAN ID个域网标识符以加入同一个ZigBee网络。ZigBee网络拓扑与自组织过程 我们采用了树状拓扑。其中一个XBee模块配置为“协调器”Coordinator连接在作为汇聚点的树莓派上它是网络的发起者和管理者。其他XBee模块配置为“路由器”Router或“终端设备”End Device。路由器负责中继数据扩展网络覆盖范围终端设备通常是电池供电的传感器只发送自己的数据不参与转发以节省电量。实操心得网络初始化流程的坑。理论上协调器上电后会自动扫描信道、建立网络其他节点会自动发现并加入。但在实际机房电磁环境复杂的背景下这个过程可能失败。我们的经验是必须编写完善的初始化重试和状态监测逻辑。在协调器代码中需要循环检测网络是否成功建立在终端节点代码中加入网络后应发送一个“注册”包到边缘服务器服务器维护一个在线节点列表。对于长时间未“心跳”的节点要在管理界面给出醒目提示这往往是节点故障或电池耗尽的第一个信号。数据包设计与可靠性保障 传感器数据不能简单裸发。我们设计了一个简单的应用层协议帧包含帧头2字节如0xAA0x55、节点ID2字节、传感器类型1字节、数据长度1字节、数据载荷N字节、CRC校验2字节。树莓派上的接收程序必须严格按帧解析校验失败则丢弃。为了应对无线传输可能丢包的问题对于关键告警数据如烟雾报警我们采用了应用层确认重传机制传感器发送告警数据后会等待边缘服务器的ACK确认包如果超时未收到则在随机退避后重发最多3次。这虽然增加了少量延迟但确保了关键告警的可靠性。3.2 边缘服务器的数据接收与处理逻辑边缘服务器树莓派是承上启下的关键。我们使用Python作为主要开发语言因其在数据处理和硬件交互方面的库非常丰富。1. 串口数据接收与解析 协调器XBee模块通过USB连接到树莓派在系统中识别为/dev/ttyUSB0。我们使用pyserial库打开串口设置正确的波特率Zigbee通常为9600或115200。接收数据是一个异步过程我们采用一个独立的线程持续读取串口数据并放入一个缓冲区。主线程或另一个解析线程从缓冲区中取出原始字节流按照之前定义的帧格式进行拆解、校验。import serial import threading from queue import Queue class ZigbeeReceiver: def __init__(self, port, baudrate): self.ser serial.Serial(port, baudrate, timeout1) self.data_queue Queue() self.receiving True self.recv_thread threading.Thread(targetself._read_serial) self.recv_thread.start() def _read_serial(self): buffer bytearray() while self.receiving: data self.ser.read(self.ser.in_waiting or 1) if data: buffer.extend(data) # 在buffer中寻找帧头并解析完整帧 frame self._extract_frame(buffer) if frame: self.data_queue.put(frame) # 将解析好的帧放入队列供处理 def _extract_frame(self, buffer): # 实现具体的帧解析和CRC校验逻辑 # 返回解析后的字典如 {node_id: 1, sensor_type: TEMP, value: 25.6} pass2. 阈值判断与本地告警 解析出数据后立即与预设的阈值进行比较。这里的技巧在于避免告警风暴。例如温度偶尔瞬间跳变一下又恢复正常不应该触发告警。我们实现了两种策略持续时间判定只有当指标连续超过阈值达到一定时间如30秒才触发告警。变化率判定对于温度如果每分钟上升超过5℃即使绝对值未超阈值也触发预警。 告警触发后除了在本地日志记录我们还可以通过树莓派的GPIO控制一个蜂鸣器或LED灯实现声光报警。同时调用短信API如阿里云、腾讯云的短信服务发送告警信息给管理员。3. 数据聚合与上报 原始数据可能每秒一条全部上报中心会造成巨大压力。我们在边缘侧进行聚合每10秒或每分钟计算一次本周期内所有指标的平均值、最大值、最小值生成一条聚合记录。这条记录通过HTTP POST或MQTT协议以JSON格式发送到中心的汇聚服务器。这样数据量减少了90%以上。import requests import json import time class DataAggregator: def __init__(self, edge_id): self.edge_id edge_id self.temp_readings [] self.aggregate_interval 60 # 60秒聚合一次 self.last_upload_time time.time() def add_reading(self, sensor_type, value): if sensor_type TEMP: self.temp_readings.append(value) # 检查是否到达聚合时间 if time.time() - self.last_upload_time self.aggregate_interval: self._upload_aggregated_data() def _upload_aggregated_data(self): if self.temp_readings: agg_data { edge_id: self.edge_id, timestamp: int(time.time()), metrics: { temperature: { avg: sum(self.temp_readings)/len(self.temp_readings), max: max(self.temp_readings), min: min(self.temp_readings) } } } try: resp requests.post(http://central-server/api/data, jsonagg_data, timeout5) if resp.status_code 200: self.temp_readings [] # 清空缓存 self.last_upload_time time.time() else: # 上报失败记录日志下次聚合时尝试重发需考虑去重 pass except Exception as e: # 网络异常处理 pass3.3 服务器硬件监控IPMI的实践细节通过IPMI监控服务器关键在于稳定、安全地执行远程命令。我们通常在边缘服务器上安装ipmitool工具。安全配置 首先需要在被监控服务器的BIOS/BMC设置中启用IPMI over LAN并设置一个强密码的独立管理用户非操作系统用户。为了安全最好配置IPMI访问的源IP白名单只允许边缘服务器的IP地址访问。数据采集脚本 编写一个Shell或Python脚本定期如每30秒通过ipmitool执行命令采集数据。例如采集CPU温度、系统功耗#!/bin/bash # 假设BMC IP为192.168.1.100用户为admin密码为password实际应使用配置文件或密钥 IPMI_HOST192.168.1.100 IPMI_USERadmin IPMI_PASSyour_secure_password # 采集CPU温度传感器名称可能因服务器型号而异 CPU_TEMP$(ipmitool -H $IPMI_HOST -U $IPMI_USER -P $IPMI_PASS sensor get CPU Temp | grep Sensor Reading | awk {print $4}) # 采集系统瞬时功耗 POWER$(ipmitool -H $IPMI_HOST -U $IPMI_USER -P $IPMI_PASS dcmi power reading | grep Instantaneous power | awk {print $4}) echo CPU_TEMP:$CPU_TEMP,POWER:$POWER注意事项与常见问题传感器名称不一致不同品牌、型号的服务器IPMI传感器名称可能不同如“CPU Temp” vs “CPU1 Temp”。需要先通过ipmitool sensor list命令列出所有传感器确认准确的名称。最好能做一个服务器型号与传感器名称的映射表。性能开销过于频繁地轮询IPMI比如每秒一次可能会给BMC带来微小负载。通常30秒到2分钟的间隔是合理的平衡点。网络延迟与超时IPMI命令执行可能需要几百毫秒脚本中必须设置合理的超时时间避免因某台服务器BMC无响应而阻塞整个采集流程。建议使用异步或多线程方式进行采集。3.4 实时可视化与WebSocket的应用运维人员需要一个直观的界面来查看监控状态。我们采用B/S架构前端使用Vue.js或React图表库选用ECharts后端使用Node.js或Python Flask/Django。为什么选择WebSocket传统的监控仪表盘通过HTTP轮询Polling从服务器获取数据例如每5秒请求一次。这种方式有两个明显缺点1)延迟高数据更新最快也是5秒后2)资源浪费无论数据是否变化都会产生大量无效请求。WebSocket提供了全双工通信通道连接建立后服务器可以随时主动向浏览器推送数据更新实现了真正的实时性且开销更低。后端WebSocket服务实现Node.js示例 我们使用ws库快速搭建一个WebSocket服务器。它的工作流程是前端页面加载后建立与后端WebSocket服务器的连接。后端维护一个所有连接的客户端列表。当边缘服务器上报新的聚合数据或IPMI采集到新数据时汇聚服务器的处理程序会将数据写入数据库并同时通过WebSocket服务器向所有在线的浏览器客户端广播这条新数据。前端收到数据后动态更新ECharts图表。// WebSocket服务器端 (Node.js) const WebSocket require(ws); const wss new WebSocket.Server({ port: 8080 }); let clients []; wss.on(connection, function connection(ws) { clients.push(ws); console.log(新的客户端连接); ws.on(close, () { clients clients.filter(client client ! ws); }); }); // 假设这是收到新监控数据的函数 function onNewMonitoringData(data) { // 1. 将data存入数据库如InfluxDB, MySQL // 2. 通过WebSocket广播给所有前端 const message JSON.stringify(data); clients.forEach(client { if (client.readyState WebSocket.OPEN) { client.send(message); } }); }前端数据展示与告警 前端通过ECharts绘制实时曲线图、仪表盘等。当通过WebSocket接收到数据时更新图表序列。同时前端也需要进行一次阈值判断作为后端判断的冗余如果发现数据异常可以在浏览器内弹出弹窗警告并改变对应数据点的颜色如变红。4. 系统部署、测试与性能评估一个系统设计得再好最终也要经受真实环境的考验。部署和测试阶段是暴露问题、优化系统的关键。4.1 分阶段部署策略不建议一次性在全机房铺开。我们采用“试点-扩展-全覆盖”的渐进策略单柜试点选择一个非核心业务的机柜部署1个边缘服务器树莓派连接3-5个传感器节点温湿度、烟雾并监控该机柜内的2-3台服务器。运行至少一周重点测试传感器数据准确性、无线网络稳定性、边缘告警触发是否及时、Web界面展示是否正常。区域扩展试点稳定后在一个机房区域如一个微模块内部署。此时需要规划ZigBee网络的拓扑合理安排路由器的位置以确保信号全覆盖。测试多跳路由的稳定性、边缘服务器数据聚合与上报的压力。全网覆盖最后推广到整个数据中心。此时汇聚服务器的压力成为重点需要考虑数据库选型时序数据库如InfluxDB更适合、数据归档策略、以及是否需要引入更高级别的区域汇聚节点。4.2 关键性能指标测试与验证我们参考了原文中的评估方法并加入了一些更贴近实际运维的测试点。1. 数据采集准确性验证环境数据将商用高精度温湿度计与我们的DHT11节点放置在同一位置连续记录24小时数据对比曲线计算平均误差和均方误差。我们的测试结果显示DHT11在15-35℃范围内湿度误差在±5%RH以内温度误差在±2℃以内对于机房监控预警而言完全足够。功耗数据这是验证的重点。我们使用钳形功率计高精度万用表测量服务器电源输入线的真实功耗同时通过IPMI接口读取功耗值进行对比。如原文所述在服务器空闲和运行SPECpower负载两种状态下IPMI读数与外部仪表读数的误差均在2%以内相关性系数达到0.97以上证明了IPMI采集数据的可靠性。2. 系统实时性与延迟测试 这是边缘计算价值的核心体现。我们设计了一个测试在传感器节点旁用热风枪快速加热模拟局部过热。同时用秒表记录三个时间点T1温度传感器读数超过阈值。T2边缘服务器本地声光报警器响起。T3运维人员手机收到告警短信。T4中心监控大屏上该点变红。 测试结果令人满意T2 - T1 平均在2秒以内这包括了无线传输、边缘处理的时间T3 - T1 平均在5秒以内这增加了短信网关的延迟而传统的纯中心式架构T4 - T1 往往在10秒以上甚至更久。这宝贵的几秒到十几秒对于防止热失控至关重要。3. 网络与系统稳定性压力测试ZigBee网络规模我们测试了单个协调器下连接不同数量终端设备10, 20, 40, 60的场景。发现当节点数超过40时使用简单的Ad-hoc组网方式节点入网失败率和数据丢包率显著上升。这与原文的发现一致。解决方案是采用更智能的“源路由”或“集群树”网络拓扑并优化路由表维护算法。对于大规模部署必须进行分簇每个簇由一个协调器管理再通过上层网络如以太网将多个簇的数据汇聚。边缘服务器负载监控树莓派在持续运行一周后的CPU、内存使用情况。在处理20个传感器节点、5台服务器IPMI数据的情况下树莓派3B的CPU利用率平均在15%以下内存占用稳定在200MB左右证明其完全有能力承担一个区域边缘节点的计算任务。4.3 能耗管理的初步应用监控的最终目的是为了优化。我们采集的机柜级功耗数据可以用于一些初级的能耗管理功耗基线建立分析不同时间段工作日/周末、白天/夜晚的功耗基线识别异常耗电。PUE电源使用效率近似计算虽然精确计算PUE需要总配电房数据但通过汇总各机柜的IT设备功耗可以估算IT总负载结合机房总用电量从动环监控获取可以计算出近似的PUE值用于能效趋势分析。与虚拟机调度联动未来方向这是更智能化的方向。边缘服务器可以将本区域的服务器负载和功耗数据上报汇聚心的智能调度系统可以基于这些数据在保证业务性能的前提下将虚拟机迁移到能效更高的服务器上或者将低负载服务器置于节能状态从而实现数据中心的整体节能。5. 常见问题、故障排查与运维心得在实际运行中这套系统会遇到各种各样的问题。我把踩过的坑和解决方法总结如下希望能帮你少走弯路。5.1 无线传感器网络常见故障排查表故障现象可能原因排查步骤与解决方法单个节点数据丢失1. 电池耗尽2. 节点故障死机3. 无线信号被遮挡/干扰1. 检查节点电源电压。2. 尝试物理复位节点。3. 使用ZigBee信号强度测试工具如XBee的AT指令DB检查链路质量调整节点或路由器位置。整个区域节点间歇性丢包1. ZigBee信道冲突与Wi-Fi等同频段干扰2. 协调器负载过高或不稳定3. 网络中存在“坏节点”广播干扰1. 使用Wi-Fi分析仪扫描将ZigBee信道切换到相对空闲的如信道15, 20, 25。2. 检查边缘服务器协调器连接处CPU和内存使用率重启协调器。3. 通过协调器日志或网络嗅探工具定位频繁发送异常数据的节点将其隔离检修。新节点无法加入网络1. PAN ID不匹配2. 网络已满协调器地址池耗尽3. 安全密钥错误1. 确认新节点的PAN ID与网络协调器一致。2. 检查协调器配置扩大子节点地址范围。3. 如果启用了加密确认密钥完全一致。数据传输延迟大1. 网络跳数过多2. 路由器节点处理能力不足或休眠1. 优化网络拓扑尽量减少源节点到协调器的跳数最好不超过4跳。2. 确保路由器节点供电充足并配置为永不进入休眠模式。5.2 边缘服务器与软件层问题树莓派SD卡损坏这是嵌入式设备长期运行的老大难问题。频繁的日志写入容易导致SD卡寿命终结。解决方案1) 使用高质量、高耐久度的工业级SD卡2) 将日志写入到RAM磁盘tmpfs定期同步到SD卡或通过网络发送到中心日志服务器3) 考虑使用只读文件系统或者将根文件系统迁移到USB SSD更稳定。IPMI连接突然中断可能原因1) BMC网络IP冲突2) BMC固件bug导致进程卡死3) 防火墙规则变更。排查首先从边缘服务器ping BMC的IP如果不通检查网络链路如果通尝试用ipmitool的lan print命令检查BMC网络配置。预防为BMC管理口配置静态IP并纳入统一的IP地址管理IPAM体系。数据库性能瓶颈随着时间推移监控数据量会非常庞大。如果直接使用MySQL单表查询会越来越慢。强烈建议使用时序数据库如InfluxDB、TDengine或Prometheus。它们针对时间序列数据的高写入、高压缩率和时间范围查询做了极致优化并且天然支持数据自动降采样Downsampling和过期删除Retention Policy管理起来非常方便。WebSocket连接数上限当大量运维人员同时打开监控页面时单个Node.js服务的WebSocket连接数可能达到上限。解决方案1) 使用ws库的noServer模式结合Nginx进行负载均衡和多实例部署2) 对于超大规模场景考虑使用专业的WebSocket网关或消息中间件如Redis Pub/Sub来分发数据。5.3 一些宝贵的实操心得标签化一切给每个传感器、每台服务器、每个边缘节点都打上清晰的物理位置标签如“A列03柜上中部”、“服务器-业务DB-01”并在软件配置中与之关联。当告警发生时能立刻定位到物理位置这是快速响应的第一步。配置即代码版本化管理所有节点的配置文件如ZigBee信道、PAN ID、采样频率、告警阈值不要手动设置而应写成模板化的配置文件并使用Ansible、SaltStack等工具进行批量部署和更新。将这些配置文件纳入Git版本控制任何变更都有迹可循。监控系统自身也需要被监控这是运维的“元问题”。我们为每个边缘服务器添加了“自监控”指标CPU温度、SD卡剩余空间、进程存活状态、最近一次数据上报时间。这些指标统一上报到中心一旦某个边缘节点自身异常我们能第一时间知道。灰度发布与回滚对边缘服务器上的处理逻辑或告警规则进行更新时切忌全量推送。先选择1-2个非核心区域的节点进行灰度发布观察24小时无异常后再分批滚动更新。同时一定要保留旧版本的程序包和配置以便快速回滚。文档与知识沉淀将部署拓扑图、IP地址表、传感器点位图、故障处理手册等文档维护好。运维团队人员流动是常态清晰的文档是系统长期稳定运行的保障。这个基于边缘计算的智能运维监控平台从构思到落地是一个不断权衡、迭代和解决问题的过程。它带给我的最大体会是好的架构是演进而来的而不是设计出来的。最初我们可能只关注数据能不能采上来后来开始关心实时性再后来关注系统的可维护性和扩展性。边缘计算不是替代云计算而是与之协同将智能分布到最适合的层级。这个平台目前已经稳定运行了相当长的时间将运维人员从繁琐的日常巡检和被动救火中解放出来真正实现了从“人找故障”到“故障找人”的转变。未来我们计划在边缘侧引入更轻量级的AI模型尝试对设备故障进行预测性维护让这个系统变得更加“智能”。
