LibreNMS discovery trên Nokia 7705 chết với Column 'channels' cannot be null và không thu được DOM
Bọn mình poll một số router aggregation Nokia 7705 trong LibreNMS và mình muốn lấy DOM quang từ chúng vì lý do thường thấy - bắt được một tuyến đang yếu dần trước khi khách hàng nhận ra. Discovery không bao giờ chạy xong trên các thiết bị đó.
- Nokia 7705 chạy TiMOS
- LibreNMS 26.3.1
- SFP 1G single-lane bình thường trong các cổng, nhiều vendor khác nhau, một số đã cũ
- SNMP thì vẫn khỏe: interface, CPU, memory và traffic đều poll tốt
Discovery dừng ở đây mỗi lần:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be nullvà kết quả là không có entry transceiver, không có optical sensor cho cả router - không phải một cổng lỗi còn lại vẫn chạy, mà cả thiết bị trả về trống trơn.
Đã thử:
- Chạy lại discovery riêng cho mỗi thiết bị, vẫn lỗi y hệt ở đúng chỗ đó
- Xóa rồi thêm lại thiết bị: nó được tạo, rồi discovery chết ở đúng chỗ cũ
- Các vendor khác trong cùng hệ thống vẫn discover transceiver và DOM bình thường, nên có vẻ không phải database phía mình bị hỏng
Đây có phải lỗi discovery đã biết của TiMOS không, và có gì để làm ngoài việc tắt hẳn transceiver discovery cho các router này?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Lỗi đã biết, và không phải database của bạn đâu.
Code discovery của TiMOS lấy số lane từ TIMETRA-PORT-MIB::tmnxPortSFPNumLanes và nhét thẳng bất cứ gì lấy được vào cột
channels, mà cột này không chấp nhận NULL. Optic single-lane đời cũ là thủ phạm thường gặp nhất: agent không bao giờ điền giá trị cho object đó ở chúng, nên cổng đưa vào insert một giá trị null, insert nổ, và lỗi đó kéo sập luôn discovery transceiver của cả thiết bị theo. Đó là lý do bạn mất toàn bộ cổng chứ không chỉ cổng có module lạ.Hai cách thoát. Sạch nhất là đưa LibreNMS lên bản mới hơn - thay đổi đã được chấp nhận upstream sẽ bảo vệ giá trị này trong LibreNMS/OS/Timos.php, sao cho số lane bị thiếu hoặc rỗng được đọc thành một channel duy nhất, còn gì khác thì bị ép thành số nguyên. Nếu kẹt ở bản hiện tại, tự tay đưa cùng đoạn bảo vệ đó vào file; chỉ vài dòng thôi, dù nó sẽ biến mất ở lần update tiếp theo nếu bạn quên mất nó ở đó.
Trước khi patch bất cứ gì, hãy walk TIMETRA-PORT-MIB::tmnxPortSFPNumLanes trên router. Cổng nào trả lời trống rỗng chính là cổng đang giết chết câu insert, và cũng đáng để biết optic nào đang cắm ở đó.
Xác nhận đúng cả hai điểm, cảm ơn.
Walk OID đó: các cổng có optic 1G cũ nhất trả về trống trơn cho số lane, mọi thứ mới hơn trả lời bằng 1. Vậy null đến từ các module mình thừa hưởng lại, đúng như mô tả.
Sau khi chuyển sang bản build có check đó, discovery chạy hết trên toàn bộ 7705, các transceiver xuất hiện với một channel mỗi cái, và optical sensor đang được vẽ đồ thị. Không đổi gì phía router, không loại trừ cổng nào.
Có hai điều nên lường trước giờ discovery đã chạy xong.
DDM trên thiết bị Nokia bị chặn bởi một cờ capability trong EEPROM của module. Đó là cách tiếp cận chung của hãng trên khắp các dòng sản phẩm, và được nói rõ nhất trong 7210 SAS interface guide: nền tảng này sẵn sàng in ra số liệu chẩn đoán cho một module chưa từng set cờ đó, trong khi cũng nói ngay trong cùng đoạn văn rằng họ chưa validate hay verify các con số đó. Khác dòng máy với bạn, nhưng cùng logic - số RX/TX nghe hợp lý từ một optic bên thứ ba không phải bằng chứng là hiệu chuẩn đúng.
Nửa còn lại là chính module. GLC-SX-MM không có trang A2h, nên chẳng có gì để poller đọc cả; GLC-SX-MMD thì có, chữ D là diagnostics. Một đồ thị phẳng lì trống trơn vĩnh viễn, kiểm tra cái đó trước khi nghi ngờ poller.