Observabilidade no NKPParte 1: os conceitos

Resumo: monitoramento responde se algo está quebrado; observabilidade responde por quê. Esta parte junta os conceitos que uso com clientes (pilares, métodos, SLO e custo) e mostra o que o NKP 2.19 já entrega. No lab, o cluster de workload tinha só métricas. Ligar os logs pelo catálogo levou quatro apps e cerca de 30 minutos, incluindo um storage Ceph completo. E o Alertmanager, ligado desde o primeiro dia, estava disparando alertas para ninguém. Esta é a parte 1 de 3.

Por que esta série

Depois do upgrade do NKP para a 2.19, a pergunta seguinte dos clientes foi quase sempre a mesma: “e como eu vejo o que está acontecendo dentro do cluster?”. A resposta curta é que o NKP já traz muita coisa. A resposta longa tem conceitos, escolhas e alguns cuidados, e virou esta série.

Tudo foi testado no lab de IA da Clear IT: um cluster de management e um cluster de workload em NKP 2.19, sobre Nutanix AHV.

Monitoramento × observabilidade

Os dois termos aparecem como sinônimos, mas respondem perguntas diferentes.

Monitoramento é um subconjunto de observabilidade. Você continua precisando dos alertas; a diferença é ter dados suficientes para investigar o que o alerta não explica.

Os pilares

Em Kubernetes, os eventos funcionam na prática como um quarto pilar: um OOMKilled ou um FailedScheduling explica muita coisa antes de qualquer dashboard. O valor de verdade aparece quando os sinais se ligam. Na Parte 3, um clique num trace com erro abre os logs daquela mesma requisição.

O que medir: três métodos

Medir tudo é caro e confuso. Estes métodos ajudam a escolher o mínimo útil.

Uma regra prática: RED para as aplicações, USE para os nós e o storage. Os dashboards que o NKP traz prontos cobrem bem o USE; o RED depende de instrumentar as aplicações, que é o assunto da Parte 3.

SLI, SLO e error budget

É aqui que observabilidade vira conversa de negócio.

Com um SLO definido, o alerta deixa de ser “a CPU subiu” e passa a ser “estamos gastando o orçamento de erro rápido demais”. Isso reduz alerta inútil e dá um critério claro para decidir entre lançar funcionalidade nova ou investir em estabilidade.

OpenTelemetry: o padrão aberto

O OpenTelemetry é um projeto da CNCF que padroniza como as aplicações geram métricas, logs e traces e como esses dados são transportados. A ideia central: instrumentar uma vez e mandar para qualquer ferramenta, aberta ou paga.

Na prática, ele tira o lock-in da camada de instrumentação. Trocar de backend passa a ser uma mudança de configuração no Collector, não uma reescrita do código. O NKP 2.19 traz o OpenTelemetry Operator no catálogo, e ele é o tema da Parte 3.

As ferramentas do mercado

Uma visão neutra do que se encontra. Não existe a melhor; existe a que encaixa no time, no orçamento e nas regras de retenção de cada empresa.

Os critérios que eu uso para escolher:

Muitas empresas acabam num modelo misto: a pilha aberta da plataforma para o dia a dia e uma ferramenta paga para as aplicações mais críticas.

O custo da observabilidade

Observabilidade não é de graça, mesmo com ferramentas abertas. O custo vem de três lugares:

• Cardinalidade das métricas: cada combinação de rótulos vira uma série. Um rótulo com o ID do usuário pode multiplicar as séries por milhões.
• Volume e retenção de logs: log de debug ligado em produção enche o storage rápido.
• Recursos do cluster: cada componente da pilha consome CPU, memória e disco.

No lab, o Prometheus do management usava cerca de 5,9 GiB de memória sozinho, com retenção de 10 dias em um volume de 100 GiB. E, ao final desta série, depois de ligar logs, Insights e OpenTelemetry no cluster de workload, a CPU reservada (requests) do cluster foi de 27,1% para 72,5%. Observabilidade precisa entrar no dimensionamento desde o começo.

O que o NKP já entrega ligado

Antes de habilitar qualquer coisa, rodei um inventário só de leitura nos dois clusters. A diferença entre eles foi o primeiro achado.

O cluster de workload vem com métricas, mas sem logs. Para quem roda as aplicações ali, faltava justamente o sinal mais usado no dia a dia.

O Grafana do workload já mostrava os dashboards de recursos funcionando, com um detalhe que vale um alerta para qualquer cliente: os limites de CPU do namespace kube-system somavam 161% do que o cluster tem.

No catálogo, a categoria Observability tem dois apps, os dois desligados por padrão. Eles são os temas das partes 2 e 3.

No lab: ligando os logs no cluster de workload

Objetivo: ter os logs de todos os pods do cluster de workload no Grafana, usando só o catálogo do NKP.

O caminho dos logs no NKP é este:

São quatro apps no catálogo, e um depende do outro:

O atalho que não funcionou

Comecei pelo Grafana Logging e fui aceitando as dependências que a interface mostrava. Ao habilitar o Loki, o NKP avisou que faltavam duas: Rook Ceph Cluster e Logging Operator. O aviso deixa seguir mesmo assim, e eu segui, para ver o que acontecia.

O app ficou Enabled na interface. Os pods, não:

grafana-loki-v3-ingester-zone-a-0   0/1   CreateContainerConfigError
...
Warning  Failed  kubelet  Error: secret "dkp-loki" not found

O Secret dkp-loki guarda a credencial do bucket onde o Loki grava. Quem cria esse bucket é o Rook Ceph Cluster, e ele não existia. Repare num detalhe que confunde: Rook Ceph e Rook Ceph Cluster são apps diferentes. O primeiro é só o operador; o segundo é que cria o cluster de storage.

Na ordem certa

Habilitei as dependências que faltavam. O Logging Operator subiu em cerca de um minuto: um operador, 6 Fluent Bit (um por nó) e um Fluentd. O Rook Ceph Cluster levou mais, porque monta um storage inteiro em cadeia: monitores, gerenciadores, discos e o gateway S3.

O Ceph criado pelo app usa volumes do storage padrão do cluster e entregou 160 GiB brutos, com 4 discos de dados nos 3 workers, 2 gateways S3 e erasure coding 3+1 para os dados dos buckets. Ele criou dois buckets: o do Loki e um para o Velero.

Os logs que chegaram antes do Loki

No Grafana Logging, os logs de kube-system apareceram a partir de 00:20, uns 12 minutos antes de o Loki ficar pronto. A explicação estava no log do Fluentd:

[warn]: ... failed to flush the buffer. retry_times=0 ... error="502 Bad Gateway"
[warn]: ... failed to flush the buffer. retry_times=1 ...

O Fluentd tentou entregar, recebeu 502 do gateway do Loki, guardou os logs num buffer em disco e foi tentando de novo. Quando o Loki subiu, entregou o que estava guardado. Nada se perdeu.

Os alertas que não avisavam ninguém

O Alertmanager vem ligado nos dois clusters. No workload, havia 5 alertas disparados:

O KubeProxyDown é alarme falso porque o cluster não tem kube-proxy: o Cilium faz esse papel.

$ kubectl -n kube-system get ds kube-proxy
Error from server (NotFound): daemonsets.apps "kube-proxy" not found
$ kubectl -n kube-system get cm cilium-config -o jsonpath='{.data.kube-proxy-replacement}'
true

E o mais importante estava na configuração padrão:

route:
  receiver: "null"
receivers:
- name: "null"

O único destino configurado é o "null". Os alertas disparam e não vão para ninguém: nem e-mail, nem Slack, nem Teams. Junto com um alerta crítico falso há dois dias, é o cenário que ensina uma equipe a ignorar alertas.

E para IA?

A mesma lógica vale para as cargas de IA, com sinais próprios:

O OpenTelemetry já tem convenções específicas para IA generativa, para registrar modelo, tokens e latência de forma padronizada.

Um modelo de maturidade

Para situar onde cada cliente está:

As partes 2 e 3 levam o lab do nível 2 para o 3.

O que aprendi

1. O workload vem só com métricas. Logs e traces precisam ser habilitados, e isso tem custo.
2. O aviso de dependência deixa seguir, e o resultado é um app “Enabled” que não funciona. Confira os pods depois de cada Enable.
3. Rook Ceph e Rook Ceph Cluster são apps diferentes. O primeiro é o operador; o segundo é o storage.
4. O buffer do Fluentd segura os logs quando o destino cai. É resiliência que vem de fábrica.
5. Alerta sem destino não protege nada, e alerta crítico falso ensina a ignorar alertas.
6. Observabilidade consome recursos. Ela entra no dimensionamento, não depois dele.

Checklist de observabilidade básica no NKP

• Inventário do que já está ligado em cada cluster
• Logs habilitados nos clusters de workload, com as dependências na ordem
• Pods conferidos depois de cada Enable, não só o card do app
• Pelo menos um destino real configurado no Alertmanager
• Watchdog ligado a um serviço externo de “dead man’s switch”
• Regras que não se aplicam ao ambiente ajustadas ou silenciadas
• Retenção de métricas e logs definida por regra de negócio
• Consumo da pilha de observabilidade no dimensionamento do cluster

Referências

• Site Reliability Engineering, capítulo 6: Monitoring Distributed Systems (Google)
• The USE Method (Brendan Gregg)
• OpenTelemetry
• Grafana Loki
• Logging Operator (Kube Logging)
• Rook
• Nutanix Kubernetes Platform Guide 2.19 (portal Nutanix)