Monitoramento POP/Localidade

Fase I - Estudo

Título da Ideia

1ª etapa: Migração da Automação - Monitoramento POP/Localidade.

2ª etapa: Aplicação de Inteligência Artificial (IA) para identificar a qual trecho de falha um alarme pertence.

Objetivos

O projeto tem como objetivo auxiliar a área de Alarmística do COR - Centro de Operação de Redes da Algar Telecom no processo de migração da automação do monitoramento de estação (POP) e localidade. Em termos mais detalhados, por conta de uma sobrecarga no Zabbix - ferramenta de software usada para monitorar redes e servidores -, há importância em implementar e refinar a automação em questão no Netcool. Tal importância se dá por conta de muitos alarmes acionarem quando há uma queda ou isolamento, dessa forma, com o monitoramento os alarmes são agrupados e é gerado um alarme sintético que identifica o problema. Com disso, além da diminuição da sobrecarga, o refinamento da automação poderá gerar mais reduções de esforço e de tempo de análise por parte dos analistas durante a investigação das falhas, bem como o tempo de tratamento.

Também com propósito de automação, a segunda etapa abrange um recorte mais disruptivo, porque visa o início de aplicações com IA no COR para manter atualizados o agrupamento e a categorização dos alarmes da rede de acordo com o trecho de falha a que eles pertencem. Essa solução já estava em andamento, com a aplicação de treinamento de IA com Random Forest, pelo COR (com a Gessyca Carneiro Bernardes) no momento em que o BIRD começou a atuar. Entretanto, foram identificados alguns enviesamentos no treinamento e dificultadores provenientes da vivacidade da rede, como a dinamicidade necessária na identificação de novos trechos e a possibilidade de reflexos em localidades um pouco mais distantes do trecho da falha. Dado esse cenário, o direcionamento é a aplicação de técnicas de treinamento de clusterização.

Conceito

Contexto inserido

Este projeto está inserido no contexto de automação do COR - Centro de Operação de Redes da Algar Telecom, mais especificamente na área de alarmes da rede GPON.

Projetos e pesquisas relacionados

Anteriormente a este, houve uma pesquisa da própria área de P&D do Brain:

• Alarmística COR

Possibilidades de evolução

Feita a migração dessa automação, deve ser avaliada a sobrecarga inicialmente apontada pelo COR. Em caso da necessidade de uma maior redução, possivelmente a migração e criação de outras automações poderão ser analisadas. Além disso, de maneira prospectiva, pode haver viabilidade de implementações que tragam novos mecanismos que aprimorem o monitoramento de estação e localidade.

O caminho que envolve a solução com IA, abre novas possibilidades inovadoras de integrações e automações no COR.

Características 

Na primeira etapa deste projeto, estarão presentes alguns assuntos, ferramentas e mecanismos, principalmente:

• Topologias de rede
• NodeRed
• Netcool

• Netcool impact

• JavaScript

Na segunda etapa, além das características da rede, estarão presentes:

• Técnicas de treinamento de IA

• Categorização (Random Forest)
• Clusterização (DBSCAN e Agglomerative Hierarchical Clustering)

Requisitos funcionais (RF) e não funcionais (RNF)

• RF: Por se tratar de uma automação, os requisitos funcionais envolverão tudo aquilo que é responsabilidade do sistema fazer para que a automação funcione.
  • Obter alarmes de POP e Localidade.
  • Descobrir POPs e localidades caídas.
  • Diagnosticar a queda (caracterizar, enriquecer, se trata uma queda total ou parcial).
  • Criar o alarme sintético no banco.
  • Disponibilizar os diagnósticos para os analistas.
• RNF: Os requisitos não funcionais são um pouco mais abstratos de serem identificados, visto que a aplicação é construída dentro do ambiente na rede Algar. Sendo assim, alguns fatores, como de segurança e disponibilidade já são providos.
  • Tempo de resposta e velocidade (?)
  • Volume de alarmes (?)
  • Usabilidade: a utilização da aplicação em si é automática, o que fator neste tópico é referente à visualização das mensagens que vão para a tela dos analistas.
    • Estrutura intermediária (atualizações nas tabelas para disponibilizar o diagnóstico nos telões)
  • Para possibilitar o desenvolvimento, são necessários os acessos Algar, bem como acesso à VPN.
  • NodeRed, Netcool Impact, JavaScript, SQL

Atribuições 

Na primeira etapa deste projeto, cabe ao Brain:

• Auxiliar no desenvolvimento e revisão, além de aprimorar:
  • Os fluxos no NodeRed
  • As políticas e os serviços no Impact

Estudo Dirigido

• Inicialmente, além de acompanhar o Caio com proximidade, foi importante assistir alguns vídeos para obter familiaridade com o NodeRed [1]
• Analisar os fluxos dessa automação no NodeRed, que já estavam sendo desenvolvidos pelo COR [2]
• Documentação do NodeRed [3]
• Canal do YouTube do NodeRed [4]

Fase II - Ensino

Conteúdo

Desenvolva um conteúdo que possa transmitir o conhecimento adquirido para outros
Crie um material (Wiki, PDF, PPT, ...) que possa ser armazenado e facilmente atualizável

Apresentação

Apresente ao grupo (reunião, EAD, Blog, ...)
Publique aqui

Metodologia

Descrevas as metodologias usadas. Alguns exemplos:

Estratégia de Job Rotation
Estudos básicos para conhecimento do potencial
Estudos básicos para entendimento sobre o problema
Estudos para dar base aos pesquisadores
Benchmarking com empresas estrangeiras 
Aceleradoras de empresas
Adoção de novas tecnologias
Utilização da proposta de soluções Open-source
Priorização no desenvolvimento interno
Foco na não dependência de fornecedores
Prática de formação dos talentos necessários 

Hipóteses

 Que questões envolvem a pesquisa? 
O que se espera provar?
O que se espera como resultado?
Explicações e argumentos que subsidiem a investigação em curso

Fase III - Exemplo de Caso de Negócio

Product Backlog

Descreva os requisitos deste projeto

Benefícios para quem for oferecer esta solução

    Descrever em tópicos os benefícios que uma pessoa ou uma empresa podem obter: ganhos, receitas, novos negócios, novos produtos, novas parcerias

Benefícios para o usuário

    Descrever em tópicos os benefícios para os usuários desta solução.
    Pode se inspirar no Canvas.

Direcionadores chave para esta iniciativa

    Descrever em tópicos o que esta iniciativa pode proporcionar

Possíveis modelos de negócios

    Descrever em tópicos os possíveis modelos de negócios

Business Case

    Descrever um exemplo de negócio que permita avaliar a solução comercialmente

Alinhamento com Lei do Bem

• Projeto possui algum elemento tecnologicamente novo ou inovador?

Elemento tecnologicamente novo ou inovador pode ser entendimento como o avanço tecnológico pretendido pelo projeto, ou a hipótese que está sendo testada

• Projeto possui barreira ou desafio tecnológico superável?

Barreira ou desafio tecnológico superável pode ser entendido como aquilo que dificulta o atingimento do avanço tecnológico pretendido, ou dificulta a comprovação da hipótese

• Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico?

Metodologia/método para superação da barreira ou desafio tecnológico pode ser entendido como aqueles atividades que foram realizadas para superação da barreira ou do desafio tecnológico existente no projeto

• Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?

Se sim, o desenvolvimento tecnológico é executado por associado ou por alguma empresa terceira? qual o nome da empresa? 
Anexar cópia do contrato

Fase IV - Protótipo orientado ao Negócio

Escopo

Explique o escopo deste protótipo

Limitações

Informe sobre as limitações técnicas, comerciais, operacionais, recursos, etc.

PoC

Desenvolva um PoC (Proof of Concept)

Privacidade (LGPD)

• Avaliar condições referentes à Lei Geral de Proteção de Dados

Detalhamento Técnico

Descreva especificamente os aspectos técnicos desta pesquisa

Histórico

• 21/03/2024:
  • Kick off: Caio Cesar Oliveira Rabelo:
    • 1. Escopo: alarmes de toda a rede (IP, exemplo, acesso, agregação e backbone). Alarmes de indisponibilidade nos 3 subdomínios. Em alguns casos, o site inteiro está fora do ar (energia, temporal) gera um monte de alarme de indisponibilidade. Foi feito um monitoramento de POPs para agregar todos os alarmes num só. A ideia é agregar todos os alarmes de site de uma localidade. Objetivo: tratar rápido a falha. Foi feito uma 1a implementação no Zabbix com baixa performance. A ideia é migrar para o Netcool criando um alarme sintético. Fazer pra site e localidade.
    • 2. Responsável: Caio Cesar e Elton
    • 3. Frequência dos encontros: Weekly 5a tarde
    • 4. Ferramentas: Netcool, Netcool Impact, NodeRed, Javascript e IPL => Material a ser enviado pelo COR
    • 5. Entrega final: Temos reuniões planejadas para apresentação do status do projeto em VMOs, Conselhos e momentos específicos.

• 22/03/2024
  • Reunião com olhar técnico (bastante introdutório, porém específico sobre o projeto de monitoramento) com Caio e Elton.
    • Ênfase principalmente sobre as plataformas/ferramentas (NodeRed, Netcool/Impact, Inventário Digital) que acessam bancos de dados que já estão estruturados.
    • Impact => Políticas e Serviços -> Serviços acionam políticas.
  • Relacionado diretamente ao projeto, inicialmente, para monitoramento de POPs, os alarmes de ICMP são identificados. Em seguida, é feito o enriquecimento, que é acompanhado por status (enrichpop, enriched, status de alarme sintético). Por fim, é possível obter um diagnóstico (ou não) com base nos dados analisados.
• 25/03/2024
  • Acompanhando remotamente o Caio, Elton e equipe a solucionar problemas reais em alarmes de estação.
  • Encontrar amanhã no CA.
• 26/03/2024
  • Encontro de manhã e de tarde no CA. Desenvolvemos em cima do código no Impact e NodeRed.
    • A estrutura geral está pronta e o fluxo no NodeRed montado, entretanto há bugs a serem solucionados e melhorias a serem feitas nos códigos das políticas (Impact) e em algumas buscas SQL (NodeRed).
    • Serviços já foram criados tanto para POPs quanto Localidades.
• 28/03/2024
  • Ainda não tendo a VPN na máquina, a continuidade do estudo está sendo dada pela análise do fluxo estruturado no NodeRed.
• 08/04/2024
  • Atualização sobre impedimento: sigo sem a VPN, então sigo estudando alguns tópicos e fluxos, entretanto o desenvolvimento (codificações) segue por parte do COR.
• 15/04/2024
  • Obtenção da VPN. Entretanto, sem os acessos Algar (IP Fixo e Firewall) necessários para acessar o ambiente de desenvolvimento do Nodered do COR.
• 07/05/2024
  • Obtenção dos acessos: IP Fixo e Firewall. Até o momento sem outros impedimentos, o desenvolvimento agora também pode ser feito por parte do Brain.
• 15/05/2024
  • Reunião para dar direcionamento ao início das atividades no NodeRed por parte do Brain.
    • Transferir o fluxo do ambiente produtivo para o amb. de homologação, realizando as devidas trocas de apontamentos.
    • Aprimoramentos no fluxo inicialmente desenvolvido pelo COR.
  • Impedimento encontrado: o ambiente de homologação precisará ser criado novamente (COR).
• 17/05/2024
  • Ambiente de homologação criado, o acesso deu certo, mas o NodeRed deu problema com os botões dos injects e dos debugs, o que impede a transferência e teste do fluxo produtivo dentro do amb. de homologação.
• 28/05/2024
  • Reunião de alinhamento com os especialistas do COR, na qual foi concluído que é mais viável a realocação dos pesquisadores a outra contribuição.
• 29/05/2024
  • Primeira reunião sobre a realocação, presencialmente no CA com Luigi, Luiz, Caio, Gessyca e Helen.
    • Direcionamento para contribuição envolvendo IA nos processos de análise de identificação do trecho afetado e agrupamento dos alarmes.
• 03/06/2024
  • Reunião com Gessyca: Avaliação dos recursos necessários para executar o código criado
  • LN: Definir se já consegue colaborar no desenvolvimento da solução ou se precisa de alguma formação
• 06/06/2024
  • Luigi conseguiu rodar os códigos em sua máquina do Brain
• 07/06/2024
  • Reunião presencial Gessyca e Luigi para dar continuidade ao trabalho, entretanto foram identificados erros de padronização de entrada
• 10/06/2024
  • Com uma base de dados um pouco maior, a máquina do Brain apresentou problema
  • numpy.core._exceptions._ArrayMemoryError: Unable to allocate 191. MiB for an array with shape (24982125,) and data type float64
• 17/06/2024
  • Outras máquinas foram testadas, entretanto o problema realmente se dá na disponibilidade de memória RAM
  • Algumas possibilidades estão sendo avaliadas: spark, memory mapping e fracionamento do arquivo
• 20/06/2024
  • Alguns testes com spark foram realizados, mas sem muito sucesso, apenas obtivemos melhor desempenho do código. Rodou em 91s, antes estava entre 106s e 108s
  • O tipo de arquivo que armazena o treinamento (joblib) não pode ser dividido. Começamos a ver sobre Pickle, mas ainda estamos inconclusivos
• 25/06/2024
  • Memory mapping resolveu a questão do armazenamento do joblib, por enquanto foi suspendida a necessidade de uma VM com mais RAM
• 26/06/2024
  • Testes com a database menor para conclusão e comparativo das soluções com mmap (mode: read only) e sem (mode: none). Os resultados foram iguais.
  • Continuidade na implementação do Spark para paralelismo e melhor desempenho
• Até o final de Julho, ocorreram várias reuniões entre Luigi, Gessyca e Davi Lacerda sobre como os dados estavam realmente afetando o treinamento e concluiu-se que o treinamento estava muito enviesado. Foi marcada uma reunião com o COR para entender quais parâmetros realmente afetam na obtenção da saída
• 01/08/2024
  • Reunião com COR mencionada acima
  • A conclusão foi que os parâmetros que fariam mais sentido seriam: NENAME, SUMMARY, ALARMEDRESOURCE, LOCATION e COLLECTIONFIRST (essa última para obtenção do "normalized_timestamp" que relaciona alarmes dentro de um intervalo de 20 minutos)
• 08/08/2024
  • Foi percebido que o "normalized_timestamp" enviesa o treinamento, visto que em produção o timestamp será completamente diferente e não entenderá a correlação com o que foi aprendido
• 14/08/2024
  • Reunião de Luigi e Gessyca com participação de Rodrigo Silva Peres e Pedro Henrique Araujo da Silva
  • Rodrigo irá trazer até 19/08 as conclusões que obtiver, bem como direcionamentos e materiais
  • Luigi e Gessyca irão aplicar "feature importance" para entender o peso de cada coluna nos outputs
• 23/08/2024
  • Reunião com REME - Remodelando sua Empresa com Matemática e Estatística do IME - Instituto de Matemática e Estatística
  • Luiz e Luigi apresentaram o Brain, Bird e, de forma geral, as situações problema da pesquisa
  • Houve interesse de ambas partes em assinar um NDA para compartilhamento de mais informações, como detalhes da rede e a database que está sendo usada para treinamento da IA
  • A partir dessa reunião, está sendo alinhado com o COR para mantê-los informados dessa parceria, principalmente para assegurar o compartilhamento de dados que não sejam sensíveis
• 28/08/2024
  • Monitoramento POP - Retorno do Rodrigo pós reunião
• 26/09/2024
  • O algoritmo com Agglomerative Clustering foi implementado, testado e não obteve bons resultados
  • Foi conversado com a Helen Cristina, SCRUM do COR, obtivemos a informação de que o COR está reavaliando toda a arquitetura de soluções
  • O andamento a partir disso será aprensentar/alinhar tudo o que já foi feito com os especialistas, para depois tomar decisões de próximos passos com o diretor

Pesquisadores

• Luigi Negrini (BIRD Brain)
• Lucas Resende Gomes (BIRD Brain)
• Caio Cesar Oliveira Rabelo (COR)
• Elton Soares Silva (COR)
• Gessyca Carneiro Bernardes (COR)