生產環境中的 DDM 監測

讀取一次 DDM 只能說明模組此刻的狀態，做趨勢分析才能說明它未來的走向。多數光模組故障會提前數週顯現徵兆：Rx 功率漂移、偏置電流攀升、FEC 前誤碼率上升，只是需要有人在記錄這些數字才能看到。

工作台、CLI 還是 NMS

通過 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」就是一份工單。

警報：看變化量，而不只是閾值

模組的閾值是廠商自定的限值（參見閾值與警報）；你自己的警報應當更嚴格，並且基於相對變化：

快速響應

• 重要鏈路上的 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、警報分級，以及模組數據與光纖數據的關聯分析），參見監測與管理。