Monitoramento de microserviços em Kubernetes: visibilidade real

Monitorar microserviços em Kubernetes é acompanhar cada requisição atravessando pod, namespace, service, deployment e chart dentro do cluster. A descoberta automática mantém o inventário vivo enquanto os pods nascem e morrem, e a propagação de contexto pelos cabeçalhos do W3C Trace Context é o que impede o trace de terminar no meio do percurso.

Quando uma aplicação vira dezenas de serviços independentes, a organização ganha autonomia de time e perde a visão de conjunto. Cada equipe enxerga o próprio serviço com precisão, e ninguém enxerga a requisição inteira, que é justamente a unidade que o usuário percebe e que o negócio cobra.

Monitoramento de microserviços em Kubernetes é a disciplina que acompanha o comportamento de cada serviço em execução dentro de um cluster orquestrado e correlaciona esse comportamento com as dimensões próprias do orquestrador. Devolver a visão de conjunto tem duas partes: a descoberta automática de tudo que roda no cluster, com a marcação correta de cada dimensão, e o trace distribuído, que costura as chamadas entre serviços em um percurso único e legível.

A Rike IS conduz consultoria, implantação, treinamento e governança contínua em observabilidade sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte.

As dimensões do Kubernetes que importam

Kubernetes organiza a execução em camadas, e cada camada responde a uma pergunta diferente durante um incidente. Cinco dimensões concentram quase toda a investigação em um cluster de produção.

Pod é a menor unidade de execução do cluster, um ou mais contêineres que compartilham rede e ciclo de vida. O orquestrador cria, destrói e recria pod o tempo todo, sem intervenção humana e sem aviso à equipe de operações.

Namespace é a divisão lógica do cluster. Ele separa ambientes, times ou produtos dentro da mesma infraestrutura física, e por isso costuma ser a dimensão que a organização usa para atribuir responsabilidade e custo. Um alerta sem namespace obriga alguém a descobrir de quem é o problema antes de começar a resolvê-lo.

Service é o ponto de acesso estável para um conjunto de pods que muda de endereço a cada recriação. A aplicação chama o service, não o pod, e essa indireção é o que permite ao orquestrador substituir réplicas sem quebrar quem depende delas.

Deployment descreve o estado desejado de um serviço: quantas réplicas devem existir, qual imagem cada uma executa e como uma versão nova substitui a anterior. Chart empacota esse conjunto de objetos para implantação e carrega a versão do que chegou ao cluster.

Para o gerente de infraestrutura, essas cinco dimensões são a base do rateio de consumo por área e da previsão de capacidade por namespace. Para o Site Reliability Engineer, ou SRE, são os filtros que reduzem um cluster inteiro ao serviço que de fato falhou.

Descoberta automática em cluster

Descoberta automática, ou auto-discovery, é a capacidade de identificar sozinho o que está em execução, sem que alguém declare cada componente em um arquivo de configuração. Em um cluster onde pods entram e saem o dia inteiro, ela decide se o inventário reflete a realidade ou uma foto antiga.

Na plataforma Dynatrace, o OneAgent cumpre esse papel. Uma instalação distribuída pelo próprio orquestrador coloca o agente em cada nó do cluster, e a partir daí ele descobre a stack em execução sem configuração manual por componente.

A parte decisiva vem depois da detecção. Cada entidade descoberta recebe a marcação das dimensões do Kubernetes a que pertence: pod, namespace, service, deployment e chart. Uma latência elevada deixa de ser um número solto e passa a ser um número com endereço, ligado ao serviço, ao namespace e à versão implantada naquele instante.

Essa marcação é o que permite correlacionar em várias direções ao mesmo tempo. A equipe filtra por namespace para isolar um produto, por service para isolar uma função, por deployment para comparar duas versões, e por chart para saber qual entrega introduziu o comportamento novo. Em vez de instrumentar serviço por serviço e manter esse trabalho vivo a cada mudança de arquitetura, a operação instala uma vez no cluster e recebe o inventário atualizado enquanto os pods nascem e morrem. Serviços novos aparecem já observados, porque a descoberta acontece na camada do nó.

Sobre esse inventário correlacionado opera o Smartscape, o mapa de dependências em tempo real da plataforma. O mapa mostra quem chama quem dentro do cluster, e é essa topologia que sustenta a análise de causa raiz que o Davis executa, dentro da disciplina de Artificial Intelligence for IT Operations, ou AIOps. A IA causal atua na identificação da causa e do contexto do problema, enquanto os dashboards organizam e tornam exploráveis os sinais operacionais.

Para o profissional de DevOps, a descoberta automática elimina a tarefa recorrente de registrar cada serviço novo na esteira de entrega. Para o CIO e o CTO, que aprovam o investimento, significa que a cobertura de observabilidade não se degrada em silêncio conforme o cluster cresce.

Rastrear a requisição entre serviços

Trace é o rastreamento de uma requisição percorrendo todos os serviços que participaram dela, e funciona como o GPS de uma viagem, mostrando cada parada do trajeto e onde houve atraso. Em arquitetura de microserviços, o trace deixa de ser recurso avançado e vira condição de diagnóstico.

O trace se compõe de spans. Cada span registra uma operação individual, como consultar um banco ou publicar uma mensagem em fila, e carrega identificador próprio, identificador do trace ao qual pertence, marcas de tempo, atributos e estado final.

Sem trace, o cluster produz uma cena confusa e conhecida por qualquer equipe de plantão. Cada serviço reporta saúde individual aceitável, o usuário reclama de lentidão, e ninguém consegue apontar em qual salto entre serviços o tempo foi consumido.

Com trace, a resposta é imediata. O percurso completo aparece em ordem, com a duração de cada etapa, e a etapa lenta se destaca sem que alguém precise abrir um painel por serviço para comparar horários. A investigação começa onde antes ela terminava.

Existe um ganho adicional em ambiente orquestrado. Como cada span carrega as dimensões do Kubernetes, o trace mostra não apenas qual serviço demorou, mas em qual pod e sob qual versão implantada aquilo aconteceu. Uma réplica defeituosa entre as réplicas saudáveis do mesmo serviço aparece nesse nível de detalhe.

Para o CTO e o CEO, o trace transforma discussão de responsabilidade entre times em evidência técnica compartilhada. Para o SRE, encurta o tempo médio de resolução justamente na fase mais cara do incidente, que é descobrir onde olhar.

Propagação de contexto e o span órfão

Propagação de contexto é o mecanismo que mantém o trace vivo quando a requisição salta de um serviço para o seguinte. Funciona como o carimbo no passaporte, que acompanha o viajante entre fronteiras. A propagação acontece por cabeçalhos padronizados pelo W3C Trace Context.

Dois campos fazem esse trabalho. O traceparent carrega a versão do formato, o identificador do trace, o identificador do span pai e as marcas de amostragem. O tracestate transporta informação adicional de fornecedor ao longo do mesmo percurso.

Quando alguma camada do percurso não repassa esses cabeçalhos, aparece o span órfão: uma operação registrada sem ligação com o trace a que pertence. O dado existe e o tempo foi medido, e ainda assim aquela etapa flutua isolada, fora do percurso que explicaria o comportamento do usuário. O efeito prático é um trace que termina no meio do caminho.

Três pontos concentram a maior parte das quebras de propagação em clusters reais. O primeiro é o serviço de entrada legado, que recebe a chamada externa e monta uma requisição nova sem copiar os cabeçalhos recebidos. O segundo é a comunicação assíncrona por fila, quando o produtor não grava o contexto na mensagem e o consumidor não tem de onde lê-lo. O terceiro é a biblioteca de cliente antiga, que abre a conexão de saída por um caminho que a instrumentação automática não intercepta.

A correção segue a mesma ordem em qualquer um dos três casos. Primeiro localizar o ponto exato de perda pelo trace incompleto, depois instrumentar à mão a entrada e a saída daquele serviço, e por último confirmar que o percurso fecha por inteiro.

Para o SRE, span órfão é a diferença entre um trace que aponta a causa raiz e um trace que apenas confirma a existência do problema. Para o gerente de infraestrutura, é custo de ingestão pago por um dado que não responde pergunta nenhuma.

Instrumentação em ambiente efêmero

Efemeridade é a característica que separa a operação de um cluster de tudo que veio antes dele. Pod é recriado a cada atualização de versão, réplica sobe e desce conforme a demanda, e um nó inteiro pode ser substituído durante a madrugada sem que ninguém acorde. Configuração de monitoramento presa ao host não sobrevive a esse ciclo, e quem instrumenta manualmente uma máquina descobre, na primeira substituição de nó, que a configuração se perdeu junto com a máquina.

A instrumentação em Kubernetes precisa estar ligada à definição do serviço, não ao lugar onde ele calhou de rodar.

Duas decisões resolvem isso, e ambas são tomadas antes da primeira instalação. A primeira é distribuir o agente pelo próprio orquestrador, de modo que qualquer nó novo receba a instrumentação como parte do provisionamento. A segunda é declarar os atributos de identificação na especificação do serviço, para que eles acompanhem cada réplica criada a partir dela.

Governança de atributos é a segunda decisão levada a sério. O campo service.name das semantic conventions do OpenTelemetry, padrão aberto e vendor-neutral da CNCF para gerar telemetria, precisa ter o mesmo valor em todas as réplicas do mesmo serviço, e valores diferentes entre serviços distintos. Nome divergente fragmenta o painel e enfraquece a análise causal.

A regra prática de nomeação cabe em uma frase: o nome do serviço identifica a função de negócio, não a máquina, o time ou o número da réplica.

Para o profissional de DevOps, atributo declarado na especificação significa que cada implantação chega ao painel já identificada, com a versão visível, e uma reversão pode ser avaliada por dado medido em vez de percepção. Para o gerente de infraestrutura, significa consumo atribuível por namespace desde o primeiro dia.

A convenção de atributos de um cluster em produção se decide antes da instalação, nunca depois do primeiro painel fragmentado. Atributo mal escolhido cria retrabalho de painel e de alerta meses depois, quando o histórico já carrega o nome errado. A Rike IS fecha essa convenção com a equipe de operações antes de colocar o agente no primeiro nó.

Sampling em volume de microserviços

Sampling, ou amostragem, é a decisão de guardar parte dos traces em vez de guardar todos, e funciona como a pesquisa eleitoral, que observa uma parcela para inferir o comportamento do conjunto. Em cluster com muitos serviços, cada requisição de usuário gera um span a cada operação do percurso, e o volume cresce mais rápido que a utilidade.

O que cabe decidir em um cluster é o critério, não o mecanismo. O critério é simples de enunciar: preservar integralmente o que tem erro e o que tem latência elevada, e amostrar o tráfego de rotina que se comporta como esperado. Trace de rotina descreve o que já se sabe, e trace de erro descreve o que precisa ser resolvido.

Esse critério corresponde ao sampling tail-based, que decide o que preservar depois de conhecer o resultado da transação. A alternativa, decidir no início da requisição, escolhe sem saber como aquela transação vai terminar, e descarta erro com a mesma probabilidade com que descarta sucesso.

Um cuidado acompanha qualquer critério de amostragem em ambiente de microserviços. A decisão precisa valer para o trace inteiro, e não para cada serviço isoladamente, porque um percurso guardado pela metade produz o mesmo efeito prático de um span órfão.

Para o CIO e o CTO, o sampling é o mecanismo que mantém a conta de observabilidade previsível enquanto o número de serviços aumenta. Para o SRE, é a garantia de que o incidente da madrugada terá trace disponível quando a investigação começar.

Por onde começar em um cluster já em produção

Instrumentar um cluster que já roda tem uma ordem que evita retrabalho, e ela contraria a intuição de começar pelo serviço mais problemático. Três decisões vêm antes de qualquer instalação.

A primeira é definir a convenção de nomes e atributos que vale para o cluster inteiro. Nome de serviço, identificação de ambiente e responsável por namespace precisam estar acordados antes que o primeiro dado chegue, porque corrigir marcação depois implica reprocessar histórico e reconstruir painel.

A segunda é mapear os pontos de entrada e de saída do cluster, que são onde a propagação de contexto quebra com mais frequência. Serviço legado, integração com terceiro e comunicação por fila entram nessa lista, e cada um recebe verificação explícita de que o trace atravessa.

A terceira é escolher o critério de amostragem antes do volume aparecer, e não depois da primeira conta acima do previsto.

Só então a instalação começa, e ela começa por um namespace representativo em vez do cluster inteiro. Um namespace instrumentado por completo ensina mais sobre o ambiente do que um cluster instrumentado pela metade, e permite ajustar a convenção enquanto o custo de mudar ainda é baixo.

A leitura desses dados dentro da disciplina de Application Performance Monitoring, ou APM, é o que transforma inventário em governança de performance. O que o usuário percebe do lado do navegador pertence à disciplina vizinha de Digital Experience Monitoring, ou DEM, e as duas leituras se encontram no mesmo trace.

Perguntas frequentes

E quando existe service mesh no caminho das chamadas?

Service mesh injeta um proxy ao lado de cada pod e passa a intermediar a comunicação entre serviços. O proxy gera span próprio. A camada extra entra no percurso e não substitui a instrumentação da aplicação, que continua respondendo pelo que acontece dentro do processo. A verificação necessária é uma só: se a aplicação repassa os cabeçalhos que recebeu, em vez de iniciar um trace novo a cada salto. Malha que reinicia o contexto parte o percurso em dois, com a aparência enganosa de dois incidentes independentes.

Vale instrumentar homologação com o mesmo critério de produção?

Vale, com diferença de volume e nenhuma diferença de convenção. Nome de serviço e atributos de identificação precisam ser idênticos nos dois ambientes, sob pena de o painel tratar o mesmo serviço como duas entidades distintas. O que muda é a retenção. O critério de amostragem também fica mais folgado fora de produção, porque o tráfego de homologação não sustenta decisão de capacidade. Ambiente com convenção própria vira a origem do retrabalho que a convenção deveria evitar.

O que muda quando a operação usa mais de um cluster ou mais de uma região?

Muda o atributo que separa as origens, não a lógica da observação. O inventário precisa carregar a identificação de cluster e de região, além das dimensões do Kubernetes. O campo cloud.region das semantic conventions do OpenTelemetry existe para essa finalidade. Sem esse eixo, dois pods de mesmo nome em clusters diferentes colidem no mesmo painel. Trace que atravessa cluster segue íntegro, com a condição de que a propagação de contexto sobreviva à saída de um cluster e à entrada do outro.

Job e CronJob aparecem no mesmo inventário dos serviços de longa duração?

Aparecem, e é nesse ponto que a marcação de atributos prova o próprio valor. Carga de curta duração sobe, executa e desaparece antes que qualquer coleta periódica feche uma janela de observação sobre ela. O trace da execução é o que sustenta a análise, com os atributos declarados na especificação do objeto. Rotina noturna sem atributo declarado desaparece sem deixar rastro, e é o ponto cego que mais reaparece em cluster maduro.

Instrumentar o cluster inteiro pesa nos nós?

O agente consome recurso do nó, como qualquer processo residente, e esse consumo entra na previsão de capacidade desde o desenho da implantação. A conta cresce por outro motivo: o volume de dado que a operação decide reter. Amostragem e retenção definidas antes da instalação mantêm o custo previsível, em vez de deixar a equipe reagir à primeira fatura acima do esperado. Nó em saturação antes da instrumentação já era um problema de capacidade, e a observação apenas o torna visível.

Observar microserviços em Kubernetes exige convenção acordada, descoberta automática confiável, propagação de contexto verificada e critério de amostragem definido, tudo isso em um ambiente que se recria sozinho várias vezes por dia. A Rike IS conduz esse trabalho por inteiro, com consultoria, implantação, treinamento e governança contínua sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. Leve o desenho do seu cluster para uma conversa técnica com os especialistas da Rike IS.