Discovery do LibreNMS num Nokia 7705 morre com Column 'channels' cannot be null e não coleta DOM
Fazemos polling de um punhado de roteadores de agregação Nokia 7705 no LibreNMS e eu queria o DOM óptico deles pelo motivo de sempre - pegar um enlace degradando antes do cliente perceber. O discovery nunca termina nesses equipamentos.
- Nokia 7705 rodando TiMOS
- LibreNMS 26.3.1
- SFPs comuns de 1G single-lane nas portas, vendors misturados, alguns antigos
- SNMP saudável no resto: interfaces, CPU, memória e tráfego, tudo faz polling normalmente
O discovery para aqui toda vez:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be nulle o resultado é nenhuma entrada de transceiver e nenhum sensor óptico para o roteador inteiro - não é uma porta ruim com o resto funcionando, o equipamento inteiro volta vazio.
O que eu já tentei:
- rodei o discovery de novo só para esse equipamento, mesmo erro no mesmo ponto
- apaguei e recadastrei o equipamento: ele é criado, e depois o discovery morre no mesmo lugar
- outros vendors na mesma instalação fazem discovery de transceivers e DOM normalmente, então não parece um banco de dados quebrado do meu lado
Isso é um problema conhecido de discovery no TiMOS, e tem algo para fazer a respeito, além de desligar o discovery de transceiver para esses roteadores?
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
Esse é conhecido, e não é o seu banco de dados.
O código de discovery do TiMOS pega a contagem de lanes em TIMETRA-PORT-MIB::tmnxPortSFPNumLanes e joga o que vier direto na coluna
channels, que não aceita NULL. Ópticas antigas de single-lane são as culpadas de sempre: o agent nunca popula esse objeto para elas, então a porta entrega um null para o insert, o insert explode, e a falha derruba o discovery de transceiver do equipamento inteiro junto com ela. É por isso que você perde todas as portas em vez de só a do módulo estranho.Duas saídas. A mais limpa é avançar a versão do LibreNMS - a mudança aceita lá na origem protege o valor em LibreNMS/OS/Timos.php, de forma que uma contagem de lanes ausente ou vazia é lida como um canal único e qualquer outra coisa é forçada para inteiro. Se você está preso na sua versão atual, coloque a mesma proteção nesse arquivo na mão; são umas duas linhas, embora ela vá sumir na próxima atualização se você esquecer que ela está lá.
Antes de aplicar qualquer patch, percorra TIMETRA-PORT-MIB::tmnxPortSFPNumLanes no roteador. As portas que responderem com nada são as que estão matando o insert, e vale saber quais ópticas estão sentadas nelas.
Confirmado nos dois pontos, obrigado.
Percorrendo esse OID: as portas com as ópticas de 1G mais antigas não retornam nada para a contagem de lanes, tudo que é mais novo responde com 1. Então o null vem dos módulos que eu herdei, exatamente como descrito.
Depois de migrar para uma build que tem a checagem, o discovery vai até o fim em todos os 7705, os transceivers aparecem com um canal único cada, e os sensores ópticos estão sendo plotados em gráfico. Nenhuma mudança do lado do roteador, nenhuma porta excluída.
Duas coisas para esperar agora que o discovery termina.
O DDM nos equipamentos Nokia é controlado por uma flag de capability no EEPROM do módulo. Essa é a abordagem padrão da casa em todas as famílias, e está escrita mais claramente no guia de interface do 7210 SAS: a plataforma imprime diagnósticos numa boa para um módulo que nunca seta a flag, dizendo no mesmo parágrafo que não validou nem verificou esses números. Caixa diferente da sua, mesma lógica - números de RX/TX plausíveis numa óptica de terceiros não são prova de que a calibração está certa.
A outra metade é o módulo em si. GLC-SX-MM não tem página A2h, então não tem nada para nenhum poller ler; GLC-SX-MMD tem, o D sendo de diagnostics. Um gráfico permanentemente plano e vazio, confira isso antes do poller.