CodingBox Q&A Ask question

LibreNMS 对 Nokia 7705 的发现过程报 Column 'channels' cannot be null 并中止,采不到 DOM 数据

Asked Active Viewed 60 AI translation from English
3

我们在 LibreNMS 里轮询几台 Nokia 7705 汇聚路由器,出于常见的理由想采集光路 DOM 数据——在客户发现之前先捕捉到一条链路正在劣化。这些设备上的发现(discovery)流程始终跑不完。

  • 跑 TiMOS 的 Nokia 7705
  • LibreNMS 26.3.1
  • 端口上是普通的单通道 1G SFP,混杂多个厂商,其中一些比较老
  • SNMP 其他方面都很健康:接口、CPU、内存和流量都能正常轮询

发现流程每次都在这里停住:

SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be null

结果是整台路由器都没有任何光模块记录,也没有任何光学传感器——不是某一个坏端口拖累、其余正常,而是整台设备的结果都是空的。

我已经尝试过:

  • 单独对这台设备重跑发现流程,在同一个位置报同样的错误
  • 删除设备再重新添加:设备能创建成功,但发现流程在同一个地方挂掉
  • 同一套环境里的其他厂商设备能正常发现光模块和 DOM,所以看起来不像是我这边数据库坏了

这是不是一个已知的 TiMOS 发现问题,除了对这些路由器整体关闭光模块发现之外,还有什么办法?

Comments 3

Accepted answer

这是个已知问题,不是你数据库的锅。

TiMOS 的发现代码是从 TIMETRA-PORT-MIB::tmnxPortSFPNumLanes 里取通道数,拿到什么就直接塞进 channels 这一列,而这一列是不接受 NULL 的。老式单通道光模块通常就是罪魁祸首:agent 从来不会为它们填充这个对象,于是端口往插入语句里塞进了一个 null,插入就崩了,而这一次失败会把整台设备的光模块发现全部拖下水。这就是为什么你丢的是全部端口,而不只是那个用了特殊模块的端口。

有两条出路。最干净的是升级 LibreNMS——上游已经接受的改动在 LibreNMS/OS/Timos.php 里加了一层保护,让缺失或者空的通道数被当作单通道来处理,其他情况则强制转成整数。如果暂时升不了版本,就手动把同样的保护逻辑加到那个文件里;就几行代码,不过下次更新时如果你忘了它的存在,它就会被覆盖掉。

在动手打补丁之前,先在路由器上把 TIMETRA-PORT-MIB::tmnxPortSFPNumLanes 挨个查一遍。哪些端口返回空值,就是它们在把插入语句搞崩,顺便也值得看看这些端口上到底插的是什么光模块。

7 CanadalinkadminCA Show original (English) AI translation

两点都确认了,谢谢。

查了那个 OID:用最老的 1G 光模块的端口,通道数这一项完全没有返回任何值,所有更新一些的模块都返回 1。所以这个 null 正是来自我接手的那些老模块,跟描述的完全一致。

升级到带这个检查的版本之后,所有 7705 上的发现都能跑完了,光模块都以单通道的形式出现,光学传感器也已经在出图了。路由器那边什么都没改,也没有排除任何端口。

0 Indiawaverunner21IN Show original (English) AI translation

既然发现流程能跑完了,接下来有两件事要留意。

Nokia 设备上的 DDM 是靠模块 EEPROM 里的一个能力标志位来控制的。这是整个产品家族的通用做法,在 7210 SAS 接口手册里说得最明白:平台会心安理得地给一个从没设置过这个标志位的模块打印诊断数据,同一段话里又说它没有对这些数值做过校验或验证。虽然是不同的设备,逻辑是一样的——第三方光模块给出的看似合理的 RX/TX 数值,并不能证明校准是准的。

另一半是模块本身的问题。GLC-SX-MM 没有 A2h 页面,所以任何轮询器都读不到任何东西;GLC-SX-MMD 有,这个 D 就是 diagnostics 的意思。有一张图会永远是一条平平的空线,在怀疑轮询器之前先检查这一点。

2 Netherlandsoptichub40NL Show original (English) AI translation
Log in to comment. Log in