Mapa de leituraDo sinal de uma decisão operacional
  1. 01Entender
  2. 02Priorizar
  3. 03Actuar

Kubernets automatiza deslumbres e recuperação, mas também multiplica componentes efímeros, etiquetas e relações. Um pod que desaparece pode ser levado à prova do problema; um clúster “verde” pode alojar uma aplicação lenta. observabilidade Kubernets deve conectar plataforma e experiência, não apenas contar pods.

As cinco camadas a observar

1. Experiência do usuário

Disponibilidade, erros e latência das transacções críticas. É a camada que determina impacto. Pode ser medida com RUM, sintéticos e métricas de aplicação.

2. Aplicações e serviços

Taxa, erros, duração, dependências e traços. Deve incluir a versão expandida, namespace, serviço e proprietário.

3. Workloads

Deployments, StatefulSets, DaemonSets, Jobs e Pods. Importam reinícios, estados pendentes, erros de imagem, provas e limites.

4. Nós e recursos

CPU, memória, disco, rede, pressão, capacidade atribuível e saturação. Deve distinguir o uso real de requestos e limites configurados.

5. Controlo Plano

API servidor, scheduler, controllers e etcd. A sua degradação pode afetar alterações, escala e recuperação, embora as aplicações continuem a responder por um tempo.

Metricas: começar por sintomas

As métricas de Kubernetes são expostas a partir de componentes, cubelet e ferramentas como cube-state-metrics. O risco é converter cada métrica em alerta.

Prioridade:

  • Latência e erros de serviços críticos.
  • Podes não estar disponível em relação ao estado desejado.
  • Reiniciais persistentes e CrashLoopBackOff.
  • Workloads pendentes por falta de recursos ou restrições.
  • Saturação e pressão de nós.
  • Erros e latência da API do servidor.
  • Saúde de etcd e latência de armazenamento.
  • Perda ou atraso da pipelina de telemetria.

Um alerta deve indicar impacto ou risco próximo e ter responsabilidade. O resto pode ficar disponível para diagnóstico.

Logs: a evidência desaparece com o pod

Conteúdos normalmente escrevem para stdout y stderr; o runtime e kubet administram arquivos no nó. Kubernetes não oferece um armazenamento central duradouro. É necessário um agente ou coletor que encaminha os registos antes que o nó se desapareça.

Boas práticas:

  • Logs estruturados em JSON.
  • Timestamp e severidade consistentes.
  • service.name, ambiente, versão, namespace e pod.
  • trace_id y span_id para correlação.
  • Edição de segredos e dados pessoais.
  • Limites de volume e de retenção por categoria.

Não uses os nomes do pod como identidade principal: muda. A identidade deve representar o serviço e a versão.

Traços: seguir um pedido entre pods

Os traços distribuídos mostram como um pedido através de entrada, serviços, filas e bases de dados. OpenTelemetry pode instrumentar aplicativos e enviar OTLP a um coletor expandido no clúster.

Um traço útil permite- lhe responder:

  • Onde se acrescentou a latência?
  • Que dependência falhou?
  • A falha afecta uma versão ou uma zona?
  • Há rentros que amplificam a carga?
  • Que logs correspondem à transacção?

Sem propagação de contexto, cada micro-serviço aparece como uma ilha.

Arquitectura de Colecção

Um padrão comum combina:

  • ServidorSet para telemetria por nó, logs e métricas locais.
  • Gateway Collector para processamento, amostragem e exportação.
  • Prometheus para escraping de métricas.
  • Infraestrutura de registos e traços, gerenciado ou autogestionado.

O desenho deve contemplar picos, backpressure, rententes, memória e comportamento quando o mecanismo não está disponível. A observabilidade não deve abranger a aplicação que tenta observar.

Cardinalidade: o custo oculto das marcas

Kubernets adiciona dimensões úteis —cluster, namespace, pod, container—, mas combinar-as com IDs únicos pode multiplicar séries.

  • UID de pod e container.
  • Caminhos HTTP não parametrizados.
  • IDs do usuário, o utilizador necessita da sessão.
  • Labirintos criados dinâmicamente.
  • Histogramas com demasiados buckets.

Conservar detalhes em registos ou traços quando não necessário como rótulo mecânico.

Dashboard mínimo de Kubernets

Um dashboard operacional deverá mostrar:

  1. SLO e sinais RED de aplicativos críticos.
  2. Estado desejado vs disponível de workloads.
  3. Podes estar pendente, falhada e reinício.
  4. Capacidade e pressão por nó e espaço.
  5. Erros e latência do controlo plano.
  6. Mudanças e desenvolvimentos recentes.
  7. Saúde e perda da pipelina de telemetria.

A visão executiva da plataforma será separada. Um gerente precisa de impacto e tendência; um SRE precisa de detalhes para agir.

Multi-cluster: manter um contexto sem multiplicar tabuleiros

Quando existem vários clústers, copiar o mesmo dashboard para cada um dificulta comparar e agregar manutenção. Normalizar atributos como organização, conta, região, clúster, ambiente e equipamento. Depois permitiu filtrar de uma visão global para o detalhe.

Não centralize tudo sem avaliar conectividade e isolamento. Uma pipeline regional pode reduzir a transferência e manter a operação quando falhar a ligação central. Para serviços regulamentados, a residência de registos e traços pode exigir backends ou retençãos diferentes.

Além disso, medi a saúde por clúster do Collector, atrasos de exportação e volume descartado. Se uma região deixar de enviar telemetria, uma visão global poderia interpretar a ausência de dados como ausência de incidentes.

Erros Frequentes

  • Alerta por cada reinicio sem considerar o estado final.
  • Observar nós, mas não transacções.
  • Manter os registos sem limites.
  • Usar os dashboards importados sem adaptá- los ao SLOs.
  • Não etiquetar os responsáveis.
  • Ignorar o custo de cardinalidade.
  • Não provar o que acontece quando o coletor falha.

Antes de expandir a marca, executa um teste: remover um pod, saturar uma dependência em um ambiente controlado e simular indisponibilidade do motor. A equipa deve identificar impacto, serviço e causa sem depender do nome do pod que já desapareceu. Registará tempo, passos e telemetria faltando; essa evidência define a seguinte melhor melhor do que instalar outro dashboard.

Próximo passo

CTL integra Kubernets com Prometheus, Grafana y OpenTelemetry. Agendar uma avaliação para rever cobertura, alertas e custos.

Perguntas frequentes

Qual é a diferença entre os metroscs-server e o Prometheus?

Metrics Server entrega métrica de recursos para funções como auto-scaling e kubectl top; não é pensado como solução histórica completa. Prometheus recolha e armazena séries para análises e alertas.

É um coletor que se torna clúster?

Depende do volume, isolamento e disponibilidade. Um gateway por clúster simplifica contexto e falhas, enquanto gateways regionais podem centralizar processamento. A arquitetura deve ser testada sob carga.

Como se observa um pod que já desapareceu?

A telemetria deve ser exportada fora do nó e associada a identidades estáveis. Os eventos de Kubernets, logs centralizados e traços conservam provas depois de terminar o pod.

Fontes Verificações