Esquema de log de insights de contêiner

Os insights de contêiner armazenam os dados de log coletados em uma tabela chamada ContainerLogV2. Este artigo descreve o esquema desta tabela e sua comparação e migração da tabela ContainerLog herdada.

Importante

ContainerLogV2 será o esquema padrão por meio do ConfigMap para a CLI versão 2.54.0 e superior. ContainerLogV2 será o formato de ingestão padrão para clientes que integrarão insights de contêiner com Autenticação de Identidade Gerenciada usando a integração do ARM, Bicep, Terraform, Policy e portal. O ContainerLogV2 pode ser habilitado explicitamente por meio da CLI versão 2.51.0 ou superior usando configurações de coleta de Dados.

O suporte para a tabela ContainerLog será desativado em 30 de setembro de 2026.

Comparação de tabelas

A tabela a seguir realça as principais diferenças entre o uso do esquema ContainerLogV2 e ContainerLog.

Diferenças de recursos	ContainerLog	ContainerLogV2
Esquema	Detalhes em ContainerLog.	Detalhes em ContainerLogV2. Colunas adicionais são: - ContainerName - PodName - PodNamespace - LogLevel1 - KubernetesMetadata2
Integração	Configurável apenas por meio de ConfigMap.	Configurável por meio de ConfigMap e DCR. 3
Preços	Compatível apenas com logs de análise com preços completos.	Dá suporte à camada de logs básicos de baixo custo, além dos logs de análise.
Consultas	Requer várias operações de junção com tabelas de inventário para consultas padrão.	Inclui metadados adicionais de pod e contêiner para reduzir a complexidade da consulta e as operações de junção.
Várias linhas	Sem suporte, as entradas de várias linhas são divididas em várias linhas.	Suporte para registro em log de várias linhas para permitir entradas individuais consolidadas para saída de várias linhas.

¹Se LogMessage for um JSON válido e tiver um nível nomeado de chave, seu valor será usado. Caso contrário, usaremos uma abordagem de correspondência de palavra-chave baseada em regex para inferir LogLevel do próprio LogMessage. Observe que você pode ver algumas classificações incorretas, pois esse valor é inferido.

²KubernetesMetadata é uma coluna opcional e a coleção desse campo pode ser habilitada com o recurso de Metadados do Kubernetes. O valor desse campo é JSON e contém campos como podLabels, podAnnotations, podUid, Image, ImageTag e Image repo.

³A configuração de DCR não tem suporte para clusters usando clusters baseados em autenticação de entidade de serviço. Para usar essa experiência, migre seus clusters com a entidade de serviço para a identidade gerenciada.

Observação

Não há suporte para exportação para o Hub de Eventos e a Conta de Armazenamento se o LogMessage não for um JSON válido. Para obter o melhor desempenho, recomendamos emitir logs de contêiner no formato JSON.

Avaliar o impacto dos alertas existentes

Antes de habilitar o esquema ContainerLogsV2, você deve avaliar se você tem alguma regra de alerta que dependa da tabela ContainerLog. Esses alertas precisam ser atualizados para usar a nova tabela.

Para verificar os alertas que fazem referência à tabela ContainerLog, execute a seguinte consulta do Azure Resource Graph:

resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "ContainerLog"
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc

Habilitar o esquema ContainerLogV2

Você pode habilitar o esquema ContainerLogV2 para um cluster usando a REGRA de Coleta de Dados (DCR) ou o ConfigMap do cluster. Se ambas as configurações estiverem habilitadas, o ConfigMap terá precedência. Os logs stdout e stderr só são ingeridos na tabela ContainerLog quando o DCR e o ConfigMap forem explicitamente definidos como desativados.

Filtragem de metadados e logs do Kubernetes

A Filtragem de Metadados e Logs do Kubernetes aprimora o esquema ContainerLogsV2 com mais metadados do Kubernetes, como PodLabels, PodAnnotations, PodUid, Image, ImageID, ImageRepo e ImageTag. Além disso, o recurso Filtragem de Logs fornece recursos de filtragem para contêineres de carga de trabalho e plataforma (ou seja, namespaces do sistema). Com esses recursos, os usuários ganham um contexto mais avançado e melhoram a visibilidade de suas cargas de trabalho.

Principais recursos

• Esquema ContainerLogV2 aprimorado com campos de metadados do Kubernetes: os Metadados de Logs do Kubernetes introduzem outros campos de metadados opcionais que aprimoram a experiência de solução de problemas com consultas simples do Log Analytics e removem a necessidade de ingressar com outras tabelas. Esses campos incluem informações essenciais, como "PodLabels", "PodAnnotations", "PodUid", "Image", "ImageID", "ImageRepo" e "ImageTag". Ao ter esse contexto prontamente disponível, os usuários podem agilizar a solução de problemas e identificar os problemas rapidamente.

• Configuração de lista de inclusão personalizada: os usuários podem adaptar novos campos de metadados que desejam ver por meio da edição do configmap. Observe que todos os campos de metadados são coletados por padrão quando metadata_collection estiver habilitado e se você quiser selecionar campos específicos, remova marca de comentário de include_fields e especifique os campos que precisam ser coletados.

• Esquema ContainerLogV2 aprimorado com nível de log: os usuários agora podem avaliar a integridade do aplicativo com base em níveis de severidade codificados por cores, como CRÍTICO, ERRO, AVISO, INFORMAÇÕES, DEPURAÇÃO, RASTREAMENTO ou DESCONHECIDO. É uma ferramenta crucial para resposta a incidentes e monitoramento proativo. Ao distinguir visualmente os níveis de gravidade, os usuários podem identificar rapidamente os recursos afetados. O sistema codificado por cores simplifica o processo de investigação e permite que os usuários analisem ainda mais detalhadamente selecionando o painel para uma experiência de exploração para depuração adicional. No entanto, é importante observar que essa funcionalidade só é aplicável ao usar o Grafana. Se você estiver usando o Workspace do Log Analytics, o LogLevel será simplesmente outra coluna na tabela ContainerLogV2.

• Filtragem de log baseada em anotação para cargas de trabalho: técnica eficiente de filtragem de log por meio de anotações de pod. Os usuários podem se concentrar em informações relevantes sem filtrar o ruído. A filtragem baseada em anotação permite que os usuários excluam a coleta de logs para determinados pods e contêineres anotando o pod, o que ajudaria a reduzir significativamente o custo da análise de logs.

• Filtragem de log baseada em ConfigMap para logs de plataforma (Namespaces do System Kubernetes): os logs de plataforma são emitidos por contêineres nos namespaces do sistema (ou restritos semelhantes). Por padrão, todos os logs de contêiner do namespace do sistema são excluídos para minimizar o custo do Log Analytics. No entanto, em cenários específicos de solução de problemas, os logs de contêiner do contêiner do sistema desempenham uma função crucial. Por exemplo, considere o contêiner coredns dentro do namespace do sistema kube. Para coletar logs (stdout e stderr) exclusivamente do kube-system do formulário do contêiner coredns, você pode habilitar as seguintes configurações no configmap.

• Painel do Grafana para visualização: o painel do Grafana não só exibe visualizações codificadas por cores de níveis de log que vão de CRÍTICO a DESCONHECIDO, mas também se aprofunda em Volume de Log, Taxa de Log, Registros de Log, Logs. Os usuários podem obter análises sensíveis ao tempo, insights dinâmicos sobre tendências de nível de log ao longo do tempo e monitoramento crucial em tempo real. Também fornecemos um detalhamento por computador, pod e contêiner, que capacita a análise detalhada e a solução de problemas identificadas Por fim, na nova experiência da tabela Logs, os usuários podem exibir detalhes detalhados com a exibição de expansão e exibir os dados em cada coluna e ampliar as informações que desejam ver.

Aqui está um vídeo mostrando o Painel do Grafana:

Como habilitar a filtragem de metadados e logs do Kubernetes

Pré-requisitos

1. Migrar para a Autenticação de Identidade Gerenciada. Saiba mais.

2. Verifique se o ContainerLogV2 está habilitado. Os clusters de Autenticação de Identidade Gerenciada têm esse esquema habilitado por padrão. Se não estiver, habilite o esquema ContainerLogV2.

Limitações

Não há suporte para o Painel do Grafana ContainerLogV2 com o SKU de Logs Básicos na tabela ContainerLogV2.

Habilitar metadados do Kubernetes

1. Baixe o configmap e modifique as configurações de false para true, como visto na captura de tela abaixo. Observe que todos os campos de metadados com suporte são coletados por padrão. Se você quiser coletar campos específicos, especifique os campos necessários em include_fields.

2. Aplique o ConfigMap. Consulte configurar o configmap para saber mais sobre como implantar e configurar o ConfigMap.

3. Após alguns minutos, os dados devem fluir para a tabela ContainerLogV2 com metadados de logs do Kubernetes, conforme mostrado na captura de tela abaixo.

Integrar à experiência do painel do Grafana

1. Na guia Insights, selecione as configurações de monitor e integre-se ao Painel do Grafana com a versão 10.3.4+

2. Verifique se você tem uma das funções de Administrador/Editor/Leitor do Grafana verificando o controle de acesso (IAM). Caso contrário, adicione-os.

3. Verifique se a instância do Grafana tem acesso ao workspace do Azure Logs Analytics (LA). Se ela não tiver acesso, você precisará conceder acesso à função Leitor de Monitoramento da Instância do Grafana ao seu workspace do LA.

4. Navegue até o workspace do Grafana e importe o Painel ContainerLogV2 da galeria do Grafana.

5. Selecione suas informações para DataSource, Subscription, ResourceGroup, Cluster, Namespace e Rótulos. Em seguida, o painel é preenchido conforme mostrado na captura de tela abaixo.

Observação

Quando você carrega inicialmente o Painel do Grafana, ele pode gerar alguns erros devido a variáveis que ainda não estão sendo selecionadas. Para evitar que isso seja recorrente, salve o painel depois de selecionar um conjunto de variáveis para que ele se torne padrão na primeira abertura.

Habilitar filtragem baseada em anotação

Siga as etapas mencionadas abaixo para habilitar a filtragem baseada em anotação. Localize o link aqui depois que a documentação de filtragem relacionada for publicada.

1. Baixe o configmap e modifique as configurações de false para true, como visto na captura de tela abaixo.

2. Aplique o ConfigMap. Consulte configurar o configmap para saber mais sobre como implantar e configurar o ConfigMap.

3. Adicione as anotações necessárias à especificação do pod de carga de trabalho. A tabela a seguir realça diferentes possíveis anotações de Pod e descrições do que elas fazem.

Anotação	Descrição
fluentbit.io/exclude: "true"	Exclui fluxos stdout e stderr em todos os contêineres no Pod
fluentbit.io/exclude_stdout: "true"	Exclui apenas o fluxo stdout em todos os contêineres no Pod
fluentbit.io/exclude_stderr: "true"	Exclui apenas o fluxo stderr em todos os contêineres no Pod
fluentbit.io/exclude_container1: "true"	Excluir fluxos stdout e stderr somente para o contêiner1 no pod
fluentbit.io/exclude_stdout_container1: "true"	Excluir somente stdout para o contêiner1 no pod

Observação

Essas anotações são baseadas em bit fluente. Se você usar sua própria solução de coleção de logs baseada em bit fluente com o filtro de plug-in do Kubernetes e a exclusão baseada em anotação, ela interromperá a coleta de logs do Container Insights e da sua solução.

Aqui está um exemplo da anotação fluentbit.io/exclude: "true" na especificação pod:

apiVersion: v1 
kind: Pod 
metadata: 
 name: apache-logs 
 labels: 
  app: apache-logs 
 annotations: 
  fluentbit.io/exclude: "true" 
spec: 
 containers: 
 - name: apache 
  image: edsiper/apache_logs 

Filtragem de log baseada em ConfigMap para logs de plataforma (Namespaces do Sistema Kubernetes)

1. Baixe o configmap e modifique as configurações relacionadas a collect_system_pod_logs e exclude_namespaces.

Por exemplo, para coletar logs stdout e stderr do contêiner coredns no namespace do sistema kube, verifique se o namespace do skube-system não está em exclude_namespaces e se esse recurso está restrito apenas aos seguintes namespaces do sistema: kube-system, gatekeeper-system, calico-system, azure-arc, kube-public e kube-node-lease namespaces.

2. Aplique o ConfigMap. Consulte configurar o configmap para saber mais sobre como implantar e configurar o ConfigMap.

Registros em log de várias linhas nos Insights de Contêiner

Com o log multilinha habilitado, os logs de contêiner divididos anteriormente são emendados e enviados como entradas simples para a tabela ContainerLogV2. Se a linha de logs emendados for maior que 64 KB, ela será truncada devido aos limites do espaço de trabalho do Log Analytics. Esse recurso também tem suporte para rastreamentos de pilha do .NET, Go, Python e Java, que aparecem como entradas simples na tabela ContainerLogV2. Habilite o registro em log de várias linhas com o ConfigMap, conforme descrito em Configurar coleta de dados em insights de contêiner usando ConfigMap.

Observação

O configmap já apresenta uma opção de especificação de idioma, na qual os clientes podem selecionar apenas os idiomas nos quais estão interessados. Esse recurso pode ser habilitado editando os idiomas na opção stacktrace_languages no configmap.

As capturas de tela a seguir mostram o registro em log de várias linhas para o rastreamento de pilha de exceções Go:

Log de várias linhas desabilitado

Log de várias linhas habilitado

Rastreamento de pilha do Java

Rastreamento de pilha do Python

Próximas etapas

• Configure os Logs básicos para ContainerLogv2.
• Saiba como consultar dados do ContainerLogV2