三公一元一分微信群式的热闹，别搬进润滑监测告警阈值里

某矿山破碎线的主减速机，铁谱磨粒浓度在两周内从 18ppm 爬到 41ppm，随后回落。系统按单点阈值只在中段报过一次警，当时被当作取样污染处理。三个月后该机组因齿面点蚀提前更换齿轮轴。回看数据，真正有价值的不是那一次越限，而是爬升斜率与同工况历史分位的偏离——这类信号如果只靠固定阈值，几乎一定会漏。

这正是把监测做成「消息流」的代价：单指标越限容易触发，趋势形态却需要按设备类型、工况段和油品批次分别建模。GMG在采集层保留原始采样序列，趋势分析按班次聚合而非逐点推送，目的就是让运维先看到形状，再决定是否进入检查流程。

• 观察层：指标偏离基线但未越工程限值，只写入日汇总，不推送手机。
• 关注层：连续两个采样周期同向偏离，生成待复核条目，由润滑工程师确认是否为工况变化或取样误差。
• 干预层：越工程限值且伴随温度或黏度同向变化，才进入告警通道并关联计划停机窗口。

告警发出后最怕的是「群里回一句收到」就结束。建议把关注层以上的条目绑定三项动作：取样复测、同机组相邻测点比对、历史同工况分位查询。三项都完成才允许关闭条目，关闭时记录判断依据。这样一条告警从产生到闭环都有可回溯记录，下一轮阈值调整才有依据，而不是凭印象拍板。