Resumo Executivo

Yvson de Araujo Moura; Luciano Bérgamo

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

A crescente complexidade das infraestruturas de Tecnologia da Informação nas organizações modernas exige soluções eficientes e alternativas para monitoramento e gerenciamento em tempo real. O estilo tradicional de monitoramento, baseado em consultas periódicas conhecidas como polling, apresenta limitações significativas quanto à detecção de falhas, resiliência e degradação de desempenho, o que impacta diretamente a continuidade dos serviços. Segundo Turnbull (2016), o monitoramento refere-se ao conjunto de ferramentas e processos utilizados para medir e gerenciar sistemas de tecnologia da informação, permitindo extrair dados relevantes sobre as capacidades e níveis de uso dos sistemas, além de identificar potencialidades e limitações. Nesse cenário, a Arquitetura Orientada a Eventos, ou EDA, surge como uma abordagem alternativa e eficaz para permitir a detecção e resposta automatizada a incidentes em tempo real, otimizando a gestão de recursos de TI e prevenindo interrupções críticas. De acordo com Taylor (2009), a EDA possui a habilidade de detectar eventos e reagir de forma inteligente a eles, garantindo uma comunicação assíncrona e descentralizada que promove a escalabilidade e a resiliência do ambiente monitorado. O paradigma da EDA permite a reação automática a condições anômalas, como o aumento da latência de rede, falha de servidores ou superaquecimento de equipamentos, minimizando impactos operacionais. Para garantir que as métricas obtidas sejam rapidamente analisadas e utilizadas de forma proativa, a supervisão deve ser eficiente e tempestiva. O sistema Prometheus é frequentemente utilizado para coletar métricas de uso dos recursos, operando com um modelo de dados multidimensional baseado em séries temporais. No entanto, para o transporte eficiente de informações entre aplicações distribuídas, é necessário utilizar uma linguagem comum e regras claras. O RabbitMQ destaca-se como um agente de mensagens de código aberto que implementa o protocolo AMQP, permitindo a comunicação assíncrona entre aplicações por meio de filas, garantindo uma entrega confiável e flexível. A integração do RabbitMQ aos sistemas monitorados permite que dados relacionados aos recursos demandados sejam enviados como mensagens para o agente de monitoramento, que processa as informações assincronamente e decide a melhor forma de reagir.

A metodologia aplicada fundamenta-se em uma pesquisa de caráter exploratório, que busca proporcionar maior familiaridade com o problema para torná-lo mais explícito. Segundo Gil (2017), o delineamento da pesquisa ocorre no formato de estudo de caso, consistindo no estudo profundo e exaustivo de um fenômeno para permitir seu amplo conhecimento. A abordagem adota um caráter misto, integrando resultados quantitativos mensuráveis em unidades de desempenho com a análise qualitativa dos fenômenos observados. O processo metodológico envolveu o desenvolvimento, a implementação e a avaliação de um protótipo funcional de um agente de monitoramento de infraestrutura de TI baseado em EDA. Para estabelecer uma linha base de comparação, utilizou-se o método tradicional de polling através do Prometheus. No método tradicional, o servidor solicita periodicamente métricas de sistemas monitorados, como uso de CPU e memória, expondo esses dados por meio de um endpoint HTTP, geralmente definido como /metrics. O protótipo desenvolvido utiliza o protocolo AMQP versão 0-9-1, que é um protocolo binário projetado para suportar arquiteturas de mensagens escaláveis e flexíveis em ambientes heterogêneos (Aiyagari et al., 2008). O modelo AMQP opera sobre TCP/IP e utiliza um servidor intermediário para gerenciar filas e roteamento, permitindo que produtores e consumidores troquem mensagens de forma desacoplada. Segundo Gemirter et al. (2021), protocolos orientados a mensagens superam limitações do protocolo HTTP ao usar comunicação assíncrona, reduzindo o tamanho dos cabeçalhos e aumentando a velocidade de transmissão. No protótipo, as métricas são encapsuladas em eventos seguindo a especificação CloudEvents versão 1.0, que padroniza a descrição de eventos em ambientes de computação em nuvem. Cada evento inclui campos obrigatórios como identificador único, origem, tipo, tempo e a carga útil com os dados da métrica. A persistência dos dados no agente de monitoramento adota o padrão de event-sourcing, onde o estado do sistema é derivado da sequência de eventos armazenados em um banco de dados PostgreSQL. Conforme Khononov (2021), esses eventos armazenados sequencialmente tornam-se a fonte da verdade, garantindo consistência forte ao longo do tempo. O protótipo foi implementado em .NET 9, estruturado em quatro camadas lógicas: apresentação, aplicação, lógica de negócio e infraestrutura. A camada de apresentação lida com requisições HTTP e respostas em formato JSON, enquanto a camada de aplicação orquestra os fluxos de trabalho. A lógica de negócio encapsula as regras centrais do sistema e a infraestrutura gerencia o acesso a bancos de dados e a comunicação via RabbitMQ.

O cenário de teste de carga foi estruturado para simular diferentes níveis de utilização de CPU na aplicação monitorada durante 50 minutos. O experimento ocorreu em um ambiente controlado com uma máquina de 32 núcleos, 32 GB de RAM e sistema operacional Ubuntu 22.04. A primeira fase, denominada fase ociosa, durou cinco minutos e estabeleceu a linha base sem carga adicional. Seguiu-se a fase de estresse 1, com 10 minutos de processamento moderado de tarefas, e a fase sem estresse 1, com cinco minutos para recuperação do sistema. Esse ciclo foi repetido nas fases de estresse 2 e 3, intercaladas por períodos de recuperação, totalizando sete etapas sequenciais. Para a execução dos testes, utilizou-se a ferramenta Grafana k6, que permite testar a confiabilidade e o desempenho de aplicações ao criar cenários simulados de sobrecarga. Além do teste de carga geral, configurou-se um cenário específico de 20 minutos para avaliar o disparo de alertas. A regra de alerta foi definida para níveis de uso de CPU iguais ou acima de 30% por pelo menos cinco minutos. O protótipo EDA avaliou a média aritmética dos últimos cinco minutos a cada intervalo de 10 segundos, enquanto o Prometheus verificou a manutenção da condição após um estado pendente inicial. Um terceiro cenário envolveu o monitoramento concomitante de três aplicações distintas, identificadas como A, B e C, para demonstrar a capacidade do protótipo de lidar com múltiplas instâncias em tempo real. Durante todos os testes, as ferramentas tcpdump e Wireshark foram empregadas para interceptar e analisar os pacotes trafegados, permitindo a comparação precisa da quantidade de dados transferidos entre os métodos de polling e EDA.

Os resultados obtidos revelaram que tanto o protótipo baseado em EDA quanto o Prometheus foram eficazes em capturar o comportamento da aplicação. Na fase de estresse 1, o uso médio de CPU registrado pelo protótipo foi de 44,197%, enquanto o Prometheus registrou 43,665%, resultando em uma variação absoluta de apenas 0,532%. Na fase ociosa, os valores foram de 0,009% e 0,013%, respectivamente. Essas pequenas divergências decorrem dos métodos de cálculo e do desalinhamento temporal inerente às coletas, uma vez que as leituras de 10 segundos não ocorrem no mesmo exato instante. Os dados do Prometheus foram extraídos via linguagem PromQL utilizando a função rate em um intervalo de 20 segundos, normalizada pelo número de núcleos do ambiente. Já o protótipo calculou a métrica diretamente na aplicação monitorada e a transmitiu via RabbitMQ. A análise do tráfego de rede demonstrou uma vantagem significativa da arquitetura orientada a eventos. O Prometheus transferiu 36% mais dados que o protótipo EDA para a mesma métrica de CPU. Essa diferença é atribuída à sobrecarga dos cabeçalhos de requisição e resposta do protocolo HTTP, que exige dois pacotes para cada coleta, enquanto o protocolo AMQP utiliza um cabeçalho binário compacto e envia apenas uma mensagem unidirecional. Em um cenário onde todas as métricas padrão do pacote de monitoramento são consideradas, o volume total transferido pelo método de polling chegou a aproximadamente 12 MB, o que consome maior largura de banda e espaço de armazenamento. O uso da EDA permite uma granularidade superior, possibilitando configurar a aplicação para enviar apenas os registros de métricas que sejam realmente úteis para o negócio.

No cenário de disparo de alertas, o protótipo EDA acionou o alerta no tempo de 331,5 segundos, momento em que a média aritmética dos últimos cinco minutos atingiu o patamar de 30%. O Prometheus emitiu um alerta de estado pendente aos 183 segundos e o alerta definitivo de disparo aos 484 segundos, após confirmar a manutenção da condição pelo período estipulado. Embora os mecanismos de emissão sejam distintos, ambos validaram a eficácia da captura de dados para vigilância da aplicação. O teste com múltiplas aplicações demonstrou que o protótipo consegue associar corretamente cada evento ao seu serviço de origem através do campo source do CloudEvents, mantendo medições consistentes para as instâncias A, B e C simultaneamente. A escalabilidade do modelo proposto mostrou-se superior, pois o agente de monitoramento atua de forma passiva no recebimento de dados, processando-os de forma independente através do serviço de mensagens. Isso contrasta com o modelo de polling, onde o servidor de monitoramento deve gerenciar ativamente as conexões e solicitações para cada sistema monitorado, o que pode gerar gargalos em ambientes de larga escala. O uso do padrão event-sourcing facilitou a rastreabilidade completa das métricas e a reconstrução de estados históricos, sendo uma solução robusta para auditoria. Métodos como ApplyEvent foram utilizados para atualizar o estado dos agregados, enquanto o AppendEvent adicionou novos registros ao fluxo de dados de forma contínua.

A discussão dos resultados indica que a implementação da EDA no monitoramento de infraestrutura de TI atende às necessidades de flexibilidade e resiliência exigidas por sistemas modernos. A redução de 36% no tráfego de rede é um dado quantitativo relevante para infraestruturas com restrições de banda ou alto custo de transferência de dados. O desacoplamento proporcionado pelo RabbitMQ garante que, mesmo em momentos de indisponibilidade temporária do agente de monitoramento, as métricas não sejam perdidas, pois permanecem persistidas nas filas até que o processamento seja retomado. No método de polling, qualquer queda do servidor de monitoramento resulta em lacunas imediatas nos dados históricos, pois as consultas não realizadas não podem ser recuperadas retroativamente. Entretanto, observou-se que a EDA não reduziu o tempo de detecção de incidentes em comparação ao polling, uma vez que ambos operaram com intervalos de coleta de 10 segundos. As diferenças de tempo de envio situam-se na escala de milissegundos, sendo insignificantes para a finalidade de monitoramento de infraestrutura. A complexidade de implementação da EDA é superior à do polling, exigindo a configuração de brokers de mensagens e a padronização de eventos, mas os benefícios em termos de eficiência e escalabilidade justificam o investimento tecnológico. A utilização de padrões abertos como AMQP e CloudEvents garante a interoperabilidade entre diferentes plataformas e linguagens, permitindo que o protótipo seja integrado a diversos ecossistemas de software.

A aplicação do padrão de agregados, conforme descrito por Khononov (2021), permitiu manter a consistência dos dados durante todo o ciclo de vida das entidades monitoradas. Cada registro na tabela de eventos do PostgreSQL possui identificadores únicos para o evento e para o agregado, além de controle de versão para gerenciar a concorrência. Essa estrutura de dados em formato JSONB oferece flexibilidade para armazenar diferentes tipos de métricas sem a necessidade de alterações constantes no esquema do banco de dados. A análise crítica dos testes de estresse confirmou que o protótipo é capaz de lidar com a volatilidade das métricas de CPU, apresentando uma correlação alta com os dados coletados pela ferramenta de referência. A capacidade de reação inteligente mencionada por Taylor (2009) foi comprovada através da automação dos alertas, que funcionaram como gatilhos para a identificação de comportamentos anômalos. Para trabalhos futuros, a exploração de mecanismos de compressão de dados e a análise de outros protocolos como MQTT ou Apache Kafka podem trazer otimizações adicionais. A investigação de bancos de dados orientados especificamente a eventos também pode aprimorar a persistência em cenários de altíssima escala. A viabilidade da arquitetura orientada a eventos para o monitoramento de TI foi demonstrada através da implementação bem-sucedida do protótipo, que cumpriu os requisitos de automação e eficiência propostos.

Conclui-se que o objetivo foi atingido, demonstrando que a Arquitetura Orientada a Eventos é uma alternativa viável e eficiente para o monitoramento de infraestrutura de TI em comparação ao método tradicional de polling. O protótipo funcional desenvolvido comprovou que o uso de protocolos assíncronos como o AMQP reduz significativamente a sobrecarga de rede, transferindo 36% menos dados, ao mesmo tempo em que mantém a precisão das métricas coletadas. A escalabilidade e o desacoplamento proporcionados pela EDA permitem que o sistema suporte múltiplas aplicações simultâneas e garanta a integridade dos dados através de mecanismos de persistência como o event-sourcing. Embora a complexidade de implementação seja maior, as vantagens em termos de resiliência, economia de recursos de rede e flexibilidade na configuração de métricas tornam essa abordagem superior para ambientes distribuídos modernos que exigem alta disponibilidade e respostas rápidas a incidentes.

Referências Bibliográficas:

Aiyagari, S.; Richardson, A.; Radestock, M.; O’Hara, J.; et al. 2008. Advanced Message Queuing Protocol (AMQP) Specification, Version 0-9-1. Disponível em: https://www.rabbitmq.com/resources/specs/amqp0-9-1.pdf. Acesso em: 10 junho 2025.

Gemirter, C. B., Şenturca, Ç.; Baydere, Ş. 2021. A Comparative Evaluation of AMQP, MQTT and HTTP Protocols Using Real-Time Public Smart City Data. 6th International Conference on Computer Science and Engineering (UBMK): 542-547.

Gil, A. C. 2017. Como Elaborar Projetos de Pesquisa. 6ed. Atlas, São Paulo, SP, Brasil.

Khononov, Vlad. 2021. Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. Sebastopol: O’Reilly Media.

Taylor, H. et al. 2009. Event-Driven Architecture: How SOA Enables the Real-Time Enterprise. 1. ed. [S.l.]: Addison-Wesley Professional.

Turnbull, James. 2016. The art of monitoring. Mumbai: Shroff Publishers.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy