O que são logs de rede de contêineres?

Os logs de rede de contêiner no Advanced Container Networking Services para AKS (Serviço de Kubernetes do Azure) dão visibilidade a cada fluxo de rede dentro do cluster. As métricas informam o que está acontecendo em sua rede (uso de largura de banda, taxas de erro). Os logs informam por que: quem iniciou uma conexão, quais protocolos foram usados e se o tráfego foi permitido ou bloqueado.

Esses logs capturam metadados para cada fluxo de rede:

• Endereços IP de origem e de destino, nomes de pod e nomes de serviço
• Namespaces, portas e protocolos
• Direção do tráfego e veredictos de política

Com esse contexto, você pode correlacionar o comportamento da rede com cargas de trabalho específicas, solucionar problemas de conectividade, validar políticas de segurança e executar análise forense. Os logs de rede de contêiner abrangem o tráfego de Camada 3 (IP), Camada 4 (TCP/UDP) e Camada 7 (HTTP/gRPC/Kafka).

Para gerenciar o volume e o custo de dados, os logs de rede de contêiner dão suporte à agregação de log de fluxo, que agrupa fluxos semelhantes em registros resumidos em vez de armazenar um registro por evento de conexão. Você mantém os padrões operacionais necessários ao reduzir os custos de armazenamento e ingestão. Para obter mais informações, consulte Agregação de logs de fluxo.

Os logs de rede de contêineres oferecem dois modos:

• Registros armazenados – coleta contínua com filtros personalizados e agregação de fluxos. Melhor para monitoramento e análise de longo prazo.
• Logs sob demanda - Captura em tempo real por meio da CLI do Hubble e da interface do usuário do Hubble. Melhor para solução de problemas ad hoc.

Use logs armazenados quando precisar de registros persistentes para conformidade, análise de tendências ou alertas automatizados. Use logs sob demanda quando estiver resolvendo ativamente um problema de conectividade ou desempenho e precisar de uma visão imediata do tráfego em tempo real.

Logs armazenados

O modo de logs armazenados é habilitado automaticamente sempre que os Serviços Avançados de Rede de Contêiner estão habilitados em um cluster. A funcionalidade está em vigor, mas nenhum log é gerado até que você diga ao ACNS o que capturar.

Para começar a coletar logs, defina ContainerNetworkLog recursos personalizados que especifiquem qual tráfego monitorar: por namespace, pod, serviço, protocolo ou veredicto. Assim que um CRD é aplicado, o agente Cilium começa a gerar fluxos que correspondem aos seus filtros e os grava em cada nó. A coleção permanece ativa até que você remova os CRDs ou desabilite o ACNS.

Como você controla exatamente qual tráfego é registrado por meio de filtros crd, você pode se concentrar nos fluxos que importam e evitar a coleta de dados desnecessários. Combinada com a agregação de logs de fluxo, essa abordagem mantém os custos de armazenamento previsíveis e a análise bem direcionada.

Como funciona o modo de logs armazenados

Os Serviços Avançados de Rede de Contêineres utilizam a tecnologia eBPF com o Cilium para capturar fluxos de rede em cada nó. Depois que o ACNS é ativado e um recurso personalizado ContainerNetworkLog é aplicado, o agente Cilium coleta o tráfego que corresponde ao filtro e grava os registros em formato JSON para /var/log/acns/hubble/events.log em cada host. A geração de log é executada inteiramente dentro do cluster e não depende de Azure Monitor.

Para uso em produção, recomendamos habilitar o complemento Azure Monitor. Quando ativados, os agentes de Insights do Contêiner coletam logs locais do host, aplicam limites de restrição e os enviam para um espaço de trabalho do Log Analytics, onde você tem acesso à retenção de longo prazo, consultas KQL e aos painéis integrados do Portal do Azure e do Grafana. Esse é o caminho mais integrado e o que a maioria dos clientes deve escolher.

Se sua equipe já possui um pipeline de observabilidade, você pode, em vez disso, encaminhar os mesmos logs locais do host para qualquer coletor ou serviço de registro compatível com o OpenTelemetry — seja em conjunto com o Azure Monitor ou em seu lugar.

Para obter mais informações sobre limitação de taxa e Insights do Contêiner, consulte a documentação de Insights do Contêiner.

Usando logs de rede de contêiner com ou sem Azure Monitor

Você pode consumir logs de rede de contêiner de duas maneiras. A escolha certa depende se você deseja uma experiência integrada Azure nativa ou já tem um pipeline de observabilidade que deseja continuar usando.

Para a maioria dos clientes, recomendamos habilitar Azure Monitor. É a maneira mais rápida de obter recursos de retenção, consulta e painel sem precisar criar seu próprio pipeline.

Principais recursos do modo de logs armazenados

• Filtros personalizáveis. Defina ContainerNetworkLog recursos personalizados para filtrar por namespace, pod, serviço, porta, protocolo, veredicto ou direção de tráfego. Somente o tráfego correspondente é registrado, portanto, você obtém controle preciso sobre o que é coletado e o que custa.

• Agregação de logs de fluxo. Fluxos semelhantes são agrupados automaticamente em registros resumidos a cada 30 segundos, reduzindo o volume de dados, preservando sinais operacionais como padrões de comunicação de serviço, taxas de erro e veredictos de segurança. Quando emparelhada com filtros direcionados, a agregação permite manter uma visibilidade geral sem acarretar custos excessivos de ingestão. Para obter mais informações, consulte Agregação de logs de fluxo.

• Opções de armazenamento de log. O ACNS sempre grava os logs localmente em cada nó. A partir daí, você pode escolher como consumi-los:

  • Arquivos locais do host (sempre ativados): Os logs são armazenados nos nós de hospedagem em /var/log/acns/hubble. Os arquivos rotacionam automaticamente quando atingem 50 MB, e os logs mais antigos são substituídos. Use isso diretamente para monitoramento de curto prazo, em tempo real, ou encaminhe os arquivos para qualquer coletor ou serviço de log compatível com OpenTelemetry para gerenciamento de log adicional.

  • Azure Monitor (recomendado): habilite o complemento Azure Monitor para coletar e armazenar logs em um workspace Log Analytics. Você obtém armazenamento seguro e compatível com retenção de longo prazo, consultas KQL, detecção de anomalias, análise histórica e alertas por meio do serviço gerenciado do Prometheus. A geração de logs continua sendo feita pelo agente Cilium e o ContainerNetworkLog CRD; o Azure Monitor adiciona uma camada de monitoramento de consumo.

    A ContainerNetworkLogs tabela usa a camada análise por padrão. Você pode alternar para a camada Básica para reduzir os custos de ingestão e retenção, mantendo uma experiência de observabilidade semelhante. Cada camada tem um painel dedicado no portal do Azure, otimizado para os seus recursos de consulta. Para obter mais informações sobre planos de tabela, consulte planos de tabela do Log Analytics. Para saber como definir o plano de tabela, consulte Definir o plano de tabela.

• Visualização no portal Azure. Consultar e analisar logs diretamente no Log Analytics ou usar os dashboards nativos do portal Azure. Um painel dedicado está disponível para cada camada de tabela, portanto, você obtém a mesma experiência de observabilidade, independentemente de qual camada você escolher. Para obter detalhes, consulte Visualizar logs no portal Azure.

Visualizar logs no portal do Azure

Você pode visualizar, consultar e analisar logs de fluxo no portal do Azure no workspace de análise de logs para o cluster.

Os registros de rede de contêineres incluem painéis integrados no Portal do Azure para visualizar dados de fluxo. Um painel separado está disponível para cada camada de tabela Log Analytics:

Ambos os painéis mostram quais cargas de trabalho do AKS estão se comunicando entre si, incluindo solicitações de rede, respostas, quedas e erros. Use o dashboard que corresponde ao nível de tabela configurado para sua tabela ContainerNetworkLogs.

Os painéis do portal Azure têm os seguintes componentes principais:

• Visão geral da integridade da rede. A seção superior mostra métricas de resumo (logs de fluxo totais, solicitações exclusivas, solicitações descartadas e solicitações encaminhadas) para que você possa detectar anomalias rapidamente. As estatísticas são detalhadas por protocolo: solicitações de DNS descartadas, respostas HTTP 2xx, taxas de solicitação e resposta da Camada 4 e contagem de descartes. Um grafo de dependência de serviço mostra quais serviços se comunicam entre si, facilitando a identificação de gargalos e caminhos de tráfego inesperados.

  

• Logs de fluxo e logs de erros. O painel separa os registros de fluxo dos logs de erros em visualizações distintas, para que você possa se concentrar nos erros sem precisar vasculhar o tráfego normal. Use os filtros internos para restringir os resultados por protocolo, namespace ou veredicto. Por exemplo, para diagnosticar falhas na resolução de DNS, filtre os logs de erros utilizando o protocolo DNS.

  

  Cada entrada de log inclui rótulos, carimbos de data/hora e detalhes de origem/destino para ajudá-lo a identificar eventos específicos durante uma investigação.

  

• Principais namespaces, cargas de trabalho e erros de DNS. Esta seção apresenta os namespaces mais ativos, as cargas de trabalho de maior tráfego, o uso da porta e os erros de DNS mais frequentes. Use-o para identificar quais cargas de trabalho geram mais tráfego, detectar solicitações descartadas e comparar a distribuição de protocolo (por exemplo, TCP versus UDP). Padrões incomuns aqui, como picos inesperados ou destinos desconhecidos, podem indicar configurações incorretas ou preocupações com a segurança.

  

Agregação de log de fluxo

Os fluxos de rede aumentam rapidamente. Um cluster com 200 microsserviços pode gerar centenas de milhares de registros de fluxo a cada 30 segundos. Armazenar todos esses dados brutos fica caro.

Por exemplo, digamos que client-1 e client-2 se comuniquem com um pod server via TCP. Em um intervalo de 30 segundos, os registros de fluxo bruto no nó apresentam-se assim:

Com a agregação, esses 10 registros se tornam dois:

A agregação de logs de fluxo aborda essa questão ao agrupar fluxos semelhantes em registros resumidos. Durante cada janela de 30 segundos, fluxos que compartilham os mesmos campos de chave de agregação são combinados em um único registro com uma contagem de quantos fluxos ele representa.

Os seguintes campos compõem a chave de agregação:

Os fluxos que correspondem a todos esses campos em uma janela de 30 segundos são mesclados em um registro. Isso preserva os sinais necessários (quais serviços se comunicam, com que frequência, quais erros ocorrem, se o tráfego foi permitido ou bloqueado) ao cortar significativamente o volume de dados. Ao contrário da amostragem, que descarta fluxos aleatoriamente e pode perder eventos de segurança raros, a agregação retém 100% das informações de padrão.

Pontos principais:

• A agregação está habilitada e configurada por padrão. Isso reduz os custos de armazenamento e ingestão de logs sem necessidade de ajustes manuais.
• Você controla qual tráfego é capturado através de includeFilters no CRD ContainerNetworkLog.
• Filtros mais estreitos (namespace específicos ou pares de serviço) normalmente alcançam melhor compactação porque os fluxos capturados são mais semelhantes.
• Os logs agregados omitem atributos de alta cardinalidade e específicos de cada fluxo (por exemplo, carimbos de data/hora individuais, endereços IP de pods, URLs HTTP, nomes de consultas DNS) para minimizar o volume de ingestão e os custos de armazenamento. Eles foram projetados para detecção de problemas de alto nível. Utilize registros sob demanda para análises detalhadas do fluxo e investigações.

Logs sob demanda

Os logs sob demanda permitem capturar e inspecionar logs de fluxo em tempo real, sem configuração prévia ou armazenamento persistente. Use logs sob demanda quando estiver solucionando ativamente um problema de conectividade ou desempenho e precisar de visibilidade imediata.

O ACNS fornece duas ferramentas para captura sob demanda. Para configurar ambas as ferramentas, consulte Configurar o modo de logs sob demanda.

Hubble CLI

A CLI do Hubble permite que você consulte, filtre e analise logs de fluxo diretamente do terminal. Isso é especialmente útil quando você precisa de filtros detalhados, por exemplo, para isolar o tráfego por namespace, rótulo de pod ou veredicto durante uma sessão de depuração ativa.

Interface do usuário do Hubble

A interface do usuário do Hubble fornece uma exibição gráfica da comunicação serviço a serviço. É uma boa opção quando você deseja rastrear visualmente caminhos de tráfego, identificar quais serviços estão se comunicando e detectar anomalias sem escrever comandos da CLI.

Principais benefícios dos logs sob demanda

• Nenhuma configuração anterior é necessária. Comece a capturar fluxos imediatamente sem definir recursos personalizados ou configurar o armazenamento.
• Visibilidade em tempo real. Inspecione o tráfego ao vivo e exiba os metadados do pacote à medida que os problemas ocorrem.
• Solução de problemas rápida. Filtre fluxos de forma interativa por meio da CLI do Hubble ou visualize mapas de serviços na interface do usuário do Hubble.
• Baixa sobrecarga. Não é necessário armazenamento persistente, portanto, não há nenhum custo contínuo para investigações ad hoc.

Recomendações para logs armazenados

1. Comece com filtros largos e, em seguida, reduza. Ao ativar os registros de fluxo pela primeira vez, use filtros amplos para capturar o tráfego em seus principais namespaces. Execute a configuração por alguns dias e examine os dados coletados em Log Analytics. Examine o volume de dados, o custo e se os fluxos capturados correspondem ao que você realmente precisa. Então, refine seu includeFilters para se concentrar no tráfego de alto valor e eliminar o ruído.

2. Use primeiro os painéis pré-construídos. Os painéis internos do portal do Azure abrangem casos de uso comuns, como padrões de comunicação de serviço, taxas de erro e falhas de DNS. Comece por aí. Adicione painéis personalizados ou consultas do Log Analytics somente se você precisar de visibilidade que os painéis predefinidos não fornecem.

3. Examine periodicamente. À medida que as cargas de trabalho e os padrões de tráfego mudam, seus filtros podem precisar de atualização. Verifique o volume de dados e a cobertura de fluxo periodicamente para verificar se você ainda está capturando o tráfego certo a um custo razoável.

Limitações

Requisitos de plano de dados e recursos:

• O modo de logs armazenados funciona apenas com o plano de dados Cilium.
• Os logs de fluxo da camada 7 são capturados somente quando o suporte à política de Camada 7 está habilitado. Para obter mais informações, consulte Configurar uma política de Camada 7.
• Fluxos e métricas DNS são capturados somente quando uma política de rede de Nome de Domínio Totalmente Qualificado (FQDN) do Cilium é aplicada. Para obter mais informações, consulte Configurar uma política FQDN.

Compensações de agregação:

• A agregação de logs de fluxo não preserva os carimbos de data/hora de fluxos individuais, os endereços IP por pod ou campos de alta cardinalidade, como URLs HTTP e nomes de consulta DNS. Use logs sob demanda para investigação por fluxo.

Armazenamento e plataforma:

• O arquivo local do host em /var/log/acns/hubble/ tem um limite de 50 MB por nó e é atualizado automaticamente. Se você precisar de retenção de longo prazo, habilite Azure Monitor (recomendado) ou encaminhe o arquivo para seu próprio serviço de log.
• Não há suporte para o plano da tabela de logs auxiliares.

Preços

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

Conteúdo relacionado

• Configurar logs 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