生产环境中的 DDM 监测
读取一次 DDM 只能说明模块此刻的状态,做趋势分析才能说明它未来的走向。多数光模块故障会提前数周显现征兆:Rx 功率漂移、偏置电流攀升、FEC 前误码率上升,只是需要有人在记录这些数字才能看到。
工作台、CLI 还是 NMS
| 场景 | 工具 | 最适合 |
|---|---|---|
| 工作台 | CodingBox DDM 界面、CSV 导出 | 来料检验、建立基线、诊断拆下的模块 |
| 交换机 CLI | show interfaces transceiver 及各平台对应命令(按 NOS) | 故障排查时的抽查 |
| NMS / 遥测 | SNMP、流式遥测(gNMI)、厂商 API | 全网范围的趋势分析与告警 |
通过 SNMP 采集
多数平台通过标准的 ENTITY-SENSOR-MIB(entPhySensorValue,每个传感器带有类型/量程/精度)以及厂商私有 MIB(Cisco 的 entity sensor、Juniper 的 DOM MIB、Arista、华为)暴露 DDM 数据。LibreNMS 等开源 NMS 能自动发现光模块传感器并绘制曲线;Zabbix 和 Prometheus/Grafana 既可以使用同样的 OID,也可以使用流式遥测。轮询间隔取 1–5 分钟即可:DDM 数值变化缓慢,模块响应两线总线的速度也不快。
链路档案
安装时,为每条链路的两端都记录以下内容:
- Tx 功率、Rx 功率、偏置电流、温度(即 DDM 这组参数);
- 模块厂商 / 型号 / 序列号;
- 光纤长度,如有条件,还包括 OTDR 曲线。
后续读数都要与这份基线对比。没有基线,“Rx 为 −12 dBm”只是一个数字;有了基线,“Rx 自三月以来下降了 2.5 dB”就是一份工单。
告警:看变化量,而不只是阈值
模块的阈值是厂商自定的限值(参见阈值与告警);你自己的告警应当更严格,并且基于相对变化:
| 信号 | 建议触发条件 | 可能的含义 |
|---|---|---|
| Rx 功率 | 相对基线下降 2–3 dB | 连接器脏污/损坏、光纤弯折、对端激光器衰退 |
| Rx 功率 | 两个方向不对称 | 问题出在偏弱的一侧,而非线路本身 |
| Tx 偏置电流 | 相对基线上升 15–20% | 激光器老化,应安排更换 |
| 温度 | 超过 65–70 °C,或相对基线上升 +10 °C | 散热或密度问题 |
| FEC 前误码率(CMIS/VDM) | 向 FEC 极限攀升 | PAM4 链路上的最早征兆 |
| 模块告警标志位 | 任意 | 兜底手段,不应作为第一道告警 |
快速响应
- 重要链路上的 BFD 能在毫秒级发现路径劣化,远早于路由协议或用户察觉。
- 对多通道模块要跟踪逐通道数值(参见分通道诊断),单一通道失效是 AI/数据中心场景中最常见的故障模式。
- 阈值触发后,按照诊断阶梯推进:电平 → 清洁 → 更换 → OTDR。
DDM 无法告诉你的事
- 廉价模块的 Tx 功率可能是一个固定值(参见DDM 电平)。
- DDM 看到的是光,不是比特:链路电平完全正常,仍可能因色散、FEC 不匹配或极性故障而出错,因此要将 DDM 与误码计数器结合使用。
- 分辨率为 0.1 µW:低于 −40 dBm 的数值无法测量。
CodingBox 中的呈现
CodingBox 承担的是这一流程中工作台一侧的工作:可配置的轮询间隔、测量日志和 CSV 导出在安装前生成链路档案,并让拆下的模块可以在 code database 中与自己的历史记录对比。
采集细节:CLI 命令、
ethtool、ENTITY-SENSOR-MIB 与厂商 OID、OpenConfig 路径,参见用工具读取 DDM。PAM4 链路上该告警什么,参见VDM 与 FEC 指标。
按厂商列出承载本文所述数值的 SNMP 对象、OpenConfig 遥测路径和 syslog 消息,参见管理与监测。
趋势能揭示的缓慢线路故障(污染、接头进水、季节性波动)以及趋势异常后的排查顺序,参见光纤线路故障。
DDM 置于整个有源基础设施背景下的位置(放大器遥测、OSC、OCM、RFTS、告警分级,以及模块数据与光纤数据的关联分析),参见监测与管理。