Resumo

  • Um exemplo apresentado na LACNIC 46 estima 23 minutos até a primeira reclamação e mais 67 de análise manual após uma queda de 14 segundos.
  • A arquitetura proposta coleta syslog, dados da API RouterOS v7, sessões RADIUS e topologia dentro do ISP e oferece buscas por meio de SQL somente leitura.

O evento acaba em 14 segundos. A história, no entanto, pode ocupar uma tarde inteira. Esse é o descompasso que dois engenheiros levaram à sessão do Internet Measurement Working Group, durante a LACNIC 46 · LACNOG 2026, em Mendoza. No roteiro da apresentação, a primeira reclamação chega 23 minutos depois da queda; a equipe ainda gasta 67 minutos procurando a causa, de roteador em roteador.

Joaquín Tadeo Riedmaier e Santiago Agustín Zualet, da Faculdade de Engenharia da Universidad Nacional de Misiones, descrevem a sequência como uma estimativa típica para um incidente crítico. Os horários são ilustrativos. A meta do projeto é reduzir o diagnóstico de cerca de 90 para 18 minutos por evento crítico. O problema que a proposta tenta resolver aparece antes da inteligência artificial: os registros ficam espalhados, o ruído esconde o sinal e a equipe só começa a busca quando o cliente percebe o serviço ruim.

O desenho concentra os dados numa máquina Docker hospedada pelo próprio provedor. Um caminho empurra eventos pelo syslog UDP: erros, mudanças de estado, flapping de enlace e quedas PPPoE/RADIUS. Outro consulta a API REST do RouterOS v7 para ler tráfego, erros e descartes por interface ou VLAN, CPU, memória, ARP e connection tracking. O estado das sessões RADIUS por NAS acrescenta a parte que interessa ao atendimento: quais usuários ou sessões acompanharam a falha do enlace.

Django recebe o syslog e consulta a API; Python filtra ruído, normaliza e elimina eventos duplicados, além de avaliar limiares; PostgreSQL guarda as vistas que alimentam o diagnóstico. A proposta então usa um modelo local para converter perguntas comuns em SQL. As vistas são achatadas para reduzir junções e o usuário do banco só pode executar SELECT. O material diz que o modelo foi testado em um equipamento com 32 GB de RAM, mas não informa qual modelo, qual carga ou quanto tempo levou para responder.

Uma tela de exemplo pergunta quais roteadores tiveram queda nas últimas quatro horas. A resposta atribui sete eventos na ether2 do NAS 6 e 23 sessões PPPoE afetadas. A própria tela chama aquilo de exemplo ilustrativo. Outra página sincroniza erros de camada 2/3, connection tracking, RADIUS e PPPoE às 12h04, e sugere uma falha física; o material identifica o caso como simulado, não como medição de campo. São cenas para explicar a forma do sistema, não registros de clientes atendidos.

A automação está dividida em alerta e investigação. Os limiares devem avisar antes da reclamação; o painel e a pergunta em linguagem natural ajudam a reconstruir o que ocorreu. O modelo não conserta o enlace e não é a prova do incidente: é uma interface para consultar o que foi registrado. Se o syslog não guardar a queda, o intervalo de consulta da API passar por cima dos 14 segundos, ou os relógios dos equipamentos divergirem, a resposta bem escrita não recupera a sequência perdida.

Os autores chamam os 90 minutos de estimativa e os 18 de impacto esperado, sem publicar amostra de incidentes de um ISP, intervalo de coleta, tempos de diagnóstico antes e depois, falsos positivos ou método para medir a meta de ≥95 %; um piloto com esses resultados discriminados por evento mudaria a avaliação.

Essa lacuna aponta uma próxima entrega concreta. O provedor precisa ver quando cada registro chegou, que alerta apareceu, quando o técnico assumiu o caso e em que momento confirmou a causa. Com isso, a equipe pode decidir se o sistema realmente devolve tempo ou apenas apresenta uma interface mais agradável para o mesmo trabalho manual.

Fontes: agenda oficial da LACNIC 46; apresentação original do IMWG.