Monitorar OLT Huawei no Zabbix via SNMP: PON, ONU e sinal

Quem precisa monitorar OLT Huawei no Zabbix costuma começar pelo caminho errado: um item SNMP por ONU, cada um com seu próprio GET, e um alarme para cada ONU que cai. Numa OLT com alguns milhares de ONUs, isso vira dezenas de milhares de requisições por ciclo, um agente SNMP sobrecarregado e um NOC que aprende a ignorar o Zabbix porque ele apita o tempo todo.

Eu acompanho OLTs MA5800 por SNMP num sistema que escrevi para a minha operação, e os OIDs, a fórmula do índice e os números de carga deste guia saíram de lá, conferidos contra o CLI da OLT. Aqui eu traduzo essa lógica para o Zabbix 7.0: poucos walks por coluna, itens derivados por PON e por ONU, alarme de PON em vez de alarme de ONU e trigger de sinal com folga. Os exemplos usam a OLT em 192.0.2.10 e o Zabbix em 192.0.2.5.

Resposta rápida: como monitorar OLT Huawei no Zabbix

1. Na OLT, crie uma community só de leitura com snmp-agent community read e aponte os traps para o Zabbix.
2. No Zabbix, crie itens mestre do tipo SNMP agent com walk[], um por coluna: estado da ONU (.46.1.15), Rx (.51.1.4) e serial (.43.1.3), sob a base 1.3.6.1.4.1.2011.6.128.1.1.2.
3. Use descoberta LLD dependente dos walks para criar itens por PON (ONUs online e total) e por ONU (Rx).
4. Alarme por PON: nenhuma ONU online, ou percentual offline acima do limite em PONs maiores.
5. Alarme de sinal com média ou máximo de uma janela, nunca com uma leitura só.
6. Ajuste os intervalos ao tamanho da OLT: o agente SNMP dela entrega um número limitado de linhas por segundo.

Por que monitorar OLT Huawei por SNMP e não pelo CLI

O CLI da MA5800 é ótimo para diagnóstico e péssimo para coleta em massa. Ler a potência de todas as ONUs por SSH, porta por porta, levava mais de 40 minutos numa OLT de cerca de 1.950 ONUs. A saída longa do Telnet chegava cortada com a OLT carregada, e uma leitura parcial fazia ONUs boas parecerem sumidas.

O walk SNMP resolve os dois problemas. Ele traz a tabela inteira ou falha, sem meio-termo silencioso, e cobre todas as ONUs da OLT de uma vez. Numa OLT com cerca de 1.950 ONUs, a coleta de quatro colunas caiu de mais de 40 minutos para 4,1 minutos, com as potências batendo com o CLI. O CLI continua sendo a ferramenta de diagnóstico; o roteiro está no guia de diagnóstico de ONU com LOS ou offline na OLT Huawei.

SNMP na OLT: snmp-agent na MA5800

Antes de monitorar OLT Huawei pelo Zabbix, a OLT precisa responder SNMP e saber para onde mandar os traps. No modo config:

config
snmp-agent community read ZbxLeitura2026
snmp-agent sys-info version v2c
snmp-agent target-host trap-hostname ZB address 192.0.2.5 trap-paramsname ZB
snmp-agent target-host trap-paramsname ZB v2c securityname ZbxLeitura2026
snmp-agent trap enable standard
display snmp-agent community read

• snmp-agent community read cria a community de leitura. Não crie community de escrita para monitoramento: o Zabbix só lê.
• snmp-agent sys-info version v2c habilita o SNMPv2c, que tem o GETBULK usado pelos walks.
• trap-hostname cadastra o Zabbix como destino de traps, com nome ZB, e aponta para a lista de parâmetros ZB. Sem udp-port, o trap vai para a porta padrão 162.
• trap-paramsname ZB v2c securityname define a versão do trap e o nome de segurança que vai junto, aqui igual à community que o snmptrapd vai aceitar.
• snmp-agent trap enable standard liga os traps padrão.
• display snmp-agent community read confere a community criada.

Use uma community longa e diferente das outras OLTs, e libere a porta 161/UDP da OLT só para o servidor Zabbix ou o proxy na rede de gerência. Se você ainda está montando a OLT do zero, veja as configurações iniciais da OLT Huawei; para a navegação entre os modos, os comandos básicos da OLT Huawei MA5800.

Teste do servidor antes de monitorar OLT Huawei no Zabbix

Antes de abrir o Zabbix, confirme do próprio servidor que a OLT responde. Com o pacote de ferramentas do net-snmp instalado:

OLT=192.0.2.10
C=ZbxLeitura2026
B=1.3.6.1.4.1.2011.6.128.1.1.2
snmpget -v2c -c $C $OLT 1.3.6.1.2.1.1.1.0
snmpbulkwalk -v2c -c $C -Cr30 -On $OLT $B.46.1.15
snmpget -v2c -c $C -On $OLT $B.51.1.4.4194312192.1

O primeiro snmpget lê o sysDescr, que mostra modelo e versão da OLT. O snmpbulkwalk percorre a coluna de estado das ONUs; repare que o número do -Cr vai colado, sem espaço, senão o net-snmp não aceita. O -On deixa os OIDs numéricos, sem precisar dos arquivos MIB da Huawei. O último lê o Rx de uma ONU só, pelo índice calculado. A saída do walk tem esta cara:

.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15.4194312192.0 = INTEGER: 1
.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15.4194312192.1 = INTEGER: 2
.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15.4194312192.2 = INTEGER: 1
.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15.4194312448.0 = INTEGER: 1

Como o índice vira frame, slot e porta

Todas as tabelas de ONU usam o mesmo índice composto: o ifIndex da porta GPON, um ponto, e o ONT ID. Na MA5800 que eu monitoro, o ifIndex segue a fórmula 4194304000 + slot × 8192 + porta × 256. A porta 0/1/0 é 4194312192, a 0/1/1 é 4194312448. Na saída acima, as três primeiras linhas são as ONTs 0, 1 e 2 da porta 0/1/0, e o valor 2 da segunda indica ONU offline.

Eu conferi essa fórmula contra o display ont info 0 all em mais de 15 mil ONTs, sem divergência. Em outro modelo de chassi, confira antes: leia o serial pelo índice calculado e compare com o CLI. Se o serial não bater, a fórmula é outra.

OIDs para monitorar OLT Huawei: status e sinal

A base para monitorar OLT Huawei GPON é 1.3.6.1.4.1.2011.6.128.1.1.2. Os OIDs abaixo são colunas de tabela: acrescente o índice ifIndex.ontId para ler uma ONU. A última coluna diz o que eu conferi contra o CLI na mesma ONU e no mesmo minuto.

Dois cuidados. ONU offline ou sem leitura óptica devolve 2147483647 nas colunas de potência e temperatura: é um valor sentinela, não um sinal absurdo, e precisa ser descartado. E a causa da queda guarda a última queda, não a situação atual. Uma ONU online há semanas continua mostrando o dying-gasp antigo. Na tabela pública da Huawei há dezenas de códigos de causa, mas só rotule o que você conferiu no seu firmware. Antes de criar os alarmes de PON, confira o estado de duas ou três ONUs no CLI e no walk, uma online e uma offline.

Template para monitorar OLT Huawei: poucos walks, muitos itens

A ideia central para monitorar OLT Huawei sem pesar o agente é coletar cada coluna uma vez por ciclo e derivar o resto dentro do Zabbix. O item walk[] do Zabbix 7.0 usa GETBULK e devolve o texto no mesmo formato do snmpwalk. Itens dependentes leem esse texto por pré-processamento, sem nenhuma requisição nova à OLT.

No template, crie três itens mestre, todos do tipo SNMP agent e sem histórico, porque o valor bruto só serve para alimentar os dependentes:

Item mestre 1 (tipo SNMP agent)
  Nome:       GPON: walk de estado
  Chave:      gpon.walk.run
  SNMP OID:   walk[1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15]
  Intervalo:  5m
  Histórico:  não guardar

Item mestre 2 (tipo SNMP agent)
  Nome:       GPON: walk de Rx das ONUs
  Chave:      gpon.walk.rx
  SNMP OID:   walk[1.3.6.1.4.1.2011.6.128.1.1.2.51.1.4]
  Intervalo:  15m
  Histórico:  não guardar

Item mestre 3 (tipo SNMP agent)
  Nome:       GPON: walk de seriais
  Chave:      gpon.walk.sn
  SNMP OID:   walk[1.3.6.1.4.1.2011.6.128.1.1.2.43.1.3]
  Intervalo:  1h
  Histórico:  não guardar

O estado roda a cada 5 minutos porque é dele que sai o alarme de PON. O Rx muda devagar e pode rodar a cada 15 minutos. O serial só serve para descobrir ONUs novas e nomear os itens, então uma vez por hora basta. Separar as colunas em itens diferentes deixa cada uma com o seu intervalo.

Descoberta LLD por PON

O alarme mais útil é por porta PON, não por ONU. Para isso, crie uma regra de descoberta do tipo Dependent item, com mestre gpon.walk.run, e um passo de pré-processamento JavaScript que agrupa as linhas do walk por ifIndex:

var out = {};
value.split('\n').forEach(function (l) {
  var m = l.match(/\.46\.1\.15\.(\d+)\.\d+ = /);
  if (!m) return;
  var d = parseInt(m[1], 10) - 4194304000;
  out[m[1]] = '0/' + Math.floor(d / 8192) + '/' +
    Math.floor((d % 8192) / 256);
});
return JSON.stringify(Object.keys(out).map(function (k) {
  return {'{#IFINDEX}': k, '{#FSP}': out[k]};
}));

O script lê cada linha, extrai o ifIndex com uma expressão regular e calcula a posição com a mesma fórmula do índice. O resultado é uma lista com {#IFINDEX} e {#FSP} (por exemplo, 0/1/0) para cada porta que tem pelo menos uma ONU cadastrada. O motor JavaScript do Zabbix é ES5, por isso o código usa function e forEach.

Dentro dessa regra, crie dois protótipos de item dependentes, ambos com o mesmo mestre. O primeiro, pon.online[{#IFINDEX}], conta as ONUs online da porta:

var n = 0;
var re = /\.46\.1\.15\.{#IFINDEX}\.\d+ = INTEGER: 1$/;
value.split('\n').forEach(function (l) {
  if (re.test(l.trim())) n++;
});
return n;

O segundo, pon.total[{#IFINDEX}], conta todas as ONUs cadastradas na porta:

var n = 0;
var re = /\.46\.1\.15\.{#IFINDEX}\.\d+ = INTEGER: \d+$/;
value.split('\n').forEach(function (l) {
  if (re.test(l.trim())) n++;
});
return n;

O Zabbix substitui as macros LLD dentro do código JavaScript, então cada item criado procura só as linhas da sua porta. Os dois itens não fazem requisição à OLT: leem o texto que o mestre já trouxe.

Descoberta das ONUs e item de Rx

Para o sinal, crie outra regra dependente, agora com mestre gpon.walk.sn. No pré-processamento, o primeiro passo é SNMP walk to JSON com o campo {#SN} e o prefixo .1.3.6.1.4.1.2011.6.128.1.1.2.43.1.3. O segundo é um JavaScript que acrescenta a posição e limpa o serial:

var a = JSON.parse(value);
a.forEach(function (o) {
  var p = o['{#SNMPINDEX}'].split('.');
  var d = parseInt(p[0], 10) - 4194304000;
  o['{#FSP}'] = '0/' + Math.floor(d / 8192) + '/' +
    Math.floor((d % 8192) / 256);
  o['{#ONT}'] = p[1];
  o['{#SN}'] = o['{#SN}'].replace(/[^0-9A-Fa-f]/g, '');
});
return JSON.stringify(a);

O {#SNMPINDEX} é o sufixo do OID, no formato ifIndex.ontId. O script separa as duas partes, calcula o frame/slot/porta e remove os espaços do serial em hex. Se a sua OLT devolve o serial como texto, troque essa linha por uma conversão de cada caractere para dois dígitos hex, como o próprio CLI mostra o SN. O protótipo do Rx fica assim:

Protótipo de item (tipo Dependent item, mestre gpon.walk.rx)
  Nome:   ONU {#FSP} ONT {#ONT} ({#SN}): Rx
  Chave:  onu.rx[{#SNMPINDEX}]
  Tipo de informação: numérico (float), unidade dBm
  Pré-processamento:
    1. SNMP walk value: .1.3.6.1.4.1.2011.6.128.1.1.2.51.1.4.{#SNMPINDEX}
    2. JavaScript: return Math.abs(value) >= 2147483647 ? null : value;
    3. Custom multiplier: 0.01

O passo 1 pega, no texto do walk de Rx, a linha da ONU descoberta. O passo 2 descarta os sentinelas 2147483647 e -2147483648: devolver null no JavaScript faz o Zabbix ignorar o valor. O passo 3 converte centésimos em dBm.

Triggers: PON sem ONU online e Rx abaixo do limite

Com os itens prontos, os alarmes ficam simples. Os três protótipos de trigger abaixo usam o nome do template OLT Huawei GPON; troque pelo nome do seu. As quebras de linha são só para leitura: no campo Expressão, cole cada trigger numa linha só.

last(/OLT Huawei GPON/pon.online[{#IFINDEX}])=0
and last(/OLT Huawei GPON/pon.total[{#IFINDEX}])>0

last(/OLT Huawei GPON/pon.total[{#IFINDEX}])>={$PON.MIN.ONU}
and (last(/OLT Huawei GPON/pon.total[{#IFINDEX}])
- last(/OLT Huawei GPON/pon.online[{#IFINDEX}])) * 100
/ last(/OLT Huawei GPON/pon.total[{#IFINDEX}]) >= {$PON.OFF.PCT}

max(/OLT Huawei GPON/onu.rx[{#SNMPINDEX}],1h)<{$ONU.RX.MIN}

1. PON sem ONU online: nenhuma ONU online numa porta que tem ONUs cadastradas. É o quadro de tronco rompido, splitter primário ou módulo da porta. Severidade alta.
2. PON com muitas ONUs offline: em portas com pelo menos {$PON.MIN.ONU} ONUs, dispara quando o percentual offline passa de {$PON.OFF.PCT}. Em porta pequena, um limite percentual vira ruído: duas ONUs desligadas numa PON de oito já são 25%. Por isso, abaixo do mínimo, só o primeiro alarme vale.
3. Rx baixo: o maior valor de Rx da última hora ficou abaixo do limite. Usar max numa janela evita alarme por uma leitura ruim isolada.

As macros ficam no template, com valores que você ajusta por host:

{$PON.MIN.ONU}  = 10
{$PON.OFF.PCT}  = 10
{$ONU.RX.MIN}   = -27

Os valores seguem os limiares que eu uso na prática: 10% para PON com 10 ONUs ou mais, e -27 dBm como início de sinal degradado no Rx da ONU. Abaixo de -25 dBm eu já conto como sinal baixo nos relatórios, mas não como alarme. Confira a classe do módulo da porta, porque B+ e C+ têm sensibilidades diferentes. A tabela completa de faixas está no guia de valores ideais de sinal da ONU GPON.

Falta de energia não é rompimento

Quando falta energia num bairro, dezenas de ONUs caem juntas com dying-gasp e o alarme de PON percentual dispara. No meu sistema, ONUs com dying-gasp ficam fora da contagem de offline do alarme de PON, e a mensagem informa quantas foram ignoradas. No Zabbix, isso exige mais um walk, da coluna .46.1.24, e cruzar a causa com o estado. Lembre que a causa é a da última queda: só conte dying-gasp de ONU que está offline agora.

Traps de LOS e dying-gasp ao monitorar OLT Huawei

O polling de 5 minutos é o alarme confiável para monitorar OLT Huawei. Os traps servem para saber antes, no segundo em que a OLT gera o evento. No Zabbix, o caminho é o snmptrapd do net-snmp recebendo na porta 162 e um receptor gravando num arquivo que o servidor lê:

# /etc/snmp/snmptrapd.conf
authCommunity log,execute ZbxLeitura2026
traphandle default /bin/bash /usr/sbin/zabbix_trap_handler.sh

# /etc/zabbix/zabbix_server.conf
StartSNMPTrapper=1
SNMPTrapperFile=/tmp/zabbix_traps.tmp

O authCommunity faz o snmptrapd aceitar traps com a community configurada na OLT. O traphandle entrega cada trap ao script receptor em Bash do Zabbix, que grava no arquivo indicado em SNMPTrapperFile. O StartSNMPTrapper=1 liga o processo que lê esse arquivo. O Zabbix associa cada trap ao host pelo IP da interface SNMP.

No host, comece com um item snmptrap.fallback, que guarda todo trap que nenhum outro item pegou. Provoque um evento conhecido numa ONU de teste, como tirar a fibra ou a energia, e veja qual OID chega. Só então crie itens snmptrap["<OID>"] para os eventos que interessam. Não copie OIDs de trap de listas da internet sem ver o trap real chegar: o que a OLT manda depende da versão e dos alarmes habilitados.

Intervalos e carga na OLT

Este é o ponto que mais pesa quando o objetivo é monitorar OLT Huawei grande. Na minha medição numa MA5800 grande, o agente SNMP entregou cerca de 22 linhas por segundo, fixo. Aumentar o max-repetitions de 30 para 100, 200 ou 400 não mudou nada, e mexer em timeout e tentativas também não. Numa OLT com cerca de 7.700 ONUs, cada coluna levou perto de 6 minutos para ser percorrida. Na OLT de 1.950 ONUs a vazão foi um pouco maior, então meça a sua com o snmpbulkwalk e o comando time antes de fixar os intervalos.

A única alavanca é coletar menos colunas, ou coletar com menos frequência. Com 22 linhas por segundo como referência conservadora, a tabela abaixo dá um ponto de partida para os intervalos dos três itens mestre:

No Zabbix 7.0 o timeout é configurável por item. Um walk de vários minutos precisa de timeout compatível, e o campo Max repetition count da interface SNMP (padrão 10) controla o tamanho de cada bloco GETBULK. Como a vazão do agente não muda com ele, não adianta subir muito: a documentação avisa que valor alto demais pode estourar o timeout.

Se a OLT também é acessada por SSH para provisionamento e backup, como no script de backup da OLT Huawei MA5800, evite agendar os walks pesados no mesmo horário das rotinas de CLI.

Erros comuns ao monitorar OLT Huawei no Zabbix

• Um item SNMP por ONU com GET próprio. Aumenta muito as requisições e derruba a vazão do agente. Use walk e itens dependentes.
• Trigger por ONU offline. Gera centenas de alertas num rompimento de tronco. Alarme por PON e deixe a ONU para consulta.
• Não descartar o 2147483647. O gráfico de Rx ganha picos absurdos e as médias ficam erradas.
• Esquecer a divisão por 100. -2534 é -25,34 dBm.
• Ler a causa da queda como estado atual. Ela guarda a última queda. Cruze com o estado ou com a hora da última subida.
• Confiar em tabela pública de causas sem conferir. A numeração pode não bater com o seu firmware.
• Assumir a fórmula do índice em outro chassi. Confira o serial pelo índice calculado.
• Community de escrita no Zabbix. Monitoramento só lê.

Perguntas frequentes

Quais OIDs usar para monitorar OLT Huawei MA5800?

Os principais estão sob 1.3.6.1.4.1.2011.6.128.1.1.2: .46.1.15 para o estado da ONU, .51.1.4 para o Rx, .51.1.3 para o Tx e .43.1.3 para o serial. O índice de cada linha é o ifIndex da porta GPON seguido do ONT ID.

Por que o Rx aparece como 2147483647?

É o valor que a OLT devolve quando não há leitura, como em ONU offline ou sem diagnóstico óptico. Descarte esse valor no pré-processamento para não sujar gráficos e triggers.

Preciso dos arquivos MIB da Huawei no Zabbix?

Não. Com OIDs numéricos, o net-snmp e o Zabbix funcionam sem os arquivos MIB. Eles só ajudam a ler nomes em vez de números.

Qual intervalo de coleta usar numa OLT grande?

Depende do número de ONUs. Numa MA5800 grande, o agente entregou cerca de 22 linhas por segundo na minha medição, então uma OLT com 7.700 ONUs leva perto de 6 minutos por coluna. Nesse porte, use 10 a 15 minutos para o estado e intervalos maiores para Rx e serial.

Trap de LOS substitui o polling?

Não. Trap é UDP e pode se perder. Use o trap para saber rápido e o polling do estado para confirmar e disparar o alarme de PON.

Conclusão

Para monitorar OLT Huawei no Zabbix sem pesar a OLT nem afogar o NOC em alertas, colete pouco e derive muito: um walk por coluna, itens dependentes por PON e por ONU, alarme de PON em vez de alarme de ONU e trigger de sinal com janela. Respeite a vazão do agente SNMP ao escolher os intervalos, descarte o sentinela e trate a causa da queda como histórico.

Monitorar OLT Huawei mostra onde está o problema; quando o alarme de PON disparar, o próximo passo é o CLI. O roteiro de comandos e a leitura de cada causa de queda estão no guia de diagnóstico de ONU com LOS ou offline na OLT Huawei.