실제 운용에서의 DDM 모니터링

DDM을 한 번 읽으면 모듈의 현재 상태를 알 수 있고, 추이를 보면 그 미래를 알 수 있습니다. 대부분의 광학 장애는 몇 주 전부터 — 드리프트하는 Rx 파워, 상승하는 바이어스 전류, 올라가는 pre-FEC BER의 형태로 — 수치를 기록하고 있는 사람에게 미리 신호를 보냅니다.

벤치, CLI, NMS

SNMP로 수집하기

대부분의 플랫폼은 표준 ENTITY-SENSOR-MIB(entPhySensorValue, 센서별 타입/스케일/정밀도 포함)와 벤더 MIB(Cisco 엔티티 센서, Juniper DOM MIB, Arista, Huawei)를 통해 DDM을 노출합니다. LibreNMS 같은 오픈소스 NMS는 광 센서를 자동으로 찾아내 그래프로 보여주며, Zabbix와 Prometheus/Grafana도 같은 OID나 스트리밍 텔레메트리로 동작합니다. 1–5분마다 폴링하십시오 — DDM 값은 천천히 변하고, 모듈이 2선식 버스에 응답하는 속도도 느긋합니다.

링크 패스포트

설치 시점에 모든 링크의 양 끝에 대해 다음을 기록하십시오.

• Tx 파워, Rx 파워, 바이어스 전류, 온도(DDM 값 일체);
• 모듈 벤더/부품 번호/시리얼 번호;
• 광섬유 길이, 가능하다면 OTDR 트레이스.

이 기준값이 이후 판독값과 비교하는 대상이 됩니다. 기준값이 없으면 "Rx가 −12 dBm"은 그냥 숫자에 불과하지만, 기준값이 있으면 "3월 이후 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, 알람 계층 구조, 모듈 데이터와 광섬유 데이터의 상관 분석: 모니터링과 관리.