Observabilidade full-stack com SUSE Observability: do sintoma à causa, com a topologia e a linha do tempo

Por que logs, métricas e traces separados não bastam num incidente em Kubernetes, e como o SUSE Observability, o antigo StackState, liga tudo numa topologia que você pode voltar no tempo, integrada ao Rancher Prime.

5 min de leitura

Muitas equipes têm boas ferramentas de monitoramento e, ainda assim, passam a primeira hora de um incidente abrindo abas: o painel de métricas, a busca de logs, o rastreamento da aplicação, o histórico de deploys. Cada ferramenta mostra um pedaço verdadeiro. O que falta é a ligação entre eles, e é a sua equipe que acaba fazendo essa ligação de cabeça, sob pressão.

Este artigo explica o que o SUSE Observability, que antes se chamava StackState, faz de diferente nesse momento: ele parte da topologia, ou seja, do mapa de como os componentes se conectam, e permite voltar no tempo até o instante em que o problema começou.

Resumo rápido

  • Logs, métricas e traces separados mostram sintomas; a causa costuma estar na relação entre os componentes e na mudança que aconteceu antes da falha.
  • O SUSE Observability coleta topologia, eventos, logs, mudanças, métricas e traces dos clusters Kubernetes e liga tudo num mapa só.
  • A linha do tempo permite voltar ao estado da topologia num momento passado e ver a telemetria daquele instante.
  • Ele é integrado ao Rancher Prime: a SUSE inclui o SUSE Observability na subscrição, e uma extensão mostra a saúde dos recursos dentro do próprio Rancher.

Por que dados isolados não resolvem o incidente

Pense numa tela lenta para o cliente. A causa pode ser um pod reiniciando em loop, um banco de dados sem recurso, uma configuração alterada no deploy da tarde ou um nó com o disco cheio. Cada ferramenta separada aponta um sintoma. Para chegar à causa, alguém precisa saber que aquele serviço depende daquele banco, que roda naquele nó, que recebeu aquela mudança.

Em Kubernetes isso fica mais difícil, porque os componentes nascem e morrem o tempo todo. O pod que falhou às 14h pode nem existir mais às 14h20, quando alguém começa a investigar.

O que o SUSE Observability faz de diferente

Começa pela topologia

O agente instalado em cada cluster coleta topologia, eventos, logs, mudanças e métricas, e o SUSE Observability monta com isso um mapa vivo: quais serviços existem, em quais pods e nós rodam e de quem dependem. Os sinais de saúde ficam presos a esse mapa, então um alerta não chega solto, chega dentro do contexto do que está acima e abaixo dele.

Volta no tempo até o momento da falha

A linha do tempo, na parte de baixo da interface, permite viajar de volta ao estado da topologia num ponto do passado e navegar pela telemetria disponível para aquele retrato. Por padrão a visão fica ao vivo, mostrando a última hora; ao escolher um intervalo específico, a topologia é congelada naquele momento.

Para a sua equipe, isso responde à pergunta que mais consome tempo num incidente: o que estava diferente quando o problema começou. Mesmo que o pod já tenha sido substituído, o retrato daquele instante continua lá, dentro do período de retenção configurado.

Monitores com orientação de correção

Os monitores avaliam a saúde dos componentes e já vêm prontos para os casos comuns de Kubernetes. Cada monitor pode trazer um guia de correção, com o que verificar e o que fazer, o que ajuda o plantonista a agir com o mesmo critério da pessoa mais experiente do time.

OpenTelemetry e rastreamento de aplicações

A SUSE descreve o SUSE Observability como nativo em OpenTelemetry. Isso significa que as aplicações instrumentadas com OpenTelemetry enviam traces e métricas que entram no mesmo mapa, junto com a infraestrutura. Você não fica preso a um agente proprietário para a parte de aplicação, e a instrumentação que a sua equipe já fez continua valendo.

Como ele se integra ao Rancher Prime

Para quem já usa o Rancher, a integração é o ponto forte:

  • Incluído na subscrição. Segundo a SUSE, o SUSE Observability está incluído no SUSE Rancher Prime. Para quem prefere não hospedar a plataforma, existe a versão SaaS, chamada SUSE Cloud Observability.
  • Saúde dentro do Rancher. Uma extensão de interface do Rancher mostra os sinais de saúde observados pelo SUSE Observability em cada recurso, com um link direto para investigar a fundo.
  • Implantação no seu Kubernetes. A versão autogerenciada roda num cluster Kubernetes da própria empresa, com um agente em cada cluster monitorado. Clusters em EKS, AKS, GKE, OpenShift e Kubernetes próprio estão entre os ambientes documentados.

Assim, o mesmo painel que a equipe usa para gerenciar os clusters passa a mostrar também se eles estão saudáveis, e a investigação começa a um clique de distância.

Onde ele se encaixa com o que você já tem

O SUSE Observability não exige que você abandone o monitoramento atual. Muitas operações mantêm o monitoramento de rede e de infraestrutura que já funciona bem, como Nagios XI, PRTG ou Checkmk, e usam o SUSE Observability onde a complexidade é maior: os clusters Kubernetes e as aplicações que rodam neles. A escolha certa depende de onde estão hoje os seus incidentes mais demorados.

Onde a Lavineda entra

Você pode contratar a subscrição com a implantação feita pela nossa engenharia e manter a operação com a sua equipe, ou deixar a observabilidade dos clusters e aplicações conosco no Cloud Care. Os detalhes estão em SUSE Observability, e a gestão dos clusters com Rancher está explicada em Kubernetes com Rancher.

Fontes

O próximo passo

Se a primeira hora dos seus incidentes ainda é gasta descobrindo onde olhar, vale conversar. Numa conversa de diagnóstico gratuita, você nos conta como a sua equipe investiga problemas hoje e nós devolvemos um feedback honesto sobre a visibilidade dos seus clusters e aplicações, com próximos passos claros e sem compromisso.