Henrique Annicchino Mello de Freitas; Jorge Valverde-Rebaza

DOI: 10.22167/2675-6528-202600888

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

Resumo

A crescente adoção de arquiteturas em nuvem, conteinerização e microsserviços ampliou a complexidade operacional de sistemas distribuídos, reforçando a necessidade de observabilidade. O estudo objetivou comparar Datadog, Grafana/Prometheus e Elastic Stack em ambientes monolíticos e de microsserviços, sob quatro cenários de carga e dois modos de execução (com e sem instrumentação). Para isso, consolidaram-se 240 execuções válidas, e a análise experimental considerou métricas de latência, *throughput*, erro, CPU e memória, complementadas por campanhas de validação com APM para observação de falhas induzidas. O tratamento quantitativo empregou testes de normalidade, ANOVA ou Kruskal-Wallis e cálculo de tamanho de efeito. Os resultados indicaram diferenças estatisticamente significativas entre as ferramentas em 91 de 144 comparações, com maior consistência nas métricas de memória e efeitos recorrentes em latência e *throughput*. Um *ranking* ponderado, calculado a partir das médias normalizadas, posicionou Grafana/Prometheus em primeiro lugar, seguido por Datadog e Elastic Stack. As campanhas de APM evidenciaram falhas induzidas nas três *stacks* avaliadas, com aumento de latência e transações com falha. Concluiu-se que *stacks* distintas introduziram *overheads* operacionais diferentes, e essa variação dependeu do contexto experimental, especialmente da arquitetura, do cenário de carga e do modo de execução. As limitações incluíram o tamanho amostral reduzido por grupo e a dependência temporal do ambiente SaaS do Datadog, mas a pesquisa ofereceu evidências comparativas válidas dentro do recorte metodológico estabelecido.

Palavras-chave: benchmarking; instrumentação; observabilidade; OpenTelemetry; telemetria.

1. Introdução

A evolução das arquiteturas de software, impulsionada pela adoção massiva de ambientes em nuvem, conteinerização e microsserviços, transformou radicalmente o panorama do desenvolvimento e da operação de sistemas. Essa transição, embora traga benefícios como escalabilidade e resiliência, introduziu uma complexidade operacional sem precedentes. A variabilidade inerente a sistemas distribuídos, a heterogeneidade tecnológica e a dificuldade em reconstruir a cadeia causal de um problema em produção tornaram as abordagens tradicionais de monitoramento insuficientes. Nesse contexto, a observabilidade emergiu como uma prática fundamental para correlacionar métricas, *logs* e *traces* de forma integrada, visando reduzir o tempo de diagnóstico e apoiar decisões de engenharia baseadas em evidências. Trabalhos recentes, como os de Volpert et al. (2023), destacam que os requisitos de monitoramento evoluíram com o avanço do paradigma *cloud-native*, exigindo *pipelines* flexíveis, instrumentação consistente e maior capacidade de correlação entre fontes distintas de telemetria.

A observabilidade, em sua essência, baseia-se na coleta e análise de três pilares de telemetria: métricas, *logs* e *traces*. Métricas fornecem dados quantitativos sobre o estado do sistema; *logs* registram eventos discretos; e *traces* mapeiam o fluxo de uma requisição através de múltiplos serviços. Em arquiteturas de microsserviços, a dificuldade de rastrear falhas cresceu exponencialmente com o aumento das dependências entre serviços, a fragmentação dos *logs* e a natureza dinâmica das rotas de execução. O uso de *distributed tracing* consolidou-se como um dos mecanismos mais promissores para reconstruir caminhos de chamadas e apoiar a detecção de falhas em tempo de execução (Mazraemolla e Rasoolzadegan, 2024). Pesquisas atuais exploram a busca por *tracing* transparente e de baixo *overhead* em arquiteturas baseadas em Node.js (Kabamba, Khouzam e Dagenais, 2024) e estratégias de reconstrução de *traces* sem modificação da aplicação, voltadas a ambientes de microsserviços complexos (Ashok et al., 2024). Em paralelo, abordagens mais recentes exploram o uso conjunto de métricas, *logs* e *traces* para análise de causa raiz em sistemas *cloud-native*, indicando que a combinação de sinais constitui um caminho importante para melhorar o diagnóstico operacional (Han et al., 2024).

Apesar dos benefícios inegáveis, a implementação de soluções de observabilidade não é neutra em termos de consumo de recursos. A instrumentação e a coleta de telemetria podem introduzir um *overhead* relevante, impactando o desempenho do sistema monitorado. Abordagens recentes, como as propostas por Sharma e Nadig (2024) e Otero, Garcia e Fernandez (2025), buscam desenvolver alternativas mais leves e distribuídas para reduzir esse custo operacional. Além dos desafios técnicos de visibilidade, a decisão sobre qual *stack* de observabilidade adotar envolve *trade-offs* complexos relacionados a *overhead*, integração e manutenção. Em ambientes de microsserviços, competências relacionadas a monitoramento, *Continuous Integration/Continuous Delivery* (CI/CD), integração de serviços e práticas de *Development and Operations* (DevOps) aparecem entre as capacidades essenciais para equipes que operam esse tipo de arquitetura (Ayas, Hebig e Leitner, 2024). Dessa forma, a avaliação empírica de ferramentas sob carga real, em múltiplas arquiteturas e com diversas métricas operacionais, mostra-se crucial tanto do ponto de vista científico quanto prático.

Estudos experimentais anteriores sobre *tracing* distribuído em microsserviços e ambientes *serverless* reforçam a importância de investigar o *overhead* operacional. Por exemplo, Nou et al. (2025) reportaram impactos substanciais em *throughput* e latência, além de identificar a serialização dos *traces* como uma das principais fontes de custo. Tais achados empíricos sublinham que a escolha e a configuração de uma *stack* de observabilidade podem ter implicações diretas no desempenho e na eficiência de recursos dos sistemas em produção. A variação no comportamento e no custo de diferentes ferramentas de observabilidade, sob distintas condições de carga e arquitetura, exige uma análise comparativa rigorosa para fornecer dados concretos que auxiliem engenheiros e arquitetos de software em suas decisões.

Diante da complexidade crescente dos sistemas distribuídos e da necessidade crítica de observabilidade, aliada ao *overhead* operacional que essas soluções podem introduzir, este trabalho objetiva comparar o desempenho e o impacto de diferentes tecnologias de observabilidade, especificamente Datadog, Grafana/Prometheus e Elastic Stack, em ambientes de arquitetura monolítica e de microsserviços, sob quatro cenários de carga e dois modos de execução (com e sem instrumentação), avaliando métricas de latência, *throughput*, erro, consumo de CPU e memória, bem como a capacidade de detecção de falhas induzidas.

2. Material e Métodos

O presente estudo foi delineado como uma pesquisa de natureza quantitativa e experimental, com abordagem comparativa, visando avaliar o desempenho e o impacto de distintas tecnologias de observabilidade. A metodologia empregada concentrou-se na comparação de três “stacks” de observabilidade em cenários controlados, permitindo a análise de variáveis de desempenho sob diferentes condições operacionais. Este desenho experimental buscou fornecer evidências empíricas sobre o “overhead” introduzido por cada ferramenta, contribuindo para a compreensão dos “trade-offs” envolvidos na escolha de soluções de monitoramento em sistemas distribuídos.

Os experimentos foram conduzidos em um ambiente de host local, utilizando um sistema operacional Windows 10 Home Single Language, versão 2009. A infraestrutura de execução baseou-se em conteinerização, gerenciada por Docker Engine 27.2.0 e Docker Compose v2.29.2-desktop.2. O ambiente experimental foi mantido constante ao longo de todas as baterias comparativas, assegurando que as três “stacks” fossem avaliadas sob as mesmas condições de sistema operacional, mecanismo de conteinerização e protocolo de carga. Essa preocupação com repetibilidade e controle das variáveis de execução esteve alinhada a práticas contemporâneas de avaliação de desempenho e “benchmarking” em sistemas emergentes (Nambiar e Poess, 2024). A unidade de análise consistiu nas três “stacks” de observabilidade selecionadas, operando em dois estilos arquiteturais distintos.

A pesquisa comparou três “stacks” de observabilidade amplamente utilizadas no ecossistema de sistemas em nuvem: Datadog, Grafana/Prometheus e Elastic Stack. Essas ferramentas foram selecionadas por sua relevância e representatividade no contexto de monitoramento de arquiteturas distribuídas. As aplicações alvo foram implementadas em dois estilos arquiteturais distintos: um monolito (projeto inventory-manager) e um sistema de microsserviços (projeto seat-flow). Cada combinação de fatores experimentais, que incluía a “stack”, a arquitetura, o cenário de carga e o modo de execução, foi repetida cinco vezes, totalizando duzentas e quarenta execuções válidas para análise.

As “stacks” de observabilidade foram configuradas com componentes específicos para cada ecossistema. O Datadog utilizou o agente `gcr.io/datadoghq/agent:7`, com APM e receptores OpenTelemetry Protocol (OTLP) via HTTP (4318) e gRPC (4317), além de coletar “logs” de contêineres e integrar “openmetrics”. O Grafana/Prometheus empregou `prom/prometheus:latest` e `grafana/grafana:latest`, com intervalos de `scrape` e `evaluation` de cinco segundos. A Elastic Stack consistiu em Elasticsearch 8.15.5, Kibana 8.15.5, APM Server 8.15.5, Filebeat 8.15.5 e Metricbeat 8.15.5. A opção por uma pilha baseada em coleta, armazenamento e consulta desacoplados mostrou-se coerente com trabalhos recentes que exploraram arquiteturas de monitoramento distribuídas apoiadas em Elasticsearch e componentes de streaming para alta escalabilidade (Calderon et al., 2024).

A instrumentação das aplicações foi realizada utilizando NodeSDK do OpenTelemetry com `auto-instrumentations-node` para “tracing”. No monolito, o “backend” foi configurado com Node.js, `prom-client` 15.1.3, `elastic-apm-node` 4.15.0 e SDK do OpenTelemetry 0.213.0. Nos microsserviços, os serviços `auth`, `user`, `reservation` e `seat` utilizaram `prom-client` 15.1.3 e SDK do OpenTelemetry 0.211.0. As métricas Prometheus foram expostas via `endpoint` `/metrics`, com `collectDefaultMetrics()` habilitado apenas no modo instrumentado. As métricas coletadas incluíram `http_requests_total`, `http_errors_total` e `http_request_duration_seconds`, com histograma de duração HTTP utilizando `buckets` específicos para capturar variações de latência.

Cada cenário experimental foi executado em dois modos distintos: “base”, sem instrumentação adicional de observabilidade, e “instr”, com instrumentação e coleta de telemetria ativadas para a “stack” em avaliação. Os cenários de carga foram definidos por scripts `k6` específicos: “idle” (um usuário virtual por um minuto), “normal” (dez usuários virtuais por dois minutos), “high” (cinquenta usuários virtuais por dois minutos) e “burst” (rampa até cinquenta usuários virtuais, sustentação curta e retorno a zero). No monolito, o alvo principal foi `GET /api/health`, enquanto nos microsserviços, o “gateway” HTTP encaminhou requisições para rotas de `users`, `auth`, `reservations` e `seats`.

O protocolo de execução automatizado, implementado via scripts PowerShell, compreendeu sete etapas para cada repetição. Inicialmente, a “stack” de observabilidade e a aplicação alvo eram iniciadas, aguardando-se a confirmação de “health checks” HTTP. Em seguida, iniciava-se a coleta de estatísticas de contêineres via `docker stats` a cada dois segundos, e a carga era executada com `grafana/k6:latest`. Finalmente, metadados de execução, versões e contêineres ativos eram registrados, e os artefatos brutos eram consolidados em diretórios versionados. Campanhas de validação de falhas induzidas induziram latência HTTP, erros 500, lentidão de banco de dados e pausas em filas, para observar o comportamento das “stacks” com APM habilitado.

Os artefatos brutos, organizados em conjuntos `raw_datadog`, `raw_grafana` e `raw_elastic`, foram consolidados no arquivo `dataset/processed/results.csv`. O processamento utilizou `k6.json`, `docker_stats.csv` e `run.log` de cada execução. Do `k6`, extraíram-se o p50, p95 e p99 da duração de requisições HTTP, erros de requisição, contagem total de requisições e duração efetiva da execução para cálculo de requisições por segundo (rps). As métricas de contêineres, como `cpu_avg`, `cpu_p95`, `mem_avg` e `mem_p95`, foram agregadas por `timestamp` a partir do `docker_stats.csv`. O “pipeline” de consolidação descartou artefatos legados e preservou apenas execuções marcadas como válidas no conjunto final.

A análise inferencial foi estruturada por ferramenta dentro de cada combinação de arquitetura, cenário e modo de execução. A normalidade dos dados foi verificada utilizando o teste de Jarque-Bera. Quando todos os grupos de um estrato atenderam ao critério de normalidade, aplicou-se a Análise de Variância (ANOVA) de uma via. Caso contrário, foi empregado o teste de Kruskal-Wallis. Para ambos os testes, calculou-se o tamanho de efeito, utilizando `eta_sq` para ANOVA e `epsilon_sq` para Kruskal-Wallis. Esta abordagem permitiu identificar diferenças estatisticamente significativas entre as ferramentas avaliadas em diversas métricas de desempenho.

Adicionalmente à análise inferencial, construiu-se um “ranking” ponderado com pesos configuráveis por métrica para sintetizar o desempenho global das ferramentas. Para métricas onde valores menores indicavam melhor desempenho (latência, erro, CPU e memória), a normalização foi realizada de forma que o maior valor observado entre as ferramentas fosse subtraído do valor da ferramenta e dividido pela diferença entre o maior e o menor valor. Para métricas onde valores maiores indicavam melhor desempenho (rps), a normalização subtraiu o menor valor da ferramenta e dividiu pela diferença entre o maior e o menor valor. O “score” final foi calculado pela média ponderada dos “scores” normalizados.

A atribuição dos pesos seguiu uma justificativa de engenharia orientada ao impacto operacional. A métrica de erro recebeu o peso de dois, por representar uma degradação funcional diretamente perceptível ao usuário. As métricas p95, p99 e rps receberam peso de um e meio, refletindo a cauda de latência e a capacidade efetiva de atendimento sob carga, aspectos cruciais na avaliação de desempenho de sistemas distribuídos. As demais métricas, como p50, `cpu_avg`, `cpu_p95`, `mem_avg` e `mem_p95`, receberam peso de um, funcionando como componentes basais do custo operacional. O “ranking” ponderado serviu como síntese comparativa complementar, não substituindo a análise estatística inferencial por estrato.

Algumas limitações metodológicas foram identificadas. O tamanho amostral de cinco repetições por grupo reduziu o poder dos testes de normalidade. A análise inferencial identificou diferenças globais entre as ferramentas, mas não incluiu pós-testes pareados nem correção por comparações múltiplas, o que restringiu a extrapolação para uma superioridade universal de uma ferramenta. Houve um problema inicial de compatibilidade no fluxo de exportação de “traces” do Elastic, corrigido antes da consolidação final. Além disso, a campanha experimental com Datadog dependeu da disponibilidade temporária de seu ambiente “Software as a Service” (SaaS), limitando a reexecução imediata da mesma configuração fora do período coberto pela licença.

3. Resultados e Discussão

O estudo comparativo das tecnologias de observabilidade Datadog, Grafana/Prometheus e Elastic Stack em arquiteturas monolíticas e de microsserviços, sob diferentes cenários de carga e modos de execução, revelou uma complexidade de desempenho que transcende a mera escolha de uma ferramenta. A consolidação de 240 execuções válidas permitiu uma análise estatística robusta, gerando 144 comparações inferenciais que abordaram nove métricas de desempenho em 16 estratos experimentais distintos. Destas, 91 comparações indicaram diferenças estatisticamente significativas entre as ferramentas avaliadas, conforme detalhado no relatório estatístico. Este achado inicial é crucial, pois corrobora a hipótese de que as “stacks” de observabilidade não são neutras em termos de “overhead” operacional, um ponto já levantado por Nou et al. (2025) e Sharma e Nadig (2024), que destacaram a introdução de custos relevantes pela instrumentação e coleta de telemetria. A variabilidade observada sugere que a escolha da solução de monitoramento deve ser contextualizada, considerando as especificidades da arquitetura e do perfil de carga.

A análise aprofundada das métricas revelou que as diferenças entre as ferramentas foram particularmente consistentes no que tange ao consumo de memória. Tanto a média de memória (`mem_avg`) quanto o percentil 95 da memória (`mem_p95`) apresentaram significância estatística em todos os 16 estratos experimentais. Este resultado é de grande relevância prática, pois indica que o custo de observabilidade, manifestado no consumo de memória, é um fator estável e previsível, independentemente da arquitetura da aplicação (monolito ou microsserviços), do cenário de carga (idle, normal, high, burst) ou do modo de execução (base ou instrumentado). A consistência desses achados em memória sugere que a pegada de recursos de cada “stack” de observabilidade é uma característica intrínseca e menos suscetível a variações contextuais do que outras métricas. Para equipes de engenharia e operações, isso implica que a estimativa do impacto na memória ao adotar uma dessas “stacks” pode ser feita com maior confiança, permitindo um planejamento de capacidade mais preciso e a otimização de custos de infraestrutura, especialmente em ambientes de nuvem onde o consumo de recursos é diretamente proporcional aos gastos (Volpert et al., 2023). A literatura sobre monitoramento de sistemas distribuídos frequentemente discute o “overhead” de CPU e rede, mas a consistência na memória, como evidenciado aqui, oferece uma nova perspectiva sobre a estabilidade do custo operacional.

Tabela 1. Total de comparações significativas por métrica.

Métrica	Comparações significativas	Total de comparações
p50	13	16
p95	11	16
p99	9	16
rps	11	16
erro	0	16
cpu_avg	9	16
cpu_p95	6	16
mem_avg	16	16
mem_p95	16	16

Fonte: elaborado pelo autor (2026)

A Tabela 1 ilustra claramente a prevalência de diferenças significativas nas métricas de memória, com `mem_avg` e `mem_p95` apresentando 16 comparações significativas em um total de 16. Este dado reforça a ideia de que a gestão de memória é um ponto crítico e distintivo entre as “stacks”. Em contraste, métricas como `p50`, `p95` e `rps` também demonstraram diferenças significativas, mas em um número menor de estratos (13, 11 e 11, respectivamente). Isso sugere que, embora a latência e o “throughput” sejam influenciados pela escolha da ferramenta de observabilidade, essa influência pode ser mais dependente do contexto específico da carga de trabalho e da arquitetura. A implicação prática é que, ao avaliar o impacto de uma “stack” na latência e no “throughput”, é fundamental considerar o perfil de uso da aplicação, enquanto o impacto na memória pode ser generalizado com maior segurança. A escolha de uma “stack” com menor consumo de memória pode ser particularmente vantajosa para aplicações com restrições de recursos ou em ambientes de microsserviços com muitos contêineres, onde a consolidação de recursos é primordial.

As diferenças em latência e “throughput”, especialmente nos percentis `p50`, `p95` e `rps`, são indicativos de como a escolha da solução de observabilidade pode influenciar não apenas a visibilidade operacional, mas também o comportamento responsivo da aplicação. A latência, em particular o `p95` e `p99`, é uma métrica crítica para a experiência do usuário em sistemas interativos. Um aumento na latência, mesmo que pequeno, pode ter um impacto significativo na satisfação do usuário e na retenção (Mazraemolla e Rasoolzadegan, 2024). Os resultados deste estudo, ao identificar diferenças significativas nessas métricas, sublinham a importância de considerar o “overhead” de instrumentação e coleta de telemetria no desempenho geral do sistema. A literatura tem explorado o impacto do “distributed tracing” na latência, com Kabamba, Khouzam e Dagenais (2024) buscando soluções de baixo “overhead” para Node.js. Nossos achados complementam essa discussão, mostrando que o impacto não se restringe apenas ao “tracing”, mas se estende a toda a “stack” de observabilidade e sua interação com a aplicação. Para engenheiros de desempenho, isso significa que a avaliação de uma “stack” deve incluir testes de carga realistas que simulem os padrões de uso esperados, a fim de identificar potenciais gargalos de desempenho introduzidos pela observabilidade. A otimização da instrumentação e a configuração dos coletores de telemetria tornam-se, portanto, tarefas essenciais para equilibrar a visibilidade com a performance.

Por outro lado, a métrica de erro não apresentou diferença significativa entre as ferramentas no recorte estável do “benchmark”. Em 14 dos 16 estratos, o teste foi classificado como “not_applicable”, pois todos os grupos apresentaram erro igual a zero. Este resultado é esperado e faz sentido, dado que o conjunto de dados consolidado para as análises estatísticas foi formado por execuções estáveis de “benchmarking”, e não por campanhas específicas de falha induzida. A ausência de erros no cenário base de “benchmark” valida a estabilidade do ambiente experimental e a robustez das aplicações sob carga normal. No entanto, é crucial notar que o estudo também incluiu campanhas de validação de falhas induzidas com APM habilitado, conforme mencionado no resumo, que evidenciaram falhas e aumento de latência. Embora esses dados não tenham sido o foco principal da análise estatística quantitativa para as comparações de “overhead”, eles confirmam a capacidade das “stacks” de detectar e reportar problemas em cenários de degradação. A capacidade de uma ferramenta de observabilidade em identificar e diagnosticar falhas é tão importante quanto seu “overhead” em condições normais, como destacado por Han et al. (2024) ao discutir a análise de causa raiz em sistemas “cloud-native”. A ausência de erros no “benchmark” não diminui a importância de uma “stack” robusta para detecção de falhas, mas sim delimita o escopo da análise de “overhead” para cenários de operação normal.

Figura 1. Distribuição consolidada de p95 por ferramenta

Fonte: elaborado pelo autor (2026)

As distribuições observadas, visualizadas por meio de “boxplots”, reforçaram os padrões estatísticos identificados. A Figura 1, que apresenta a distribuição consolidada do `p95` da latência, oferece uma visão clara das diferenças entre as ferramentas. O Grafana/Prometheus (grafana-oss) demonstrou um comportamento relativamente mais favorável em várias métricas de latência e “throughput”, com caudas de latência mais curtas e maior capacidade de processamento de requisições por segundo (rps). Este desempenho superior do Grafana/Prometheus pode ser atribuído à sua arquitetura leve e ao modelo de coleta baseado em “pull” do Prometheus, que pode introduzir menos “overhead” na aplicação instrumentada em comparação com agentes mais intrusivos ou modelos de “push” de telemetria. A flexibilidade do Grafana para visualização e a capacidade do Prometheus de coletar métricas de forma eficiente são bem documentadas na literatura, e este estudo fornece evidências empíricas que corroboram essa percepção em um ambiente controlado. Para organizações que priorizam a baixa latência e o alto “throughput”, especialmente em aplicações de missão crítica, o Grafana/Prometheus emerge como uma opção atraente, desde que a complexidade de sua configuração e manutenção auto-hospedada seja gerenciável.

Figura 2. Distribuição consolidada de mem_avg por ferramenta

Fonte: elaborado pelo autor (2026)

Em contraste, o Datadog apresentou um comportamento agregado mais favorável em memória quando comparado ao Elastic Stack, como pode ser observado na Figura 2, que ilustra a distribuição consolidada da média de memória (`mem_avg`). Embora o Datadog seja uma solução SaaS com um agente mais abrangente, sua otimização para o consumo de recursos no host pode ser um diferencial. A capacidade de um agente de observabilidade de operar com uma pegada de memória reduzida é crucial, especialmente em ambientes de microsserviços onde centenas ou milhares de instâncias de agentes podem estar em execução. Um menor consumo de memória por agente se traduz em maior densidade de contêineres por host e, consequentemente, em menor custo de infraestrutura. Este achado sugere que, para ambientes onde a otimização de recursos de memória é uma prioridade máxima, o Datadog pode oferecer uma vantagem competitiva. A literatura sobre soluções SaaS de observabilidade frequentemente destaca a conveniência e a riqueza de recursos, mas a eficiência de recursos no lado do cliente é um fator menos explorado e que este estudo traz à tona.

Figura 3. Distribuição consolidada de rps por ferramenta

Fonte: elaborado pelo autor (2026)

O Elastic Stack, por sua vez, mostrou um comportamento competitivo em CPU média e CPU p95 no “ranking” agregado, mas com pior posição relativa em latência e memória sob o protocolo adotado. A Figura 3, que exibe a distribuição consolidada de `rps`, pode ajudar a contextualizar esse desempenho. O Elastic Stack, com sua arquitetura baseada em Elasticsearch para armazenamento e Kibana para visualização, é conhecido por sua escalabilidade e capacidade de processar grandes volumes de dados de telemetria (Calderon et al., 2024). No entanto, a complexidade de seus componentes e o modelo de coleta podem introduzir um “overhead” que se manifesta em maior consumo de memória e latência em certos cenários. A necessidade de múltiplos componentes (Elasticsearch, Kibana, APM Server, Filebeat, Metricbeat) e a sobrecarga de processamento para indexação e busca podem explicar esse comportamento. Para equipes que já utilizam o Elastic Stack para outras finalidades, como busca ou análise de logs, a integração da observabilidade pode ser uma extensão natural. Contudo, é fundamental que essas equipes estejam cientes dos “trade-offs” em termos de latência e memória, e que realizem testes de desempenho específicos para suas cargas de trabalho. A otimização da configuração do Elastic Stack, como o ajuste de índices e a gestão de recursos do Elasticsearch, pode mitigar parte desse “overhead”.

Tabela 2. Ranking ponderado final das ferramentas avaliadas.

Posição	Ferramenta	Weighted score
1	grafana-oss	0.682
2	datadog	0.410
3	elastic-stack	0.348

Fonte: elaborado pelo autor (2026)

O “ranking” ponderado final, apresentado na Tabela 2, sintetizou o desempenho global das ferramentas com base nas médias normalizadas e ponderadas das métricas. O Grafana/Prometheus (grafana-oss) obteve a primeira posição com um “weighted score” de 0.682, seguido pelo Datadog (0.410) e pelo Elastic Stack (0.348). Este resultado é coerente com os achados estatísticos individuais e reforça a percepção de que o Grafana/Prometheus, sob o conjunto de pesos adotado e nas condições experimentais definidas, apresentou o melhor desempenho agregado, com valores relativamente mais favoráveis em latência e “throughput”. A atribuição de pesos, que priorizou métricas como erro (peso 2.0), p95, p99 e rps (peso 1.5), reflete uma justificativa de engenharia orientada ao impacto operacional, onde a degradação funcional e a capacidade de atendimento sob carga são consideradas cruciais.

A liderança do Grafana/Prometheus no “ranking” ponderado, embora significativa, deve ser interpretada com cautela, como o próprio estudo sugere. Não se trata de uma superioridade universal, mas sim de um desempenho otimizado para o conjunto de critérios e o ambiente experimental específicos. A natureza auto-hospedada do Grafana/Prometheus confere maior controle sobre a infraestrutura e a configuração, o que pode ser uma vantagem para equipes com expertise em operações e que buscam minimizar custos de SaaS. No entanto, essa vantagem vem acompanhada da responsabilidade de gerenciar a infraestrutura de monitoramento, o que pode ser um desafio para equipes menores ou com menos recursos. O Datadog, apesar de ter um “score” agregado menor, destacou-se sobretudo em memória, o que o torna uma opção viável para cenários onde a eficiência de recursos é primordial. O Elastic Stack, por sua vez, mostrou pontos fortes em CPU, mas não conseguiu compensar o impacto relativo observado nas demais métricas sob esse critério de agregação. A escolha final de uma “stack” deve, portanto, ser um processo multifacetado que considere não apenas o desempenho técnico, mas também o modelo de implantação, a facilidade de uso, a integração com o ecossistema existente e a capacidade da equipe de gerenciar a solução.

A leitura por estrato revelou um comportamento menos uniforme do que o “ranking” final agregado sugeriu, enfatizando a importância da análise contextual. Em arquiteturas de microsserviços, o Grafana/Prometheus predominou em latência e “throughput” na maior parte dos estratos, o que é consistente com seu desempenho geral. No entanto, em memória, Grafana/Prometheus e Datadog alternaram a melhor posição, indicando que a eficiência de memória pode variar mais significativamente com o cenário de carga e o modo de execução em microsserviços. Este achado é particularmente relevante para arquiteturas de microsserviços, onde a gestão de recursos é complexa devido à natureza distribuída e efêmera dos serviços. A capacidade de um agente de observabilidade de se adaptar a diferentes padrões de consumo de memória em microsserviços é um diferencial importante.

No contexto do monolito, o Elastic Stack apareceu com frequência como a ferramenta mais favorável em memória e em parte dos cenários de menor carga. Isso pode ser atribuído à forma como o Elastic Stack gerencia a coleta e o armazenamento de métricas, que pode ser mais eficiente para aplicações monolíticas com padrões de carga mais estáveis e previsíveis em cenários de baixa demanda. Em contrapartida, o Grafana/Prometheus manteve vantagem recorrente em “burst” e nos cenários mais intensos de latência e “throughput” no monolito. Isso sugere que, mesmo em arquiteturas monolíticas, o Grafana/Prometheus é mais resiliente sob alta carga, o que é um fator crítico para aplicações que experimentam picos de tráfego. A observação de que nem todo estrato apresentou significância em latência ou “throughput”, especialmente em cenários monolíticos de menor carga, reforça a necessidade de interpretar o “ranking” como síntese global, e não como substituto da leitura estratificada. Essa granularidade na análise é fundamental para que os arquitetos de sistemas e engenheiros de DevOps possam tomar decisões informadas, alinhadas às características específicas de suas aplicações e ambientes operacionais. A complexidade da escolha é um tema recorrente na literatura, com Ayas, Hebig e Leitner (2024) destacando a necessidade de competências específicas em monitoramento para arquiteturas de microsserviços.

Do ponto de vista analítico, os resultados obtidos são consistentes com as expectativas teóricas sobre o “overhead” de observabilidade em sistemas distribuídos. É esperado que diferentes ferramentas introduzam custos variados de coleta, exportação e armazenamento de telemetria, impactando CPU, memória, latência e “throughput” de maneiras distintas. A complexidade inerente a sistemas “cloud-native”, com conteinerização e microsserviços, amplifica a necessidade de observabilidade, mas também os desafios associados à instrumentação (Volpert et al., 2023). A validação empírica dessas variações de “overhead” é uma contribuição significativa deste estudo, fornecendo dados concretos que podem guiar a tomada de decisão. A capacidade de correlacionar métricas, logs e traces de forma integrada, como discutido por Han et al. (2024), é um objetivo central da observabilidade, mas o custo para alcançar essa integração não pode ser negligenciado.

Ainda assim, é fundamental reconhecer as limitações metodológicas do estudo. O tamanho amostral de cinco repetições por grupo, embora suficiente para as análises propostas, pode ter reduzido o poder dos testes de normalidade, o que é uma consideração importante para a generalização dos resultados. Além disso, a análise inferencial identificou diferenças globais entre as ferramentas, mas não incluiu pós-testes pareados nem correção por comparações múltiplas. Isso restringe a extrapolação para uma superioridade universal de uma ferramenta sobre as outras. Os achados devem ser lidos como evidência comparativa válida dentro do protocolo adotado, sem inferências sobre uma superioridade absoluta em todos os contextos. A ausência de pós-testes pareados significa que, embora saibamos que há diferenças significativas entre os grupos, não podemos afirmar com certeza quais pares específicos de ferramentas são significativamente diferentes em cada estrato sem análises adicionais. Esta é uma limitação comum em estudos experimentais com múltiplos grupos e métricas, e a sua explicitação é crucial para a interpretação correta dos resultados.

Um problema inicial de compatibilidade no fluxo de exportação de “traces” do Elastic Stack foi identificado e corrigido antes da consolidação final do estudo. A correção do “exporter” OpenTelemetry de OTLP HTTP/JSON para OTLP Proto permitiu a persistência de “traces” em `traces-apm-default` e a observação de cenários comparáveis de aumento de latência e transações com falha no Kibana. Essa correção garantiu que a etapa de APM do Elastic Stack não permanecesse pendente, alinhando o escopo consolidado do estudo à comparação entre “stacks” de observabilidade tanto em “overhead” operacional quanto em evidências de falhas induzidas. A capacidade de observar falhas induzidas e o comportamento das “stacks” sob essas condições é um aspecto valioso do estudo, complementando a análise de desempenho em cenários estáveis. A detecção eficaz de falhas é um dos pilares da observabilidade, e a validação dessa capacidade em cada “stack” é um critério importante para a seleção de ferramentas.

Por fim, uma limitação temporária do Datadog precisou ser registrada. A campanha experimental com essa plataforma dependeu da disponibilidade temporária de seu ambiente “Software as a Service” (SaaS) durante a janela experimental. Embora essa condição não tenha invalidado os resultados obtidos, pois as execuções foram realizadas e validadas com sucesso, ela restringiu a reexecução imediata da mesma configuração fora do período coberto pela licença e pelos testes realizados. Essa dependência de um ambiente SaaS para testes de desempenho pode ser um desafio em estudos futuros, especialmente para garantir a reprodutibilidade a longo prazo. No entanto, a inclusão do Datadog foi crucial para fornecer uma comparação abrangente com soluções auto-hospedadas, dado seu papel proeminente no ecossistema de observabilidade. A experiência com a dependência de SaaS ressalta a importância de considerar a sustentabilidade e a flexibilidade de reexecução ao planejar estudos comparativos envolvendo plataformas comerciais.

4. Conclusão

Conclui-se que o objetivo foi atingido, ao comparar o desempenho e o impacto das tecnologias de observabilidade Datadog, Grafana/Prometheus e Elastic Stack em arquiteturas monolíticas e de microsserviços, sob diferentes cenários de carga e modos de execução. O estudo avaliou métricas de latência, *throughput*, erro, CPU e memória, além da capacidade de detecção de falhas induzidas. Os resultados confirmaram que as “stacks” de observabilidade introduzem *overheads* operacionais distintos, cuja variação depende do contexto experimental, como a arquitetura, o cenário de carga e o modo de execução. As diferenças foram mais consistentes no consumo de memória, seguido por latência e *throughput*. O Grafana/Prometheus apresentou o melhor desempenho agregado sob o protocolo adotado, sem que isso implique superioridade universal.

Contudo, o estudo apresentou algumas limitações que restringem a generalização dos achados. O tamanho amostral reduzido por grupo (n=5) pode ter impactado o poder dos testes de normalidade. A análise inferencial identificou diferenças globais, mas não incluiu pós-testes pareados nem correção por comparações múltiplas, impedindo inferências sobre a superioridade absoluta de uma ferramenta sobre outra. Adicionalmente, a dependência temporária do ambiente SaaS do Datadog durante a janela experimental limitou a reexecução imediata. Para estudos futuros, sugere-se a replicação com maior tamanho amostral, a inclusão de pós-testes pareados e a exploração de outros cenários de arquitetura e carga. Seria valioso também investigar o custo-benefício de soluções SaaS versus auto-hospedadas e aprofundar a análise quantitativa da detecção de falhas.

Referências Bibliográficas

ASHOK, S.; HARSH, V.; GODFREY, B.; MITTAL, R.; PARTHASARATHY, S.; SHWARTZ, L. TraceWeaver: Distributed Request Tracing for Microservices Without Application Modification. In: ACM SIGCOMM 2024 – Proceedings of the 2024 ACM SIGCOMM Conference. 2024. p. 828-842. Disponível em: <https://doi.org/10.1145/3651890.3672254>.

AYAS, H. M.; HEBIG, R.; LEITNER, P. An empirical investigation on the competences and roles of practitioners in Microservices-based Architectures. Journal of Systems and Software, v. 213, 2024, 112055. Disponível em: <https://doi.org/10.1016/j.jss.2024.112055>.

CALDERON, G.; DEL CAMPO, G.; SAAVEDRA, E.; SANTAMARIA, A. Monitoring Framework for the Performance Evaluation of an IoT Platform with Elasticsearch and Apache Kafka. Information Systems Frontiers, v. 26, p. 2373-2389, 2024. Disponível em: <https://doi.org/10.1007/s10796-023-10409-2>.

HAN, Y.; DU, Q.; HUANG, Y.; LI, P.; SHI, X.; WU, J.; PEI, F.; TIAN, F.; HE, C. Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data. IEEE Transactions on Services Computing, v. 17, n. 6, p. 3789-3802, 2024. Disponível em: <https://doi.org/10.1109/TSC.2024.3478759>.

KABAMBA, H. M.; KHOUZAM, M.; DAGENAIS, M. R. Vnode: Low-Overhead Transparent Tracing of Node.js-Based Microservice Architectures. Future Internet, v. 16, n. 1, 2024, 13. Disponível em: <https://doi.org/10.3390/fi16010013>.

MAZRAEMOLLA, Z. P.; RASOOLZADEGAN, A. An effective failure detection method for microservice-based systems using distributed tracing data. Engineering Applications of Artificial Intelligence, v. 133, Part F, 2024, 108558. Disponível em: <https://doi.org/10.1016/j.engappai.2024.108558>.

NAMBIAR, R.; POESS, M. (eds.). Performance Evaluation and Benchmarking: 15th TPC Technology Conference, TPCTC 2023, Vancouver, BC, Canada, August 28 – September 1, 2023, Revised Selected Papers. Cham: Springer, 2024. Disponível em: <https://doi.org/10.1007/978-3-031-68031-1>.

NOU, A.; TALLURI, S.; IOSUP, A.; BONETTA, D. Investigating Performance Overhead of Distributed Tracing in Microservices and Serverless Systems. In: ICPE ’25: Companion of the 16th ACM/SPEC International Conference on Performance Engineering. 2025. p. 162-166. Disponível em: <https://doi.org/10.1145/3680256.3721316>.

OTERO, M.; GARCIA, J. M.; FERNANDEZ, P. An extensible lightweight framework for distributed telemetry of microservices. Sustainable Computing: Informatics and Systems, v. 46, 2025, 101100. Disponível em: <https://doi.org/10.1016/j.suscom.2025.101100>.

SHARMA, B.; NADIG, D. eBPF-Enhanced Complete Observability Solution for Cloud-native Microservices. In: 2024 IEEE International Conference on Communications (ICC). 2024. Disponível em: <https://doi.org/10.1109/ICC51166.2024.10622329>.

VOLPERT, S.; EICHHAMMER, P.; HELD, F.; HUFFERT, T.; REISER, H. P.; DOMASCHKA, J. The view on systems monitoring and its requirements from future Cloud-to-Thing applications and infrastructures. Future Generation Computer Systems, v. 141, p. 243-257, 2023. Disponível em: <https://doi.org/10.1016/j.future.2022.11.024>.

Artigo 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