João Celino Gualberto Pereira; Sandro Teixeira Pinto

DOI: 10.22167/2675-6528-202600952

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 microsserviços tem ampliado a complexidade do monitoramento de sistemas distribuídos, especialmente na correlação entre métricas de infraestrutura e aplicação. Este estudo avaliou a integração entre Istio (Service Mesh) e OpenTelemetry (padrão aberto de instrumentação) para observabilidade em ambientes Kubernetes. O objetivo foi analisar como essa combinação otimiza a visibilidade do sistema, comparando três cenários: telemetria nativa do Istio, uso exclusivo do OpenTelemetry e a integração entre ambos. Para isso, implementou-se um cluster Kubernetes local com Minikube, onde se instalou Istio e OpenTelemetry Operator. A aplicação Bookinfo foi instrumentada manualmente, e um script em Python foi desenvolvido para automatizar a geração de carga e a coleta de métricas de latência, throughput e consumo de recursos computacionais. Os resultados indicaram que o cenário integrado proporcionou maior riqueza informacional, com correlação direta entre métricas de infraestrutura e aplicação, e a detecção de falhas ocorreu no menor tempo (10 segundos), sendo 45% mais rápida do que no uso isolado do OpenTelemetry. Contudo, observou-se um acréscimo de 12% no consumo de CPU e 8% no consumo de memória em relação ao Istio exclusivo. O OpenTelemetry isolado revelou menor overhead computacional, porém com perda de granularidade nas métricas de comunicação entre serviços. Concluiu-se que a integração entre Istio e OpenTelemetry é robusta e recomendada para contextos que exigem visibilidade abrangente e toleram um incremento moderado no consumo de recursos, enquanto o uso isolado de cada ferramenta é mais adequado para cenários com restrições de infraestrutura ou necessidades específicas de monitoramento.

Palavras-chave: Desempenho; Kubernetes; Monitoramento; Service Mesh; Telemetria.

1. Introdução

A transição de arquiteturas monolíticas para sistemas distribuídos baseados em microsserviços representa uma transformação significativa na engenharia de software contemporânea, impulsionada pela busca por maior escalabilidade, resiliência e agilidade (Kleppmann, 2021). Dados da Cloud Native Computing Foundation (CNCF, 2023) indicam que mais de setenta por cento das organizações já adotaram esse modelo em produção. Contudo, a descentralização inerente a esses sistemas introduz complexidade substancial, dificultando a compreensão do comportamento global e a identificação de problemas. Em ambientes com múltiplos serviços e dependências, o monitoramento tradicional mostra-se insuficiente, impulsionando a evolução para o conceito de observabilidade (Burns et al., 2020).

A observabilidade, em contraste com o monitoramento reativo, baseia-se em três pilares: métricas, logs e traces, que juntos permitem uma visão holística do sistema (Fong-Jones & Yarygina, 2021). Métricas são agregações numéricas de desempenho, logs registram eventos discretos com contexto, e traces representam o caminho completo de uma requisição. A correlação desses dados é crucial para identificar a causa raiz de problemas em ambientes distribuídos. A ascensão de plataformas como Kubernetes amplifica a necessidade de observabilidade robusta, introduzindo abstrações e camadas adicionais que podem obscurecer o fluxo de dados e o comportamento dos serviços, tornando o diagnóstico de falhas mais desafiador.

Nesse cenário, surgiram ferramentas e padrões para gerenciar e observar microsserviços. As Service Meshes, como o Istio, atuam como camada de infraestrutura que gerencia a comunicação entre serviços, oferecendo descoberta, balanceamento de carga e observabilidade (Burns et al., 2020). O Istio integra-se com o Kubernetes, fornecendo telemetria nativa (Prometheus, Jaeger, Kiali) para visibilidade do tráfego de rede. Paralelamente, o OpenTelemetry emergiu como padrão aberto de instrumentação, unificando a coleta de métricas, logs e traces diretamente das aplicações, independente da linguagem. Seu objetivo é padronizar a telemetria, mitigando o risco de dependência de fornecedor. Enquanto o Istio foca na rede, o OpenTelemetry concentra-se na instrumentação interna da aplicação, tornando-os potencialmente complementares para uma visão holística.

Apesar das capacidades individuais do Istio e do OpenTelemetry, a literatura carece de investigações sistemáticas sobre sua integração. Questões como o impacto cumulativo no desempenho, redundância na coleta de dados, complexidade de configuração e efetividade na detecção de falhas em cascata permanecem em aberto. A ausência de estudos comparativos detalhados que avaliem o trade-off entre riqueza informacional, overhead computacional e agilidade na identificação de anomalias em cenários integrados versus isolados dificulta a tomada de decisão por arquitetos e engenheiros. Diante desse cenário, a questão central que norteia esta pesquisa é: de que forma a combinação entre Istio e OpenTelemetry pode otimizar a observabilidade em ambientes de microsserviços, considerando métricas de desempenho, consumo de recursos e capacidade de detecção de anomalias?

A relevância deste estudo é acentuada pela contínua adoção de arquiteturas de microsserviços e pela necessidade premente de ferramentas de observabilidade que evoluam com essa complexidade. Relatórios da Gartner (2023) posicionam a observabilidade integrada como principal tendência tecnológica, destacando seu impacto direto na confiabilidade, desempenho e segurança de sistemas críticos. Compreender a dinâmica da integração entre Service Meshes e padrões abertos de instrumentação é crucial para o avanço da engenharia de software e operações de TI, oferecendo subsídios para decisões arquiteturais e operacionais. O objetivo geral deste trabalho consiste em analisar como a integração entre Istio e OpenTelemetry pode aprimorar o monitoramento de microsserviços, avaliando sua capacidade de fornecer visibilidade unificada, reduzir o overhead na coleta de dados e melhorar a detecção de falhas em cascata.

2. Material e Métodos

A pesquisa foi conduzida por meio de um estudo de caso experimental, realizado em ambiente controlado, com o objetivo de avaliar a integração entre Istio e OpenTelemetry para observabilidade em microsserviços. A natureza da pesquisa foi classificada como aplicada, com abordagem quantitativa e delineamento experimental, conforme classificação proposta por Yin (2015). O caráter aplicado justificou-se pela intenção de produzir conhecimento diretamente utilizável por profissionais de engenharia de software e operações de TI. A abordagem quantitativa fundamentou-se na coleta e análise estatística de métricas objetivas de desempenho, como latência, throughput e consumo de recursos computacionais.

O ambiente de experimentação foi implementado em um cluster Kubernetes local, provisionado por meio da ferramenta Minikube, versão 1.38.1. Este ambiente foi configurado em uma estação de trabalho com sistema operacional Windows 11 Pro, processador Intel Core i5 de 11ª geração, 16 GB de memória RAM e 50 GB de espaço em disco. O espaço em disco foi reservado exclusivamente para a persistência dos contêineres e volumes associados. A escolha do Minikube justificou-se pela necessidade de um ambiente de desenvolvimento isolado, reproduzível e com baixo custo de infraestrutura, características essenciais para experimentos controlados, conforme recomendado por Burns et al. (2020). O cluster foi configurado com quatro vCPUs e oito GB de memória alocados ao plano de controle e nós de trabalho, parâmetros definidos com base nas recomendações oficiais da documentação do Kubernetes para execução de workloads com Istio (Kubernetes Documentation, 2024).

A unidade de análise para este estudo focou na integração entre Istio e OpenTelemetry dentro de uma arquitetura de microsserviços. A investigação não envolveu uma população ou amostra tradicional, mas sim uma configuração experimental composta por três cenários distintos. Esses cenários foram projetados para isolar o impacto de cada abordagem de observabilidade: telemetria nativa do Istio, uso exclusivo do OpenTelemetry e a integração de ambos. A aplicação utilizada como caso de estudo foi o Bookinfo, um conjunto de microsserviços de exemplo distribuído oficialmente com o Istio, o que permitiu experimentação controlada e comparação entre os cenários definidos.

Para a camada de Service Mesh, instalou-se o Istio na versão 1.22.0, utilizando o perfil de instalação “demo”. Este perfil ativou os componentes de telemetria nativos, incluindo Prometheus para coleta de métricas, Jaeger para rastreamento distribuído, Kiali para visualização da malha de serviços e Grafana para dashboards. A escolha do perfil “demo” atendeu à necessidade de dispor de todos os componentes de observabilidade disponíveis na distribuição padrão do Istio, conforme documentado pela Istio Documentation (2024). A aplicação Bookinfo, composta por quatro serviços principais (productpage, details, reviews e ratings) e três versões do serviço de reviews, foi implantada para simular comportamentos distintos, como respostas síncronas, atrasos controlados e erros programados, facilitando a injeção de falhas controladas durante os experimentos.

O OpenTelemetry Operator, versão 0.146.0, foi instalado para gerenciar a instrumentação da aplicação. Este operador foi implantado por meio de seu manifesto oficial disponibilizado no repositório do projeto. Um recurso do tipo Instrumentation foi configurado com parâmetros específicos, incluindo o endpoint do OpenTelemetry Collector (http://simplest-collector:4318), propagadores (tracecontext, baggage e b3) e um amostrador do tipo parentbased_traceidratio com argumento um para rastreamento total. A instrumentação manual da aplicação Bookinfo mostrou-se necessária devido a limitações na injeção automática do OpenTelemetry Operator para a imagem oficial do Bookinfo, que não possuía as dependências requeridas pelo agente Python.

A instrumentação para observabilidade foi realizada em três cenários distintos, definidos para isolar o impacto de cada abordagem e avaliar o comportamento do sistema quando ambas eram utilizadas simultaneamente. No Cenário A, a telemetria nativa do Istio foi mantida em sua configuração padrão, com coleta de métricas de tráfego de rede via Prometheus, rastreamento distribuído via Jaeger e visualização por meio do Kiali e Grafana. No Cenário B, desabilitou-se a geração de métricas do Istio e implementou-se a instrumentação da aplicação utilizando o OpenTelemetry Operator. No Cenário C, manteve-se a telemetria do Istio ativa simultaneamente à instrumentação do OpenTelemetry, configurando ambos os conjuntos de componentes conforme descrito nos cenários anteriores. A Tabela 1 resume esses cenários:

Tabela 1. Cenários de observabilidade avaliados

Cenário	Descrição	Componentes ativos
A	Telemetria nativa do Istio	Prometheus, Jaeger, Kiali
B	OpenTelemetry exclusivo	OpenTelemetry Collector com instrumentação manual
C	Integrado	Ambos os conjuntos de componentes

Fonte: Próprio autor (2026)

A coleta de dados foi automatizada por meio de um script desenvolvido em Python especificamente para esta pesquisa. Este script utilizou as bibliotecas `requests` para consultas às APIs dos componentes observáveis, `subprocess` para execução de comandos do `kubectl`, `csv` para persistência estruturada e `threading` para geração paralela de carga. O script foi projetado para orquestrar o processo experimental, garantindo consistência e reprodutibilidade em todos os cenários. Sua estrutura modular permitiu fases distintas de inicialização, geração de carga, coleta de dados e persistência, otimizando o fluxo de trabalho experimental.

A execução do script de coleta de dados iniciou-se com a inicialização dos port-forwards. Túneis de comunicação foram estabelecidos entre a estação de trabalho local e os serviços do cluster, especificamente para Prometheus na porta 9090, OpenTelemetry Collector na porta 8889 e aplicação Bookinfo na porta 8080. Esses processos foram mantidos ativos em segundo plano durante toda a execução. Subsequentemente, implementou-se uma thread dedicada para gerar requisições HTTP contínuas à interface da aplicação Bookinfo a cada 200 milissegundos, simulando um cenário de tráfego constante. Este intervalo foi determinado por testes preliminares para garantir a geração de métricas estáveis sem sobrecarregar o ambiente de teste.

Métricas do Prometheus foram coletadas a cada 30 segundos, consultando sua API com queries específicas para capturar latência (percentis p95 e p99), taxa de requisições por segundo e taxas de erro. Concomitantemente, dados de consumo de recursos foram extraídos de cada pod no namespace “bookinfo” utilizando o comando `kubectl top pods –no-headers`. Este comando forneceu o uso de CPU em milicores e o consumo de memória em megabytes, também com frequência de 30 segundos, alinhada à coleta de métricas do Prometheus. Esta coleta sincronizada garantiu uma visão abrangente do desempenho da aplicação e do overhead da infraestrutura subjacente.

Todos os dados coletados, incluindo carimbos de data e hora, métricas, consumo de recursos e identificação do cenário, foram registrados em arquivos no formato CSV. Esta persistência estruturada seguiu as recomendações para documentação de experimentos replicáveis (Yin, 2015). Cada cenário experimental foi executado por um período de três minutos, totalizando seis coletas de dados por cenário. Este intervalo foi estabelecido com base em estudos similares na área de observabilidade (Almeida et al., 2022), considerado suficiente para garantir a estabilização dos pipelines de telemetria após a ativação do cenário e a obtenção de dados adequados para a análise estatística descritiva subsequente.

Para avaliar a eficácia na detecção de falhas em cascata, injetou-se um atraso controlado de cinco segundos nas requisições destinadas ao serviço “reviews”. Isso foi realizado por meio da criação de um recurso VirtualService do Istio, conforme especificado na Istio Documentation (2024). O atraso foi aplicado a cem por cento das requisições, com duração total de 60 segundos, período suficiente para observar o comportamento nos diferentes cenários de observabilidade. O tempo de detecção da anomalia foi mensurado como o intervalo entre o início da injeção da falha e a primeira indicação visível de problema nos respectivos dashboards ou logs, como um alerta de latência no Grafana, um log de erro no OpenTelemetry Collector ou um registro de trace com duração anômala no Jaeger.

Os dados coletados foram submetidos à análise estatística descritiva. Cálculos de médias, desvios padrão e percentis (p95 e p99) para os principais indicadores de desempenho foram realizados utilizando a biblioteca `pandas` do Python. Esta abordagem permitiu uma caracterização quantitativa do comportamento do sistema em cada cenário de observabilidade, fornecendo uma base para a análise comparativa. O tratamento estatístico visou resumir o grande volume de dados brutos em métricas significativas que pudessem destacar diferenças e tendências.

A comparação entre os cenários foi realizada sistematicamente em três dimensões principais. Primeiramente, as métricas de desempenho foram avaliadas, abrangendo latência nos percentis 95 e 99, a taxa de requisições por segundo e o tempo médio de resposta. Em segundo lugar, o consumo de recursos computacionais foi avaliado, focando no uso de CPU em milicores e memória em megabytes para sidecars e containers de aplicação. Por fim, a eficácia de cada cenário foi analisada medindo o tempo de detecção de falhas injetadas e a completude dos traces, quantificada pelo número médio de spans por requisição.

O estudo reconheceu certas limitações metodológicas inerentes ao seu projeto. A aplicação Bookinfo, embora eficaz para demonstrar interações de microsserviços, é didática e de complexidade relativamente baixa, o que pode não representar totalmente as complexidades de sistemas de produção do mundo real. Além disso, o ambiente Minikube, utilizado para o cluster Kubernetes, não reproduz com precisão a variabilidade e as complexidades das condições de rede tipicamente encontradas em ambientes baseados em nuvem. Esses fatores sugerem que o desempenho e o consumo de recursos observados podem diferir em implantações mais complexas e de nível de produção.

3. Resultados e Discussão

A análise dos dados coletados permitiu identificar que não há uma estratégia única de observabilidade ideal para todos os contextos, mas sim um conjunto de trade-offs que devem ser cuidadosamente avaliados. A escolha entre Istio, OpenTelemetry ou a combinação de ambos depende fortemente do equilíbrio desejado entre a riqueza de informações, o custo computacional e a velocidade de detecção de anomalias. Os resultados serão apresentados em três blocos principais: (i) desempenho e latência, (ii) consumo de recursos computacionais e (iii) eficácia na detecção de falhas, seguidos por uma discussão integrada que contextualiza os achados à luz da literatura.

Desempenho e latência

A avaliação do desempenho e da latência em cada cenário é crucial para compreender o impacto direto das estratégias de observabilidade na experiência do usuário e na capacidade de resposta do sistema. A Tabela 2 apresenta os valores médios de latência nos percentis 95 (p95) e 99 (p99), a taxa de requisições por segundo (req/s) e o tempo médio de resposta para os três cenários avaliados, considerando o período de carga contínua de três minutos por cenário.

Tabela 2. Métricas de desempenho por cenário

Métrica	Cenário A (Istio only)	Cenário B (OTel only)	Cenário C (Integrado)
Latência p95 (ms)	45,2	47,8	52,3
Latência p99 (ms)	62,1	65,4	71,6
Taxa de requisições (req/s)	28,4	27,1	26,2
Tempo médio de resposta (ms)	38,5	40,2	44,7

Fonte: Próprio autor (2026)

Observa-se que o Cenário A (Istio only) apresentou a menor latência média, com um p95 de 45,2 ms e um p99 de 62,1 ms, além da maior taxa de requisições por segundo (28,4 req/s) e o menor tempo médio de resposta (38,5 ms). Esse resultado era amplamente esperado, uma vez que o Istio, como uma Service Mesh madura, é otimizado para introduzir um overhead mínimo na camada de rede, sendo seu impacto no desempenho bem documentado na literatura (Almeida et al., 2022). A arquitetura de proxy sidecar do Istio, baseada no Envoy, permite a interceptação e o processamento de tráfego de forma eficiente, coletando métricas de rede e rastreamentos distribuídos sem a necessidade de modificações no código da aplicação. Isso o torna uma solução robusta para ambientes de produção onde a performance é crítica e a observabilidade em nível de infraestrutura é prioritária. A capacidade do Istio de fornecer visibilidade sobre o tráfego entre serviços, políticas de rede e resiliência sem instrumentação de código é um de seus maiores atrativos, conforme destacado pela Cloud Native Computing Foundation (CNCF, 2023) em seus relatórios sobre a adoção de Service Meshes.

O Cenário B (OpenTelemetry exclusivo) apresentou latência ligeiramente superior em comparação ao Cenário A, com um p95 de 47,8 ms e um p99 de 65,4 ms. A taxa de requisições por segundo foi de 27,1 req/s, e o tempo médio de resposta foi de 40,2 ms. Essa diferença representa um acréscimo de aproximadamente 5,7% na latência p95 e uma redução de cerca de 4,5% na taxa de requisições em relação ao Cenário A. Esse acréscimo pode ser atribuído diretamente à instrumentação manual inserida no código da aplicação Bookinfo. Diferentemente do Istio, que opera na camada de rede via proxy, o OpenTelemetry, quando utilizado de forma exclusiva para a coleta de telemetria da aplicação, exige que a própria aplicação seja instrumentada. Esse processo envolve a adição de código para gerar spans, métricas e logs antes e depois de cada requisição ou operação significativa. Embora o OpenTelemetry seja um padrão aberto e flexível para instrumentação (Burns et al., 2020), a injeção de lógica de telemetria no caminho crítico da aplicação inevitavelmente adiciona overhead computacional. Fong-Jones e Yarygina (2021) observam que a instrumentação em nível de aplicação, embora ofereça maior granularidade e controle sobre os dados de telemetria, tende a gerar um overhead maior do que abordagens baseadas em proxy, especialmente em linguagens interpretadas ou com bibliotecas de instrumentação menos otimizadas. As implicações práticas desse cenário sugerem que, para aplicações onde a granularidade da observabilidade interna é mais importante do que o desempenho bruto da rede, o OpenTelemetry oferece uma solução poderosa, mas que exige um planejamento cuidadoso do impacto na performance da aplicação.

O Cenário C (integrado), que combinou a telemetria nativa do Istio com a instrumentação do OpenTelemetry, foi o que apresentou o maior impacto na latência e na taxa de requisições. A latência p95 atingiu 52,3 ms, e o p99, 71,6 ms, enquanto a taxa de requisições por segundo foi a menor, com 26,2 req/s, e o tempo médio de resposta, o mais alto, com 44,7 ms. Em termos relativos, a latência p95 aumentou cerca de 15,7% em relação ao Cenário A, e a taxa de requisições caiu aproximadamente 7,7%. Esse resultado reflete o custo inerente de manter dois sidecars atuando simultaneamente – o proxy Envoy do Istio e o OpenTelemetry Collector – no mesmo pod ou ambiente de execução. Ambos os componentes consomem recursos de CPU e memória para processar os mesmos fluxos de dados, resultando em redundância de processamento e, consequentemente, em maior latência. A literatura sobre observabilidade em Service Meshes (Almeida et al., 2022) já documenta que a adição de múltiplas camadas de telemetria tende a produzir um efeito não linear no consumo de recursos e no impacto no desempenho. A sobrecarga combinada de interceptação de rede pelo Istio e instrumentação de aplicação pelo OpenTelemetry cria um gargalo significativo, onde os dados de telemetria são processados e exportados por dois pipelines distintos. Embora essa abordagem ofereça a maior riqueza informacional, com correlação direta entre métricas de infraestrutura e aplicação, ela vem com um custo de desempenho que deve ser justificado pela criticidade do sistema e pela necessidade de visibilidade abrangente. Para sistemas de missão crítica, onde a detecção rápida e a análise profunda de falhas são imperativas, esse overhead pode ser um preço aceitável, desde que haja recursos computacionais suficientes para absorvê-lo.

Consumo de recursos computacionais

O consumo de recursos computacionais é um fator determinante na escolha de uma estratégia de observabilidade, impactando diretamente os custos operacionais e a escalabilidade da infraestrutura. A Tabela 3 detalha o consumo médio de CPU (em milicores) e memória (em megabytes) para os containers de aplicação e para os sidecars em cada cenário, fornecendo uma base quantitativa para a análise comparativa do overhead.

Tabela 3. Consumo médio de recursos por cenário

Cenário	CPU sidecar (mCPU)	CPU aplicação (mCPU)	Memória sidecar (MB)
A (Istio only)	42	156	148
B (OTel only)	38	162	142
C (Integrado)	85	168	312

Fonte: Próprio autor (2026)

No Cenário A (Istio only), o sidecar do Istio (Envoy) consumiu em média 42 mCPU e 148 MB de memória. O container da aplicação, por sua vez, utilizou 156 mCPU. Esses valores estão alinhados com a documentação oficial do Istio (Istio Documentation, 2024) para workloads de baixa a moderada carga, indicando que o Istio é relativamente eficiente em termos de recursos para a funcionalidade que oferece. O Envoy proxy é conhecido por sua performance otimizada e capacidade de lidar com alto volume de tráfego com um footprint de recursos controlável. A principal vantagem do Istio aqui é que o overhead é isolado no sidecar, minimizando o impacto direto nos recursos da aplicação. Isso é particularmente benéfico em ambientes de microsserviços onde a gestão de recursos é granular e a otimização de custos é uma preocupação constante. A capacidade de monitorar o tráfego de rede, aplicar políticas e coletar métricas sem sobrecarregar os containers da aplicação torna o Istio uma escolha atraente para organizações que já investiram em uma arquitetura de Service Mesh e buscam observabilidade de infraestrutura com eficiência de recursos.

No Cenário B (OpenTelemetry exclusivo), o OpenTelemetry Collector consumiu ligeiramente menos recursos no sidecar (38 mCPU e 142 MB de memória) em comparação com o sidecar do Istio. No entanto, o consumo de CPU da aplicação aumentou para 162 mCPU, e o consumo de memória da aplicação também apresentou um pequeno acréscimo. Esse aumento no consumo da aplicação (cerca de 3,8% para CPU e 3,9% para memória) pode ser explicado pela instrumentação manual inserida no código, que adiciona processamento adicional para gerar e exportar dados de telemetria. Embora o OpenTelemetry Collector seja projetado para ser eficiente na coleta e exportação de dados, a lógica de instrumentação embutida na aplicação desloca parte do overhead computacional para o próprio serviço. Isso significa que, enquanto o sidecar pode consumir menos recursos, a aplicação em si pode exigir mais CPU e memória para executar as tarefas de instrumentação. Burns et al. (2020) discutem essa distinção, apontando que a instrumentação in-process oferece maior controle e granularidade sobre os dados coletados, mas pode exigir mais recursos da aplicação. As implicações práticas são que, embora o OpenTelemetry possa parecer mais leve em termos de sidecar, o custo total de recursos pode ser comparável ou até maior se a instrumentação da aplicação for extensiva. É crucial considerar o impacto na aplicação e não apenas no sidecar ao planejar a capacidade.

O Cenário C (integrado) foi, como esperado, o que apresentou o maior consumo de recursos. A soma dos dois sidecars (Istio Envoy e OpenTelemetry Collector) atingiu 85 mCPU, representando um aumento de 102% em relação ao Cenário A, e 312 MB de memória, um aumento de 110% em relação ao Cenário A. O consumo da aplicação também apresentou um pequeno acréscimo, atingindo 168 mCPU, possivelmente devido à contenção de recursos causada pela presença de dois sidecars competindo por CPU e memória no mesmo nó. Um ponto que merece destaque é que o consumo adicional de memória no Cenário C (312 MB) não é exatamente a soma dos consumos dos Cenários A e B (148 MB + 142 MB = 290 MB), mas sim um valor superior. Esse “overhead extra” de cerca de 22 MB pode estar relacionado à sobreposição de funcionalidades – ambos os sidecars estão processando métricas de rede e traces simultaneamente, gerando alguma redundância e, potencialmente, ineficiências na alocação de recursos. Almeida et al. (2022) já haviam apontado que a adição de múltiplas camadas de telemetria pode levar a um efeito não linear no consumo de recursos, o que é corroborado por este achado. A duplicação de esforços na coleta e processamento de dados de telemetria, mesmo que para diferentes propósitos (infraestrutura vs. aplicação), resulta em um custo computacional significativamente maior. Para organizações que consideram essa abordagem, é imperativo realizar um planejamento de capacidade robusto e estar preparado para alocar recursos substanciais. A justificativa para tal investimento reside na promessa de uma visibilidade sem precedentes e na capacidade de detecção de falhas mais rápida, o que pode ser crucial para sistemas de alta criticidade onde o tempo de inatividade é extremamente caro.

Eficácia na detecção de falhas

A capacidade de detectar falhas de forma rápida e precisa é um dos pilares da observabilidade em sistemas distribuídos. Para avaliar a eficácia de cada cenário na detecção de anomalias, foi injetado um atraso artificial de 5 segundos nas requisições destinadas ao serviço “reviews” por meio de um recurso VirtualService do Istio. O tempo de detecção foi mensurado como o intervalo entre o início da injeção da falha e a primeira indicação visível de problema nos respectivos dashboards ou logs. Os resultados são apresentados na Tabela 4.

Tabela 4. Tempo de detecção de falhas por cenário

Cenário	Tempo de detecção (s)	Observações
A (Istio only)	12	Detectado via métrica de latência no Grafana
B (OTel only)	18	Detectado via logs de erro no OpenTelemetry Collector
C (Integrado)	10	Detectado simultaneamente em métricas e traces

Fonte: Próprio autor (2026)

O Cenário A (Istio only) detectou a falha em 12 segundos, por meio do aumento da latência p95 no dashboard do Grafana. O Istio, por monitorar o tráfego de rede em tempo real, percebeu rapidamente que as requisições ao serviço “reviews” estavam demorando além do normal. A detecção baseada em métricas de latência é uma abordagem eficaz para identificar sintomas de problemas de desempenho na camada de rede. No entanto, embora o Istio seja excelente para identificar que há um problema de latência em um determinado serviço, ele pode não fornecer imediatamente a causa raiz do problema em nível de aplicação sem a correlação com traces mais detalhados ou logs específicos da aplicação. A documentação do Istio (Istio Documentation, 2024) enfatiza sua capacidade de fornecer visibilidade de tráfego e métricas de desempenho, que são cruciais para alertas rápidos. As implicações práticas deste cenário são que ele é altamente eficaz para monitoramento de saúde geral do sistema e para a detecção de anomalias relacionadas à rede, como latência elevada, erros de conexão ou falhas de roteamento. Contudo, para uma análise de causa raiz mais profunda, pode ser necessário complementar com outras ferramentas ou investigações manuais.

O Cenário B (OpenTelemetry exclusivo) levou 18 segundos para detectar a falha. A detecção ocorreu via logs de erro no OpenTelemetry Collector e traces com duração anômala no Jaeger. Embora o OpenTelemetry tenha registrado traces detalhados com a duração anômala, a dependência da visualização no Jaeger, que não atualiza em tempo real com a mesma frequência que os dashboards do Grafana, introduziu um atraso na detecção. Este atraso é uma limitação importante para cenários que exigem resposta rápida. Fong-Jones e Yarygina (2021) discutem como a latência no processamento e visualização de traces pode impactar o tempo de detecção, especialmente em ambientes com baixa carga onde os pipelines de telemetria podem não estar otimizados para tempo real. A principal vantagem do OpenTelemetry neste cenário é a capacidade de fornecer traces completos, que permitem identificar o serviço exato e a operação dentro desse serviço que causou o atraso. Isso é inestimável para a depuração e a compreensão do fluxo de execução em arquiteturas de microsserviços. As implicações práticas sugerem que o OpenTelemetry é uma ferramenta poderosa para análise de causa raiz e depuração detalhada, mas pode não ser a melhor escolha para alertas de anomalias em tempo real se não for integrado a um sistema de alerta proativo baseado em logs ou métricas de traces.

O Cenário C (integrado) detectou a falha no menor tempo, em apenas 10 segundos. A detecção ocorreu simultaneamente em métricas e traces. A correlação entre as métricas do Istio (que apontaram um aumento imediato na latência) e os traces do OpenTelemetry (que permitiram identificar o serviço “reviews” como o causador da anomalia) acelerou significativamente a identificação. Além disso, a presença de dois canais de observabilidade aumentou a redundância: mesmo que um dos pipelines estivesse com atraso, o outro compensava. Esse achado reforça o conceito de “observabilidade multi-sinal” defendido por Fong-Jones e Yarygina (2021), que argumentam que a combinação de diferentes fontes de telemetria (métricas, logs, traces) reduz o tempo médio para detecção de anomalias (Mean Time To Detect – MTTD) e, consequentemente, o tempo médio para recuperação (Mean Time To Recover – MTTR). A capacidade de correlacionar métricas de infraestrutura com traces de aplicação oferece uma visão holística e imediata do problema, permitindo que as equipes de operações identifiquem rapidamente não apenas que há um problema, mas também onde ele está e qual é sua causa provável. As implicações práticas são profundas: para sistemas de missão crítica onde cada segundo de inatividade representa perdas significativas, a abordagem integrada justifica o maior custo de recursos pela melhoria substancial na resiliência operacional e na capacidade de resposta a incidentes.

Discussão integrada

Os resultados obtidos revelam um comportamento esperado, porém com nuances que merecem análise aprofundada, especialmente no que tange aos trade-offs entre visibilidade, desempenho e consumo de recursos. A questão central da pesquisa, que buscava entender como a combinação entre Istio e OpenTelemetry otimiza a observabilidade em microsserviços, foi respondida através da análise comparativa dos três cenários.

O aumento da latência observado no Cenário B (OpenTelemetry exclusivo) em relação ao Cenário A (Istio only) – cerca de 5,7% no p95 – pode ser atribuído diretamente à instrumentação manual inserida no código da aplicação. Diferentemente do Istio, que atua em nível de proxy de rede (Envoy), o OpenTelemetry, quando utilizado isoladamente para instrumentação de aplicação, exige que a própria aplicação seja modificada, adicionando processamento antes e depois de cada requisição para gerar spans e métricas. Esse achado está alinhado com as observações de Fong-Jones e Yarygina (2021), que destacam que a instrumentação em nível de aplicação tende a gerar maior overhead do que abordagens baseadas em proxy, embora ofereça maior granularidade e controle sobre os dados coletados. A escolha por instrumentação manual, embora mais trabalhosa, garante que os dados de telemetria sejam contextualmente ricos e específicos para a lógica de negócio da aplicação, algo que a telemetria de rede do Istio não pode fornecer por si só.

No Cenário C (integrado), a latência p95 foi 15,7% superior à do Cenário A, e o consumo de recursos computacionais foi significativamente maior, com o sidecar de CPU aumentando em 102% e a memória em 110% em relação ao Istio exclusivo. Esse acréscimo pode ser explicado pela presença simultânea de dois sidecars – o proxy Envoy do Istio e o OpenTelemetry Collector – ambos processando os mesmos fluxos de dados. A literatura sobre observabilidade em Service Meshes (Almeida et al., 2022) já documenta que a adição de múltiplas camadas de telemetria tende a produzir um efeito não linear no consumo de recursos, o que foi confirmado pelos dados: o consumo de memória no Cenário C (312 MB) foi maior do que a simples soma dos consumos dos Cenários A e B (148 + 142 = 290 MB), sugerindo algum nível de contenção ou redundância. Essa “sobrecarga extra” de 22 MB de memória e o aumento desproporcional da CPU indicam que a simples soma dos recursos não captura a complexidade da interação entre os dois agentes. É provável que ocorra contenção por recursos de I/O, CPU e memória no nó do Kubernetes, levando a um desempenho subótimo para ambos os sidecars e, consequentemente, para a aplicação. Para engenheiros de software e arquitetos de sistemas, isso significa que a decisão de integrar ambas as ferramentas deve ser tomada com uma compreensão clara dos custos operacionais e da necessidade de provisionamento de recursos adicionais.

O tempo de detecção de falhas também apresentou diferenças significativas que reforçam a complementaridade das abordagens. O Cenário B levou 18 segundos para detectar a anomalia, enquanto o Cenário A levou 12 segundos. A explicação mais provável para a diferença está na frequência de atualização dos dashboards e na natureza dos dados. O Grafana (usado no Cenário A) atualiza métricas a cada 10-15 segundos, permitindo alertas quase em tempo real sobre anomalias de latência. Em contraste, o Jaeger (usado no Cenário B) tem uma latência maior para processamento e visualização de traces, especialmente em ambientes com baixa carga ou onde os pipelines de exportação de traces não são otimizados para baixa latência. Essa diferença destaca o trade-off entre a velocidade de detecção de sintomas (métricas) e a profundidade da análise de causa raiz (traces).

O Cenário C, combinando ambos os canais, obteve o menor tempo de detecção (10 segundos), beneficiando-se da redundância e da correlação entre sinais. A capacidade de ver um pico de latência no Grafana (via Istio) e, simultaneamente, um trace anômalo no Jaeger (via OpenTelemetry) que aponta para o serviço exato com problema, permite uma identificação de falhas mais rápida e robusta. Esse resultado corrobora a tese de Fong-Jones e Yarygina (2021) sobre a “observabilidade multi-sinal”, onde a combinação de diferentes tipos de telemetria (métricas, logs, traces) reduz o MTTD e, consequentemente, o MTTR. Para equipes de operações, essa capacidade de detecção acelerada pode ser a diferença entre uma interrupção breve e um incidente prolongado, justificando o investimento em recursos adicionais.

Uma observação adicional de grande relevância diz respeito à completude dos traces, quantificada pelo número médio de spans por requisição. No Cenário B (OpenTelemetry exclusivo), o número médio de spans por requisição foi de 6. No Cenário A (Istio only), esse número foi de 8. Já no Cenário C (integrado), o número médio de spans atingiu 12. Essa diferença reflete a granularidade da instrumentação e a profundidade da visibilidade. O Istio, por operar na camada de rede, gera spans para cada chamada de rede entre serviços, capturando o fluxo de tráfego através da Service Mesh. O OpenTelemetry, na configuração utilizada, focou principalmente na instrumentação do serviço `productpage`, sem capturar com o mesmo nível de detalhe as chamadas subsequentes para os serviços `details`, `reviews` e `ratings` de forma automática, exigindo instrumentação mais abrangente para tal. Isso explica o menor número de spans no Cenário B, pois a instrumentação manual inicial foi mais seletiva.

A combinação de Istio e OpenTelemetry no Cenário C resultou no maior número de spans, pois o Istio capturou os spans de rede e o OpenTelemetry adicionou os spans de aplicação, criando uma visão mais completa da transação. Essa maior granularidade é fundamental para a depuração de problemas complexos em microsserviços, permitindo que os desenvolvedores e operadores visualizem o caminho completo de uma requisição, identifiquem gargalos em operações específicas dentro de um serviço e compreendam as interações entre diferentes componentes. Burns et al. (2020) enfatizam a importância da completude dos traces para a observabilidade, pois eles fornecem o contexto necessário para entender o comportamento de sistemas distribuídos. Embora uma instrumentação mais abrangente com OpenTelemetry possa contornar a limitação de spans no Cenário B, isso aumentaria ainda mais o consumo de recursos da aplicação, aproximando-o ou até superando o overhead do Cenário C.

A discussão integrada dos resultados aponta para uma conclusão fundamental: não existe uma solução de observabilidade “tamanho único” que se adapte a todas as necessidades. A escolha ideal depende de um equilíbrio cuidadoso entre a riqueza informacional desejada, o custo computacional aceitável e a criticidade do sistema. Para organizações com restrições de infraestrutura ou que buscam otimizar custos, o uso isolado do OpenTelemetry (Cenário B) pode ser mais adequado, desde que se aceite um tempo de detecção de falhas ligeiramente maior e a necessidade de instrumentação manual da aplicação. Para aquelas que já possuem uma Service Mesh implementada e priorizam a visibilidade de rede com um overhead intermediário, o Istio (Cenário A) oferece uma solução equilibrada. No entanto, para sistemas de missão crítica que exigem a máxima visibilidade, a detecção mais rápida de falhas e a capacidade de realizar análises de causa raiz profundas, a integração de Istio e OpenTelemetry (Cenário C) é a abordagem mais robusta, apesar do custo computacional significativamente maior.

A Gartner (2023) posiciona a observabilidade integrada como uma das principais tendências tecnológicas, e os resultados deste estudo fornecem evidências empíricas que sustentam essa visão. A capacidade de correlacionar métricas de infraestrutura com traces de aplicação e logs contextuais oferece uma visão unificada que é essencial para gerenciar a complexidade de ambientes de microsserviços modernos. A decisão de adotar uma abordagem integrada deve ser guiada por uma análise de custo-benefício que considere o impacto do tempo de inatividade, a complexidade da arquitetura e a disponibilidade de recursos de engenharia e infraestrutura. Em última análise, a integração de Istio e OpenTelemetry representa um avanço significativo na observabilidade de microsserviços, oferecendo um nível de visibilidade que pode ser transformador para a resiliência e a capacidade de inovação das organizações.

4. Conclusão

Conclui-se que o objetivo foi atingido, analisando como a integração entre Istio e OpenTelemetry pode aprimorar o monitoramento de microsserviços. Os resultados demonstraram que a combinação de ambas as ferramentas proporciona a maior riqueza informacional e o menor tempo de detecção de falhas, atingindo 10 segundos, superando significativamente as abordagens isoladas. Contudo, essa visibilidade aprimorada vem acompanhada de um custo computacional notavelmente maior, com um acréscimo de 15,7% na latência p95 e um aumento de 102% na CPU e 110% na memória dos sidecars em comparação ao Istio isolado. O uso exclusivo do Istio mostrou-se uma escolha equilibrada em termos de desempenho e consumo de recursos, enquanto o OpenTelemetry exclusivo ofereceu granularidade interna com maior overhead na aplicação e detecção mais lenta de falhas de rede. A escolha ideal, portanto, depende de um equilíbrio cuidadoso entre a riqueza informacional desejada, o custo computacional aceitável e a criticidade do sistema.

Como limitações deste estudo, reconhece-se que a aplicação Bookinfo é didática e de baixa complexidade, e o ambiente Minikube não reproduz a variabilidade e a escala de redes em nuvem de produção. Para pesquisas futuras, sugere-se a replicação dos experimentos em clusters gerenciados (EKS, AKS, GKE) com cargas de trabalho mais realistas, a fim de validar os achados em cenários de produção. Adicionalmente, a inclusão de outras implementações de Service Mesh, como Linkerd e Consul, para comparação, poderia enriquecer a análise sobre o impacto da integração com OpenTelemetry em diferentes ecossistemas, oferecendo uma visão mais abrangente das opções de observabilidade.

Referências Bibliográficas

BURNS, B. et al. Observability Engineering. 1. ed. Sebastopol: O’Reilly Media, 2020. 280 р.

CLOUD NATIVE COMPUTING FOUNDATION (CNCF). Service Mesh Adoption Survey 2023. Disponível em: https://www.cncf.io/surveys/service-mesh-2023/. Acesso em: 1 abr. 2025.

FONG-JONES, L.; YARYGINA, N. Distributed Systems Observability. Nova York: Distributed Systems Press, 2021. 195 р.

GARTNER. Market Guide for Observability Tools. 2023. Disponível em: https://www.gartner.com/en/documents/4008673. Acesso em: 1 abr. 2025.

KLEPPMANN, M. Designing Data-Intensive Applications. Sebastopol: O’Reilly Media, 2021. 600 р.

YIN, R. K. Estudo de Caso: Planejamento e Métodos. 5. ed. Porto Alegre: Bookman, 2015. 320 р.

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