As equipes responsáveis pela operação do Kubernetes precisam de mais do que painéis que exibam o consumo de CPU e memória e as taxas de erro. A complexidade dos ambientes cloud-native faz com que uma única solicitação passe por um gateway de entrada, serviços, filas, armazenamento e processos em segundo plano, enquanto as cargas de trabalho se movem e as versões mudam continuamente. Por isso, uma implantação pode parecer saudável no nível do Deployment, enquanto uma dependência posterior, um loop de tentativas ou uma pressão sobre um caminho no plano de controle provoca um aumento da latência.
Em um material publicado no blog da CNCF, Neel Shah, da Stackgen, explica que a monitoração tradicional responde a perguntas predefinidas, como: o uso da CPU ultrapassou determinado limite? Os erros estão aumentando? Já a observabilidade, de acordo com a abordagem apresentada no material, busca ajudar a equipe a investigar um problema que não era esperado e passar da observação do sintoma à compreensão da causa e do escopo.
As métricas iniciam a investigação, mas não a encerram
As métricas continuam sendo o ponto de partida natural porque são numéricas, eficientes para armazenamento e consulta e adequadas para alertas e análises de tendência. No Kubernetes, elas podem mostrar pressão nos nós, reinicializações de contêineres, aumento da latência das solicitações, lentidão do servidor de API ou acúmulo de itens nas filas.
O material propõe aproveitar os padrões RED para serviços — taxa de solicitações, erros e duração — e o padrão USE para a infraestrutura — utilização, saturação e erros. Esses indicadores ajudam a traçar o quadro inicial do incidente: um aumento na taxa de solicitações com latência estável é diferente de um aumento na duração e na saturação com o tráfego permanecendo constante.
Porém, transformar cada detalhe em um rótulo dentro da métrica cria um problema de cardinalidade, pois o grande número de combinações únicas aumenta os custos e torna as consultas mais lentas. O material alerta especificamente contra a inclusão de identificadores de solicitações ou usuários, ou de valores quase únicos, nas métricas; esses detalhes são mais adequados para logs ou traces.
Cada sinal responde a uma pergunta diferente
Os logs acrescentam o contexto local que os gráficos normalmente não preservam. Quando são estruturados e usam campos consistentes, como horário, nível de gravidade, nome do serviço, namespace, identidade do contêiner, caminho da solicitação e contexto do trace, fica mais fácil relacionar um evento específico ao serviço ou processo que o produziu. A métrica pode indicar que o serviço de pagamentos foi afetado, enquanto o log revela um timeout, uma exceção ou uma falha em uma dependência.
Já os traces distribuídos respondem a uma pergunta diferente: como uma única solicitação percorreu o sistema e onde o tempo foi consumido? Sua importância se destaca no Kubernetes porque a falha pode estar distribuída entre vários serviços, tentativas de repetição, limites de filas ou chamadas ao banco de dados. A transmissão do contexto de tracing permite conectar os diferentes spans dentro do contexto de uma única solicitação, enquanto as convenções semânticas compartilhadas ajudam a padronizar os nomes de campos e atributos entre métricas, logs e traces.
O material também inclui o profiling nesse panorama. Depois que as métricas identificam o serviço lento, o tracing identifica o caminho da solicitação afetada e os logs esclarecem o evento local, os dados de profiling podem ajudar a identificar a função ou o caminho do código que consome CPU ou memória.
O que muda na prática durante o incidente?
O material apresenta o exemplo de um serviço de checkout que, após uma nova implantação, começa a exceder a meta de latência, enquanto os indicadores de CPU e memória permanecem normais. As métricas revelam a existência do problema; em seguida, um trace de uma solicitação lenta mostra que a maior parte do atraso ocorre na etapa de autorização do pagamento. Depois, os logs exibem mensagens repetidas de timeout associadas ao mesmo contexto da solicitação.
Essa sequência leva a equipe de uma pergunta geral — por que o serviço de pagamentos ficou lento? — a opções operacionais mais específicas, como reverter uma alteração em uma dependência, reduzir a amplificação das tentativas ou redirecionar temporariamente o tráfego durante a investigação. O material também confirma que o melhor alerta é aquele que reflete um risco para a qualidade do serviço ou para seu objetivo de confiabilidade, e não apenas um incômodo bruto nos recursos da infraestrutura; ele apresenta como exemplo um alerta associado ao aumento do valor p99 da latência acima de um segundo durante dez minutos.
Regras de design aplicáveis
- Começar pelas métricas e pelos logs disponíveis e, em seguida, ampliar gradualmente a cobertura, em vez de coletar tudo sem um objetivo.
- Priorizar dimensões relacionadas ao serviço e à carga de trabalho, em vez de rótulos altamente exclusivos dentro das métricas.
- Usar uma estrutura consistente de metadados entre métricas, logs e traces.
- Adicionar identificadores de solicitação ou de trace aos logs para facilitar a transição entre os sinais.
- Construir alertas em torno de riscos de confiabilidade e qualidade do serviço, e não apenas da pressão sobre os recursos.
- Considerar a observabilidade como parte do design da aplicação e da plataforma, e não como um acréscimo posterior à implantação.
Leitura editorial da certi.news: o valor fundamental aqui não está em recomendar a compra de uma ferramenta ou a adoção de uma implementação específica, mas em redefinir o objetivo da observabilidade. O que realmente muda é a forma de usar os dados: a métrica captura o desvio, o tracing identifica o percurso, o log explica o evento e o profiling pode identificar a causa no nível do código. Ainda existem limitações práticas claras; coletar mais sinais não garante uma compreensão melhor, assim como a ausência de nomes e campos padronizados pode tornar a correlação frágil, enquanto os detalhes exclusivos podem elevar o custo das métricas e prejudicar o desempenho das consultas. Portanto, o benefício depende da qualidade do design e da conexão entre os sinais, e não do número de painéis.