O que são métricas de redes de contentores?

Métricas de rede de contentores no Advanced Container Networking Services for Azure Kubernetes Service (AKS) ajudam-no a identificar quedas de pacotes, rastrear a atividade da rede e investigar o comportamento do DNS. Comece com métricas ao nível dos nós para encontrar um problema de saúde da rede, depois use métricas ao nível dos pods para identificar as cargas de trabalho envolvidas.

A recolha de métricas está disponível nos planos de dados Cilium e não Cilium suportados. Métricas ao nível dos pods requerem Linux; as tabelas de referência mostram quais métricas ao nível dos nós também estão disponíveis no Windows.

Recolha de métricas: visão geral

Utilize esta tabela para verificar o suporte à recolha de métricas entre planos de dados:

Para a recolha inicial, siga Configurar métricas de rede de contentores. Para registos de detalhes individuais de tráfego em vez de contadores, use registos de rede do contentor.

Principais benefícios

• Granularidade ao nível de nós e de pods. Acompanhe o volume de tráfego, as taxas de queda e os estados de ligação ao nível do nó para a saúde da infraestrutura. Analisa cada pod individual com etiquetas de origem e destino para identificar exatamente a carga de trabalho que está a causar o problema.

• Resolução de problemas mais rápida. Quando um serviço começa a perder pacotes ou as consultas DNS falham, métricas ao nível do pod ajudam a isolar o problema num pod, namespace ou protocolo específico.

• Visualização incorporada. Armazene métricas no serviço gerido Azure Monitor para Prometheus e abra dashboards de rede diretamente no portal Azure com Dashboards com Grafana. A experiência do dashboard é gratuita e não requer uma instância Azure Managed Grafana; ACNS e taxas de ingestão e armazenamento de métricas continuam a aplicar-se. Também podes usar uma implantação separada do Grafana.

Como funciona

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

Os nós Cilium do Linux usam uma pilha em camadas baseada em eBPF: os hooks do kernel eBPF capturam dados de tráfego brutos, o Cilium processa-os e o Hubble expõe-os como métricas no formato Prometheus.

Nós não-Cilium do Linux usam ganchos de kernel eBPF que alimentam o Microsoft Retina, com uma camada Hubble por cima para inspeção de fluxo. O Microsoft Retina gere a recolha de métricas e exporta métricas ao nível dos nós e pods no formato Prometheus.

De todos os caminhos, recolhe métricas no formato Prometheus e ingere-as no serviço gerido Azure Monitor para Prometheus ou no seu próprio backend Prometheus. Para o caminho gerido, abra o seu cluster AKS no portal Azure e selecione Monitorização> para visualizar os painéis de rede. Azure Managed Grafana e a sua própria implementação de Grafana são alternativas opcionais. Veja Utilizar dashboards com o Grafana no AKS.

Para começar, configure métricas de rede de contentores.

Quando usar métricas de rede de contentores

As métricas de redes de contentores são concebidas para equipas que necessitam de dados de rede focados e acionáveis, em vez de telemetria bruta. Cenários comuns incluem:

• Depurar uma carga de trabalho específica. Use métricas ao nível do pod para isolar quedas de pacotes, resets TCP ou falhas DNS para um serviço específico.
• Monitorização de clusters multitenant. Use métricas ao nível dos pods para acompanhar a saúde da rede por namespace e compreender os padrões de tráfego de cada equipa.
• Planeamento de capacidade. Rastreie as contagens de bytes encaminhados e perdidos por nó para identificar ligações saturadas ou colocação desequilibrada da carga de trabalho.
• Monitorização da saúde do DNS. Falhas nas consultas DNS do Surface e tempos lentos de resolução para detetar problemas antes que se transformem em erros de aplicação.

Antes de rever as tabelas de métricas

Tenha em consideração estes pontos:

• Métricas ao nível dos nós estão disponíveis em planos de dados Cilium e não-Cilium suportados.
• Métricas ao nível dos pods estão disponíveis no Linux.
• Nos clusters Cilium, as métricas DNS requerem uma política de rede Cilium FQDN.

Referência de métricas

Métricas no nível do nó

Métricas ao nível do nó fornecem estatísticas agregadas de tráfego por nó — pacotes encaminhados e perdidos, contagem de bytes e estados de ligação. Estas métricas estã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ó)

Cilium

Para clusters de planos de dados Cilium, métricas ao nível dos nós estão disponíveis apenas no Linux. O Cilium expõe as seguintes métricas utilizadas pelas métricas de redes de contentores:

Não-Cílio

Para cenários de planos de dados não relacionados com Cilium, métricas de rede de contentores estão disponíveis tanto para Linux como para Windows.

Métricas no nível do pod (métricas do Hubble)

Métricas ao nível do pod incluem informação de origem e de destino do pod, para que possa identificar problemas de rede ao nível da carga de trabalho individual. Estas métricas abrangem volume de tráfego, pacotes perdidos, resets TCP e fluxos da Camada 4/Camada 7.

Métricas DNS (contagens de consultas, códigos de resposta e erros) são recolhidas por defeito em planos de dados que não são Cilium. Nos planos de dados Cilium, as métricas DNS requerem uma política de rede Cilium FQDN. Também podes resolver problemas de DNS em tempo real usando a CLI do Hubble.

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

Todas as métricas incluem rótulos:

• cluster

• instance (nome do nó)

• source ou destination

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

  • Para o tráfego recebido, uma destination etiqueta indica o espaço de nomes e o nome do pod de destino.

Escolha quais métricas recolher nos clusters de Cilium

Nos clusters Cilium, utilize filtragem ao nível da fonte para selecionar que observações contribuem para métricas individuais do Hubble antes de chegarem ao seu backend de monitorização. Esta filtragem é diferente de filtrar um dashboard do Grafana, que muda apenas o que vês. Restrinja a recolha a uma aplicação e, depois, ative seletivamente métricas de IP externo ou de porta de destino quando uma investigação precisar desse detalhe.

A filtragem pode reduzir a recolha desnecessária e ajudar a controlar os custos de ingestão. Métricas adicionais podem aumentar a contagem de séries temporais e o custo, por isso verifique o seu valor e volume antes de as expandir. Séries e amostras históricas criadas anteriormente podem permanecer visíveis; a redução de custos depende do seu tráfego e configuração.

Quando ativa a Observabilidade da Rede de Contentores, os agentes expõem as métricas de rede padrão do serviço. Nos clusters Cilium, utilize um ContainerNetworkMetric recurso personalizado para selecionar tráfego para tipos de métricas individuais.

Disponibilizar uma métrica no cluster não a torna automaticamente disponível no serviço gerido do Azure Monitor para Prometheus. Por defeito, os agentes do cluster expõem hubble_flows_processed_total, mas o Prometheus gerido exclui-o da coleção porque pode produzir um grande número de séries temporais. O Prometheus gerido também exclui hubble_flows_to_world_total e hubble_port_distribution_total por defeito, mesmo quando os ativa no cluster. Para recolher e consultar qualquer uma destas métricas, adicione o seu nome à lista de permissão do Hubble no ama-metrics-settings-configmap ConfigMap. Para ver os passos, consulte Permitir as famílias de métricas no Prometheus gerido.

Existe um recurso partilhado ContainerNetworkMetric por cluster, chamado container-network-metric. Coordenar atualizações com outros administradores e preservar as definições de métricas usadas por outras equipas.

Comece por filtros de inclusão para selecionar tráfego para uma aplicação ou destino. Os filtros de exclusão são opcionais: utilize-os para omitir um subconjunto do tráfego selecionado, ou utilize filtros apenas de exclusão para manter uma recolha ampla com exceções específicas. Uma exclusão tem precedência sobre uma inclusão correspondente.

A filtragem não se limita às métricas opcionais de mundo e de porta de destino. Use os seguintes nomes de configuração para métricas existentes:

Estes filtros aplicam-se quando a métrica está presente na configuração base do serviço. A configuração do filtro e a geração de observações são separadas: as observações de métricas DNS requerem uma política de inspeção DNS aplicada e tráfego DNS. As observações métricas HTTP requerem a habilitação L7 ao nível do cluster, uma política de inspeção HTTP aplicada à carga de trabalho e tráfego HTTP através dessa política. O estado do filtro não confirma estes pré-requisitos. A filtragem não permite a inspeção nem a desencriptação do tráfego HTTPS. Para HTTP, use o nome sensível a maiúsculas e minúsculas httpV2, não http.

Para exemplos, veja DNS, TCP, HTTP e drop filtering.

Por exemplo, use filtros de inclusão para selecionar métricas de fluxo para tráfego TCP do namespace production para os endpoints que a Cilium classifica como world. Isto altera a recolha de métricas de fluxo sem alterar a recolha para outros tipos de métricas. Os filtros suportam nomes de namespace e pods, rótulos, endereços IP, identidades de segurança Cilium, protocolos e vereditos.

O filtragem controla quais as observações que contribuem para uma métrica. Não adiciona nem remove etiquetas métricas. Ao contrário dos campos adicionais de agregação para registos, as dimensões métricas continuam geridas pelo serviço.

A filtragem afeta novas observações métricas na origem. Selecionar uma carga de trabalho no Grafana altera os resultados apresentados, não a configuração da coleção. Os dados previamente recolhidos permanecem no backend das suas métricas.

Métricas adicionais

Para recolher qualquer uma das métricas seguintes, adicione uma entrada ao recurso do ContainerNetworkMetric cluster com filtros de inclusão que selecionam o tráfego que pretende monitorizar. Se a métrica ainda não estiver ativada, a entrada ativa-a para o tráfego selecionado. Se já estiver ativado, a entrada filtra qual o tráfego que contribui para ela sem alterar os rótulos ou opções existentes.

Para métricas recentemente ativadas através deste recurso, o serviço configura as etiquetas do pod de origem e do IP de destino para flows-to-world. Para port-distribution, configura os rótulos dos pods de origem e destino e a direção do tráfego. Os rótulos do protocolo e do veredicto estão incluídos para flows-to-world; os rótulos do protocolo e da porta de destino estão incluídos para port-distribution. Com estas opções fornecidas pelo serviço, a métrica global não conta o tráfego UDP nem as quedas não relacionadas com políticas.

Estas métricas contam eventos de rede observados, não ligações únicas ou pedidos de aplicação. Por exemplo, se um cliente enviar um pacote TCP SYN e depois o retransmitir enquanto tenta ligar-se, hubble_flows_to_world_total pode contar ambas as observações mesmo que pertençam à mesma tentativa de ligação. Rótulos, como nomes de pods, só são preenchidos quando essa informação está disponível para o tráfego observado.

Para um recurso personalizado completo e capturas de ecrã de ambas as métricas recolhidas a partir de uma carga de trabalho de teste, consulte Exemplo de configuração e resultados capturados.

Gerir a relevância e o ruído dos dados

Utilize a filtragem para focar métricas nas cargas de trabalho e no tráfego relevantes para a sua monitorização ou investigação. Excluir tráfego não relacionado reduz o ruído dos dados e ajuda-o a focar-se nos sinais de rede que importam.

Endereços IP de destino, nomes de pods e portas podem produzir muitas séries temporais. Este detalhe pode ser útil, mas recolhê-lo para tráfego não relacionado adiciona ruído e pode aumentar os custos de ingestão. Comece com uma carga de trabalho ou namespace específico, veja se as métricas respondem às suas perguntas e verifique o volume de dados resultante antes de expandir a coleção.

O recurso personalizado reporta um aviso para cada métrica extra ativada. O aviso identifica um potencial aumento de custo; não estima a sua fatura nem indica que um limite foi ultrapassado. O serviço gere etiquetas métricas e não podes alterá-las através deste recurso.

Remover uma entrada só desativa a métrica se essa entrada for a que a habilitou. Se o serviço disponibilizar a métrica, continuará ativo sem os filtros dessa entrada. Eliminar o recurso partilhado remove todos os seus filtros e restaura a recolha fornecida pelo serviço, o que pode alargar o tráfego incluído nessas métricas e aumentar o ruído dos dados e o volume de ingestão.

Para exemplos de YAML, consultas de verificação e passos de limpeza, consulte Configurar filtragem de métricas de rede de contentores.

Limitations

Plataforma e plano de dados:

• As métricas de nível de pod estão disponíveis apenas no Linux.
• O plano de dados Cilium é suportado a partir do Kubernetes versão 1.29.
• A filtragem de métricas ao nível da fonte está disponível apenas em clusters Cilium.
• As entradas de filtro podem ativar flows-to-world e port-distribution quando o serviço ainda não as fornece. O serviço gere as suas etiquetas; este recurso não expõe dimensões métricas personalizadas.
• Os rótulos métricos têm diferenças sutis entre clusters de Cilium e não-Cilium.

Métricas DNS:

• Nos clusters Cilium, métricas DNS requerem uma política de rede Cilium FQDN, ou pode usar a CLI do Hubble para resolução de problemas DNS em tempo real.

Problemas conhecidos:

• Se um agente de nó do Hubble falhar, o relé do Hubble pode falhar, o que pode interromper as sessões de CLI do Hubble.

Suporte FIPS (apenas planos de dados não-Cilium):

• O FIPS não está disponível nos nós Ubuntu 20.04 devido a restrições do kernel. Em vez disso, utilize um conjunto de nós do Azure Linux ou do Ubuntu 22.04. Esta limitação não se aplica aos planos de dados Cilium.

Dimensionamento:

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

Pricing

Para obter mais informações sobre preços, consulte Advanced Container Networking Services - Pricing.

Conteúdo relacionado

• Configurar métricas de rede de contentores
• Configurar a filtragem de métricas de rede de contentores
• Serviços Avançados de Rede de Contentores para AKS
• Observabilidade de Redes de Contentores em Serviços Avançados de Redes de Contentores
• Segurança de Redes de Contentores em Serviços Avançados de Redes de Contentores