O que são métricas de rede de contêiner?

Cada pod, serviço e nó em um cluster Kubernetes gera atividade de rede constantemente: conexões sendo abertas, pacotes sendo encaminhados ou descartados, consultas DNS sendo resolvidas ou falhando. Compreender essa atividade é essencial para depuração, planejamento de capacidade e para manter os serviços íntegros. Mas a maioria das configurações de monitoramento fica aquém de duas maneiras:

• Visibilidade insuficiente. Os agregados em nível de nó indicam que algo está errado, mas não onde. Sem detalhamentos em nível de pod que incluam o contexto de origem e destino, isolar uma carga de trabalho com falha significa adivinhar.
• Excesso de dados em escala. Um cluster que executa centenas de microsserviços pode produzir milhares de séries temporais de métrica por nó. Coletar tudo aumenta os custos de armazenamento e reduz a velocidade dos painéis.

As métricas de rede de contêineres no Advanced Container Networking Services para AKS (Serviço de Kubernetes do Azure) abordam ambos. O recurso coleta métricas de rede em nível de nó e em nível de pod em planos de dados Cilium e não-Cilium compatíveis, em Linux e Windows.

Em clusters Cilium, você pode ir mais longe com a filtragem no nível do código-fonte, que permite selecionar exatamente quais namespaces, cargas de trabalho e tipos de métrica são coletados antes que os dados saiam do nó.

A filtragem de métricas de contêiner é um controle de pré-ingestão para dados de observabilidade. Em vez de coletar todas as métricas disponíveis e filtrar posteriormente em dashboards ou consultas, você define o que coletar na origem. Isso mantém métricas de alto valor para as cargas de trabalho com as quais você se importa e evita a ingestão de séries temporais barulhentas ou de baixo valor.

O resultado: observabilidade de rede acionável em qualquer plano de dados com suporte, com filtragem opcional econômica no Cilium.

As métricas de rede de contêiner oferecem visibilidade profunda no nível da carga de trabalho para solução de problemas e planejamento, enquanto a filtragem no nível do código-fonte no Cilium ajuda a manter os custos de observabilidade proporcionais a cargas de trabalho críticas aos negócios.

Coleção e filtragem em um relance

Use esta tabela para entender rapidamente onde a ampla coleção está disponível e onde a filtragem refinada está disponível:

Principais benefícios

• Granularidade em nível de nó e pod. Monitore o volume de tráfego, as taxas de descarte e os estados de conexão em nível de nó para avaliar a integridade da infraestrutura. Analise pods individuais com rótulos de origem e destino para identificar a carga de trabalho exata que está causando o problema.

• Solução de problemas mais rápida. Quando um serviço começa a descartar pacotes ou as consultas DNS falham, as métricas no nível do pod permitem isolar o problema em um pod, namespace ou protocolo específico em segundos, não em horas.

• Visualização flexível. Armazene métricas no Azure Managed Prometheus e visualize no Espaço Gerenciado do Azure para Grafana (totalmente gerenciado), ou traga sua própria infraestrutura Prometheus e Grafana.

• Escalonável por design. O pipeline manipula clusters grandes e dinâmicos com centenas de nós e milhares de pods sem exigir que você escolha entre cobertura abrangente e volumes de dados gerenciáveis.

• Observabilidade direcionada (clústeres Cilium). Em clusters Cilium, a filtragem em nível de origem permite definir os namespaces, rótulos de pod ou tipos de métricas que são do seu interesse e coletar apenas esses. Não é necessário nenhum corte pós-coleta.

• Custos de ingestão de métricas mais baixos (clusters Cilium). Como a filtragem ocorre na origem em cada nó, séries temporais de métricas indesejadas nunca são coletadas, transmitidas ou ingeridas no seu backend Prometheus. Você paga apenas pelas métricas de que realmente precisa. Em grandes clusters, onde a coleção não filtrada pode produzir milhares de séries temporais por nó, a filtragem no nível do código-fonte pode reduzir significativamente os custos de ingestão e armazenamento do Azure Managed Prometheus.

Como funciona

A pilha do agente em cada nó depende do plano de dados, conforme mostrado no diagrama.

Os nós Linux Cilium usam uma pilha em camadas baseada em eBPF: os hooks do kernel eBPF capturam dados de tráfego brutos, o Cilium os processa e o Hubble os expõe como métricas no formato Prometheus. Como o Hubble fica entre o nó e o ponto de extremidade de coleta, a filtragem em nível de origem é executada nessa camada — você seleciona quais namespaces, rótulos de pod e tipos de métricas são exportados antes que os dados saiam do nó.

Os nós Linux não-Cilium usam hooks do kernel eBPF que alimentam o Microsoft Retina, com uma camada Hubble por cima para inspeção de fluxo. O Microsoft Retina gerencia a coleta de métricas e exporta métricas de nível de nó e de pod no formato Prometheus.

De todos os caminhos, as métricas são coletadas no formato Prometheus e ingeridas no Prometheus Gerenciado do Azure ou em seu próprio backend Prometheus, sendo então visualizadas no Espaço Gerenciado do Azure para Grafana ou em sua própria pilha Grafana.

Para começar, configure as métricas de rede de contêiner e configure a filtragem de métricas de rede de contêiner para clusters Cilium.

Quando usar métricas de rede de contêiner

As métricas de rede de contêiner são projetadas para equipes que precisam de dados de rede focalizados e acionáveis em vez de telemetria bruta. Cenários comuns incluem:

• Depurando uma carga de trabalho específica. Use as métricas de nível de pod para isolar perdas de pacotes, redefinições de TCP ou falhas de DNS para um serviço específico. Em clusters Cilium, a filtragem pode restringir a coleta apenas a um namespace ou rótulo de pod específico, eliminando o ruído em todo o cluster.
• Monitorando clusters multilocatários. Acompanhe a integridade da rede por namespace para que cada equipe tenha visibilidade de seus próprios padrões de tráfego. Em clusters Cilium, a filtragem com escopo definido mantém a coleção limitada aos namespaces específicos do locatário.
• Planejamento de capacidade. Rastreie a contagem de bytes encaminhados e descartados por nó para identificar links saturados ou alocação desequilibrada de carga de trabalho.
• Monitoramento da integridade do DNS. Exiba falhas de consulta DNS e tempos de resolução lentos para detectar problemas antes que se transformem em erros de aplicativo.
• Reduzindo os custos de observabilidade em escala. Em clusters grandes, a coleta sem filtro pode gerar milhares de séries temporais por nó. Em clusters Cilium, a filtragem no nível do código-fonte remove séries indesejadas antes da ingestão para que os custos permaneçam alinhados com as cargas de trabalho e os tipos de métrica escolhidos.

Como escolher o que coletar (clusters do Cilium)

Use este modelo de distribuição para equilibrar a visibilidade e o custo:

1. Comece com uma coleção ampla em um namespace de não produção para estabelecer uma linha de base.
2. Mantenha métricas de descarte de pacotes, DNS e estado TCP para namespaces críticos.
3. Limite as métricas de fluxo de alta cardinalidade apenas às cargas de trabalho críticas para os negócios.
4. Revisar as tendências de ingestão do Prometheus e refinar filtros semanalmente.

Essa abordagem ajuda você a manter métricas de alto valor, controlando o crescimento das séries temporais e os custos de ingestão.

Antes de examinar as tabelas de métricas

Tenha estes pontos em mente:

• As métricas em nível de nó estão disponíveis em planos de dados Cilium e não Cilium compatíveis.
• Métricas no nível do pod estão disponíveis no Linux.
• A filtragem no nível do código-fonte está disponível somente em clusters Cilium.
• Em clusters Cilium, as métricas DNS exigem uma política de rede Cilium FQDN.

Referência de métricas

Métricas no nível do nó

As métricas em nível de nó fornecem estatísticas de tráfego agregadas por nó — pacotes encaminhados e descartados, contagens de bytes e estados de conexão. Essas métricas são armazenadas no formato Prometheus e podem ser visualizadas no Grafana.

As métricas a seguir são agregadas por nó. Todas as métricas incluem estes rótulos:

• cluster
• instance (nome do nó)

Métricas de nível de pod (Métricas do Hubble)

As métricas no nível do pod incluem informações de pod de origem e de destino, para que você possa identificar problemas de rede no nível de carga de trabalho individual. Essas métricas abrangem volume de tráfego, pacotes descartados, redefinições de TCP e fluxos de Camada 4/Camada 7.

As métricas DNS (contagens de consulta, códigos de resposta e erros) são coletadas por padrão em planos de dados não Cilium. Em planos de dados Cilium, as métricas DNS exigem uma política de rede Cilium FQDN. Você também pode solucionar problemas de DNS em tempo real usando a CLI do Hubble.

A tabela a seguir descreve as métricas agregadas por pod (as informações do nó são preservadas).

Todas as métricas incluem etiquetas:

• cluster

• instance (nome do nó)

• source ou destination

  • Para tráfego de saída, um source rótulo indica o namespace e o nome do pod de origem.

  • Para o tráfego de entrada, um destination rótulo indica o nome e o namespace do pod de destino.

Limitations

Plataforma e plano de dados:

• As métricas no nível do pod estão disponíveis apenas no Linux.
• Há suporte para o plano de dados Cilium a partir do Kubernetes versão 1.29.
• A filtragem de métricas no nível do código-fonte só está disponível em clusters Cilium.
• Os rótulos de métrica têm diferenças sutis entre os clusters Cilium e não Cilium.

Métricas DNS:

• Em clusters Cilium, as métricas DNS exigem uma política de rede Cilium FQDN ou você pode usar a CLI do Hubble para solução de problemas de DNS em tempo real.

Problemas conhecidos:

• Se um agente de nó do Hubble falhar, o relay do Hubble poderá travar, o que pode interromper as sessões da CLI do Hubble.

Suporte a FIPS (somente planos de dados não Cilium):

• O FIPS não está disponível nos nós do Ubuntu 20.04 devido a restrições de kernel. Prefira usar um pool de nós do Azure Linux. Essa limitação não se aplica a planos de dados Cilium. Para obter atualizações, consulte o rastreador de problemas do AKS.

Escala:

• O serviço gerenciado para Prometheus no Azure Monitor e no Espaço Gerenciado do Azure para Grafana impõe limitações específicas de escala do serviço. Para obter mais informações, confira Extrair métricas do Prometheus em escala no Azure Monitor.

Pricing

Para obter mais informações sobre preços, consulte Serviços Avançados de Rede de Contêineres – Preços.

Conteúdo relacionado

• Configurar métricas de rede de contêiner
• Configurar a filtragem de métricas de rede de contêiner
• Serviços avançados de rede de contêiner para AKS
• Observabilidade de rede de contêiner em serviços avançados de rede de contêiner
• Segurança de rede de contêiner em serviços avançados de rede de contêiner