Resumo Executivo

Gabriel Pereira Amorim; Ugo Henrique Pereira da Silva

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

A arquitetura de software experimentou transformações profundas na última década, impulsionada pela necessidade de escalabilidade e agilidade em ambientes de alta disponibilidade. A partir de 2014, a divulgação de experiências de grandes corporações tecnológicas consolidou a transição do modelo monolítico para estruturas baseadas em microsserviços (Richardson, 2018). No modelo tradicional, a concentração de toda a lógica de negócio em uma unidade funcional única facilitava o desenvolvimento inicial, porém resultava em sistemas rígidos, de manutenção onerosa e com limitações severas de expansão. Em contrapartida, a abordagem de microsserviços propõe a decomposição da aplicação em pequenos serviços independentes que se comunicam via rede, permitindo que cada componente seja implantado, escalado e atualizado de forma autônoma (Newman, 2015). Essa mudança de paradigma não apenas otimiza o uso de recursos computacionais, mas também oferece liberdade tecnológica, permitindo que diferentes pilhas de software coexistam em um mesmo ecossistema para resolver problemas específicos.

A adoção dessa arquitetura distribuída responde diretamente às demandas por evolução contínua e processamento de grandes volumes de dados em tempo real. Sistemas modernos, concebidos como nativos em nuvem, exigem uma infraestrutura que suporte a elasticidade necessária para enfrentar picos de demanda sem comprometer a experiência do usuário final (Gomes et al., 2024). Entretanto, a descentralização introduz complexidades inerentes à comunicação entre serviços e à gestão do estado global do sistema. Enquanto em um monólito o rastreamento de uma falha ocorre dentro de um único processo, em um ambiente distribuído, uma única requisição pode transitar por dezenas de serviços, tornando a identificação de gargalos e erros uma tarefa significativamente mais árdua. Nesse contexto, a observabilidade emerge como um pilar fundamental para garantir a confiabilidade operacional, indo além do monitoramento passivo para oferecer uma compreensão profunda do comportamento interno das aplicações por meio de sinais externos.

A construção de uma estratégia de observabilidade eficaz fundamenta-se na correlação entre três pilares principais: métricas, logs e rastreamento distribuído. Métricas fornecem dados quantitativos sobre a saúde do sistema, como uso de memória e latência; logs oferecem registros detalhados de eventos específicos; e o rastreamento distribuído permite visualizar o fluxo completo de uma transação através das fronteiras dos serviços (Sharma et al., 2022). A integração desses elementos é essencial para lidar com falhas parciais e modos de erro implícitos que métricas isoladas não conseguem capturar. Para viabilizar essa estrutura sem incorrer em custos proibitivos de licenciamento, ferramentas de código aberto têm se consolidado como o padrão de mercado. Soluções como Prometheus para coleta de métricas, Grafana para visualização, Jaeger para rastreamento e o protocolo OpenTelemetry para instrumentação padronizada oferecem uma alternativa robusta e economicamente acessível para organizações de diversos portes.

O objetivo central desta análise consiste em validar a implementação de um ecossistema de monitoramento e observabilidade em microsserviços desenvolvidos com Node.js, utilizando exclusivamente ferramentas open source. A escolha pelo ambiente de execução Node.js justifica-se por sua ampla adoção no desenvolvimento de aplicações escaláveis e sua eficiência no tratamento de operações de entrada e saída não bloqueantes, características ideais para arquiteturas distribuídas. A investigação busca demonstrar que é possível atingir níveis elevados de visibilidade e resiliência, mesmo em projetos com restrições orçamentárias, ao integrar de forma estratégica tecnologias que democratizam o acesso a recursos avançados de engenharia de software. A justificativa reside na necessidade de mitigar o tempo médio de detecção e resolução de incidentes, garantindo que a complexidade dos microsserviços não se torne um impedimento para a sustentabilidade do negócio.

Para a condução do estudo, adotou-se uma abordagem experimental aplicada, fundamentada na criação de um ambiente controlado composto por cinco microsserviços independentes e um gateway de API. O desenvolvimento não focou na complexidade da lógica de negócio, mas sim na capacidade de integração e na viabilidade técnica da pilha de observabilidade. O ambiente de execução escolhido foi o Node.js, utilizando o framework NestJS para garantir uma organização modular e escalável. A estrutura foi composta por um API Gateway, responsável pelo roteamento e segurança; um Serviço de Autenticação, para gestão de credenciais e emissão de tokens JSON Web Token; um Serviço de Catálogo, encarregado das operações de banco de dados relacional; um Serviço de Pedidos, que orquestrava as transações; e um Serviço de Notificações, que processava eventos e mantinha o histórico de interações.

O API Gateway funcionou como o ponto único de entrada, implementando camadas de proteção por meio de guardas de segurança que validavam a autenticidade das requisições antes de encaminhá-las aos serviços internos. O Serviço de Autenticação assegurou a integridade do sistema ao gerenciar o ciclo de vida das sessões dos usuários. No Serviço de Catálogo, as operações de criação, leitura, atualização e exclusão foram conectadas a um banco de dados PostgreSQL, simulando um ambiente produtivo real. O Serviço de Pedidos atuou como o núcleo de coordenação, vinculando itens do catálogo e disparando eventos assíncronos para o Serviço de Notificações após a conclusão de cada transação. A comunicação entre todos esses componentes foi estabelecida por meio de chamadas REST, garantindo a interoperabilidade e a simplicidade na troca de mensagens.

A infraestrutura foi totalmente conteinerizada utilizando a tecnologia Docker, o que permitiu o isolamento de cada serviço em ambientes específicos, reduzindo interferências externas e garantindo a reprodutibilidade dos experimentos. Cada microsserviço, juntamente com as instâncias do banco de dados e as ferramentas de monitoramento, foi definido em arquivos Dockerfile e orquestrado via Docker Compose. Essa configuração possibilitou a criação de redes internas privadas, volumes para persistência de dados e a gestão centralizada de variáveis de ambiente. O ambiente experimental foi executado em um hardware com processador Apple M2 Pro e 16 GB de memória RAM, destinando nove núcleos de processamento e 12 GB de memória especificamente para a execução dos contêineres, assegurando que os testes de carga não fossem limitados por restrições físicas básicas.

A instrumentação do ambiente foi realizada através do OpenTelemetry Collector, que atuou como um pipeline centralizado para a recepção, processamento e exportação de dados. A configuração foi definida em um arquivo YAML, integrando as bibliotecas do OpenTelemetry diretamente ao código Node.js para a coleta automática de métricas e rastreios. Para o monitoramento quantitativo, utilizou-se o Prometheus, configurado para realizar a coleta sistemática de dados de desempenho em intervalos regulares. A visualização foi centralizada no Grafana, onde dashboards personalizados foram construídos para exibir métricas de saúde, uso de CPU, memória e comportamento das requisições HTTP. O rastreamento distribuído foi gerenciado pelo Jaeger, permitindo a análise detalhada do ciclo de vida das requisições entre os serviços, enquanto o Loki foi empregado para a agregação e consulta centralizada de logs, eliminando a necessidade de acesso direto aos logs individuais de cada contêiner.

A simulação de carga e os testes de estresse foram executados com a ferramenta Artillery, uma solução de código aberto construída em Node.js. Foram definidos cenários de teste em arquivos YAML que especificavam a intensidade das requisições, a duração dos ensaios e as rotas a serem atingidas. A análise experimental foi dividida em três cenários distintos para avaliar a robustez do sistema. O primeiro cenário, de operação normal, aplicou uma carga moderada de 20 requisições por segundo durante 30 minutos. O segundo cenário, de pico de carga, elevou a demanda para 200 requisições por segundo durante 20 minutos, testando os limites de escalabilidade. O terceiro cenário focou em falhas intencionais, onde interrupções controladas e injeção de latência de até um segundo foram introduzidas nos serviços de pedidos e catálogo para observar a capacidade de detecção e recuperação da infraestrutura de observabilidade.

As métricas de desempenho e confiabilidade foram coletadas e tratadas com estatística descritiva para garantir a precisão dos resultados. Os principais indicadores avaliados incluíram o tempo médio para detecção (MTTD), definido como o intervalo entre a ocorrência de uma falha e o disparo do alerta correspondente; o tempo médio para reparo (MTTR), que mediu o período necessário para o restabelecimento total do serviço após um incidente; e o overhead de desempenho, calculado pela diferença percentual na latência média entre o sistema com e sem a instrumentação ativa. Além disso, a taxa de erro real foi monitorada para identificar a proporção de requisições malsucedidas em relação ao volume total processado, utilizando os dados cruzados entre Prometheus, Jaeger e Loki para validar a consistência das informações coletadas durante os períodos de estresse.

A implementação dos cinco microsserviços independentes demonstrou que o isolamento de responsabilidades, embora aumente o esforço inicial de configuração, proporciona um domínio superior sobre o ecossistema tecnológico. A utilização do framework NestJS facilitou a manutenção do código e a integração com as bibliotecas de observabilidade, permitindo que a instrumentação fosse realizada de forma transparente. No cenário de operação normal, o sistema processou aproximadamente 107.981 requisições com uma taxa de erro de 0%. A latência média manteve-se estável, registrando 2,10 ms para operações de consulta e 5,92 ms para operações de cadastro. Esses valores são considerados excepcionalmente baixos para um ambiente distribuído, confirmando que a arquitetura proposta possui uma base sólida para o uso cotidiano, em conformidade com os princípios de modularidade e eficiência (Newman, 2015).

Durante a simulação de carga elevada, o sistema foi submetido a um volume massivo de aproximadamente 719.820 requisições. Mesmo sob esse estresse intenso, a arquitetura demonstrou uma resiliência notável, mantendo a taxa de erro em 0% e latências médias reduzidas, variando entre 1,30 ms e 2,44 ms para os diferentes endpoints. Esse comportamento evidencia a elasticidade dos microsserviços e a capacidade do Node.js em gerenciar altas taxas de transferência sem degradação perceptível de desempenho. A visibilidade fornecida pelas ferramentas open source foi crucial para validar que, sob demanda extrema, os recursos de hardware alocados foram utilizados de maneira otimizada, reforçando a premissa de que sistemas bem projetados podem sustentar picos de tráfego sem comprometer a disponibilidade (Gomes et al., 2024).

No cenário de falhas controladas, a injeção de indisponibilidade resultou em aproximadamente 36.000 requisições por rota, das quais uma pequena fração apresentou erros do tipo 5xx. O endpoint de autenticação registrou 74 falhas, representando 0,207% do total, enquanto os endpoints de catálogo apresentaram 128 falhas cada, totalizando 0,355%. Essas falhas foram diretamente correlacionadas às reinicializações intencionais dos serviços, permitindo que a infraestrutura de observabilidade demonstrasse sua eficácia. O tempo médio de detecção (MTTD) foi de apenas oito segundos, evidenciando a agilidade do Prometheus e do OpenTelemetry em identificar anomalias. O tempo médio de recuperação (MTTR) foi de 36 segundos, um intervalo considerado adequado para a restauração automática de contêineres em um ambiente orquestrado.

A análise do overhead de desempenho revelou que a instrumentação detalhada com ferramentas de código aberto gerou um impacto médio de apenas 3,2% na latência das requisições. Esse valor situa-se significativamente abaixo do limite de tolerância de 5% estabelecido para este estudo, provando que a coleta de métricas, logs e rastreios não compromete a viabilidade operacional das aplicações. Em sistemas de larga escala, a manutenção de um overhead reduzido é vital para evitar que a própria camada de observabilidade se torne um gargalo. A eficiência observada valida a escolha do OpenTelemetry como padrão de instrumentação, uma vez que sua arquitetura de processamento assíncrono minimiza a interferência no fluxo principal de execução do código.

Identificou-se, contudo, uma variação marginal entre o volume de requisições enviadas e o total registrado pelas ferramentas de monitoramento. Em cenários com mais de 240 mil requisições, algumas rotas apresentaram discrepâncias de dois a cinco registros. Esse fenômeno é comum em ambientes instrumentados e decorre do uso de buffers de exportação e processos de coleta que priorizam a performance em detrimento da precisão absoluta de cada evento individual. Tais variações representaram menos de 0,03% do volume total de dados, permanecendo dentro de limites aceitáveis para análises estatísticas e auditorias operacionais em sistemas distribuídos (Kandula et al., 2021). Essa característica reforça a necessidade de configurar adequadamente os intervalos de coleta para equilibrar a fidelidade dos dados com o consumo de recursos de rede e armazenamento.

A integração entre as ferramentas permitiu uma depuração eficiente durante os incidentes simulados. Enquanto o Prometheus alertava sobre o aumento na taxa de erros, o Jaeger possibilitava o rastreamento exato de quais requisições foram afetadas e em qual ponto da cadeia de chamadas a falha ocorreu. Simultaneamente, o Loki fornecia os logs detalhados dos contêineres no momento exato do erro, permitindo uma análise de causa raiz sem a necessidade de acessar manualmente cada componente da infraestrutura. Essa correlação entre os três pilares da observabilidade é o que diferencia um sistema resiliente de um sistema apenas monitorado, garantindo que as equipes de operação possuam as informações necessárias para agir com rapidez e precisão (Sharma et al., 2022).

Apesar dos benefícios técnicos e da economia direta com licenciamento, a adoção de uma pilha open source exige a consideração dos custos indiretos de infraestrutura e a curva de aprendizado das equipes. Em ambientes de produção de grande escala, o volume de dados gerado pela observabilidade pode representar entre 15% e 25% dos custos totais de infraestrutura, podendo atingir 30% em cenários críticos onde a retenção de dados por longos períodos é exigida (Majors, 2022). Para mitigar esses custos, técnicas como a amostragem de dados (sampling) tornam-se essenciais, permitindo que apenas uma parcela representativa das transações seja rastreada e armazenada, reduzindo o consumo de disco e processamento sem perder a relevância estatística para a tomada de decisão.

A comparação com soluções comerciais, como Datadog ou New Relic, destaca que, embora as ferramentas proprietárias ofereçam ambientes prontos e de fácil configuração, elas impõem uma dependência tecnológica conhecida como vendor lock-in. Essa situação limita a flexibilidade da organização e pode resultar em custos imprevisíveis à medida que o volume de dados cresce. A abordagem baseada em ferramentas de código aberto, embora demande maior esforço inicial de configuração e manutenção contínua, garante a soberania sobre os dados e a liberdade para adaptar a solução às necessidades específicas do projeto. A maturidade das comunidades em torno do Prometheus, Grafana e OpenTelemetry assegura que essas ferramentas continuem evoluindo e oferecendo suporte a novas tecnologias e padrões de mercado.

A robustez demonstrada nos testes de estresse e a precisão na detecção de falhas confirmam que a combinação de Node.js com uma pilha de observabilidade aberta é uma estratégia viável para sistemas modernos. A modularidade dos microsserviços, aliada a uma visibilidade profunda, permite que as organizações entreguem software com maior qualidade e confiança. A capacidade de recuperar serviços em menos de 40 segundos e detectar anomalias em menos de 10 segundos coloca essa solução em um patamar de excelência operacional compatível com as exigências de mercados competitivos. O estudo reforça que a observabilidade não deve ser vista como um custo adicional, mas como um investimento necessário para a sustentabilidade e resiliência de qualquer arquitetura distribuída contemporânea.

A experiência adquirida na configuração do OpenTelemetry Collector mostrou que a padronização da coleta de dados simplifica drasticamente a evolução do sistema. Ao adicionar novos microsserviços, a integração com a infraestrutura de monitoramento ocorre de forma quase automática, exigindo ajustes mínimos nos arquivos de configuração. Essa escalabilidade operacional é fundamental para empresas que adotam metodologias ágeis e ciclos de entrega contínua, onde a infraestrutura deve acompanhar a velocidade do desenvolvimento de novas funcionalidades. A democratização do acesso a essas ferramentas permite que mesmo pequenas equipes possam implementar práticas de engenharia de confiabilidade de sites (SRE) que antes eram restritas a grandes corporações.

Conclui-se que o objetivo foi atingido, uma vez que a implementação e a validação do sistema de monitoramento e observabilidade em microsserviços Node.js utilizando ferramentas open source demonstraram alta eficiência técnica e viabilidade econômica. Os resultados experimentais comprovaram que a integração entre Prometheus, Grafana, Jaeger, Loki e OpenTelemetry oferece uma visibilidade profunda e em tempo real, com um overhead de desempenho reduzido de apenas 3,2%, mantendo a estabilidade mesmo sob cargas extremas de 200 requisições por segundo. A arquitetura apresentou resiliência significativa, com tempos médios de detecção de falhas de oito segundos e recuperação em 36 segundos, validando a eficácia da solução para garantir a disponibilidade e a confiabilidade de aplicações distribuídas modernas sem a necessidade de investimentos vultosos em licenças proprietárias.

Referências Bibliográficas:

GOMES, F. A. de A.; GABRIEL, V.; ROCHA, L.; REGO, P.; TRINTA, F. A. M. Observabilidade de desempenho de arquiteturas monolíticas e microsserviços com OpenTelemetry. In: SEMINÁRIO INTEGRADO DE SOFTWARE E HARDWARE (SEMISH), 51., 2024, Brasília, DF, Brasil. Anais do LI Seminário Integrado de Software e Hardware (SEMISH 2024). Porto Alegre: Sociedade Brasileira de Computação, 2024. Disponível em: https://sol.sbc.org.br/index.php/semish/article/view/29361. Acesso em: 20 ago. 2025.

KANDULA, S. et al. Integrated observability for microservices. ACM Computing Surveys, v. 54, n. 5, p. 1-34, 2021. Disponível em: https://doi.org/10.1145/3446381. Acesso em: 20 ago. 2025.

MAJORS, C. How much should I spend on observability? Honeycomb, 2022. Disponível em: https://www.honeycomb.io/blog/how-much-should-i-spend-on-observability-pt1. Acesso em: 25 ago. 2025.

NEWMAN, S. Building microservices. Sebastopol, CA: O’Reilly Media, 2015.

RICHARDSON, C. Microservices patterns: with examples in Java. Shelter Island: Manning Publications, 2018.

SHARMA, A. et al. Distributed tracing and observability. Journal of Systems and Software, v. 192, p. 111123, 2022. Disponível em: https://doi.org/10.1016/j.jss.2022.111123. Acesso em: 20 ago. 2025.

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