実運用での DDM 監視

DDM を一度読み取れば、モジュールの現在の状態が分かります。それをトレンド化すれば、将来が分かります。ほとんどの光学的な故障は、数値を記録している人になら、数週間前から予兆を示します。Rx パワーの緩やかな低下、バイアス電流の上昇、FEC 前 BER の上昇といった形です。

ベンチ、CLI、NMS

SNMP でのデータ収集

ほとんどのプラットフォームは、標準のENTITY-SENSOR-MIB（entPhySensorValue、センサーごとに種別／スケール／精度を持つ）と、ベンダー独自の MIB（Cisco のエンティティセンサー、Juniper の DOM MIB、Arista、Huawei）を通じて DDM を公開しています。LibreNMS のようなオープンソース NMS は、光学センサーを自動検出してグラフ化します。Zabbix や Prometheus/Grafana も、同じ OID やストリーミングテレメトリーで動作します。DDM の値はゆっくりとしか変化せず、モジュールも2線バスにのんびりとした速度でしか応答しないため、ポーリングは1〜5分間隔で十分です。

リンクパスポート

設置時には、すべてのリンクの両端について記録してください。

• Tx パワー、Rx パワー、バイアス電流、温度（DDM 一式）
• モジュールのベンダー／型番／シリアル
• 光ファイバーの長さ、可能であれば OTDR トレース

このベースラインが、その後の読み値と比較する基準になります。ベースラインがなければ、「Rx は −12 dBm」はただの数値です。ベースラインがあれば、「Rx は3月から 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、アラームの階層関係、モジュールデータと光ファイバーデータの突き合わせ：監視と管理。