Esquema de log de insights de contêiner

O Container insights armazena 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 através do ConfigMap para CLI versão 2.54.0 e superior. O ContainerLogV2 será o formato de ingestão padrão para clientes que integrarão informações de contêiner com Managed Identity Auth usando ARM, Bicep, Terraform, Policy e Portal. O ContainerLogV2 pode ser explicitamente habilitado por meio da CLI versão 2.51.0 ou superior usando as 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 destaca as principais diferenças entre o uso do esquema ContainerLogV2 e ContainerLog.

Diferenças entre caraterísticas	ContainerLog	ContainerLogV2
Esquema	Detalhes em ContainerLog.	Detalhes em ContainerLogV2. As colunas adicionais são: - ContainerName - PodName - PodNamespace - LogLevel1 - KubernetesMetadata2
Integração	Apenas configurável através do ConfigMap.	Configurável através do ConfigMap e DCR. 3
Preços	Compatível apenas com logs de análise de preço completo.	Suporta a camada de logs básicos de baixo custo, além de logs de análise.
A consultar	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 operações de junção.
Multilinha	Não suportadas, 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 únicas consolidadas para saída de várias linhas.

1 Se LogMessage for um JSON válido e tiver uma chave chamada level, seu valor será usado. Caso contrário, usamos uma abordagem de correspondência de palavras-chave baseada em regex para inferir LogLevel a partir do próprio LogMessage. Observe que você pode ver algumas classificações incorretas à medida que esse valor é inferido.

2 KubernetesMetadata é coluna opcional e a coleta deste campo pode ser ativada com o recurso Kubernetes Metadata. O valor deste campo é JSON e contém campos como podLabels, podAnnotations, podUid, Image, ImageTag e Image repo.

3 Configuração DCR não suportada para clusters que utilizam clusters baseados na autenticação da entidade de serviço. Para usar essa experiência, migre seus clusters com a entidade de serviço para a identidade gerenciada.

Nota

A exportação para o Hub de Eventos e a Conta de Armazenamento não são suportadas se o LogMessage de entrada não for um JSON válido. Para obter o melhor desempenho, recomendamos a emissão de logs de contêiner no formato JSON.

Avaliar o impacto nos alertas existentes

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

Para procurar alertas que façam 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 estão 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 de 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 rico e visibilidade aprimorada de suas cargas de trabalho.

Funcionalidades principais

• Esquema ContainerLogV2 aprimorado com campos de metadados do Kubernetes: o Kubernetes Logs Metadata introduz outros campos de metadados opcionais que melhoram a experiência de solução de problemas com consultas simples do Log Analytics e eliminam a necessidade de associação 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 acelerar sua solução de problemas e identificar os problemas rapidamente.

• Configuração de lista de inclusão personalizada: os usuários podem personalizar novos campos de metadados que desejam ver editando o configmap. Observe que todos os campos de metadados são coletados por padrão quando o está habilitado metadata_collection e, se você quiser selecionar campos específicos, remova os comentários 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 gravidade codificados por cores, como CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE ou UNKNOWN. É uma ferramenta crucial para a 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 se aprofundem ainda mais, selecionando o painel para uma experiência de exploração para depuração adicional. No entanto, é importante notar que essa funcionalidade só é aplicável ao usar o Grafana. Se você estiver usando o espaço de trabalho do Log Analytics, o LogLevel é 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 utilizadores podem concentrar-se em informações relevantes sem peneirar 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 de análise de log.

• Filtragem de logs baseada em ConfigMap para logs de plataforma (Namespaces do Kubernetes do Sistema): 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 sistema desempenham um papel crucial. Por exemplo, considere o contêiner coredns dentro do namespace kube-system. Para coletar logs (stdout e stderr) exclusivamente do contêiner coredns form kube-system, você pode habilitar as seguintes configurações no configmap.

• Painel Grafana para visualização: O painel Grafana não apenas exibe visualizações codificadas por cores de níveis de log que variam de CRÍTICO a DESCONHECIDO, mas também mergulha em Volume de Log, Taxa de Log, Registros de Log, Logs. Os usuários podem obter análise sensível ao tempo, insights dinâmicos sobre as tendências de nível de log ao longo do tempo e monitoramento crucial em tempo real. Também fornecemos um detalhamento detalhado por computador, pod e contêiner, que permite uma análise aprofundada e a solução de problemas identificada. E, finalmente, na nova experiência da tabela Logs, os usuários podem visualizar detalhes detalhados com a visualização expandida, visualizar 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. Migre 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. Caso contrário, habilite o esquema ContainerLogV2.

Limitações

O Painel Grafana ContainerLogV2 não é suportado com a 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 suportados são coletados por padrão. Se desejar coletar campos específicos, especifique os campos obrigatórios em include_fields.

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

3. Depois de alguns minutos, os dados devem estar fluindo para sua tabela ContainerLogV2 com metadados de logs do Kubernetes, conforme mostrado na captura de tela abaixo.

A bordo da experiência do painel Grafana

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

2. Certifique-se de ter uma das funções de Administrador/Editor/Leitor do Grafana marcando Controle de acesso (IAM). Caso contrário, adicione-os.

3. Verifique se sua instância do Grafana tem acesso ao espaço de trabalho do Azure Logs Analytics (LA). Se ele não tiver acesso, você precisará conceder à função Grafana Instance Monitoring Reader acesso ao seu espaço de trabalho LA.

4. Navegue até o espaço de trabalho do Grafana e importe o painel ContainerLogV2 da galeria do Grafana.

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

Nota

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 se repita, salve o painel depois de selecionar um conjunto de variáveis para que ele se torne padrão na primeira abertura.

Ativar filtragem baseada em anotações

Siga as etapas abaixo mencionadas para habilitar a filtragem baseada em anotações. Encontre o link aqui assim 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 configure configmap para saber mais sobre como implantar e configurar o ConfigMap.

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

Anotação	Description
fluentbit.io/exclude: "true"	Exclui ambos os fluxos stdout & 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"	Exclua ambos os fluxos stdout & stderr somente para o container1 no pod
fluentbit.io/exclude_stdout_container1: "true"	Excluir apenas stdout apenas para o recipiente1 no pod

Nota

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

Aqui está um exemplo de fluentbit.io/exclude: "true" anotação na especificação do 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 logs baseada em ConfigMap para logs de plataforma (Namespaces do Kubernetes do Sistema)

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

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

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

Registro em log de várias linhas no Container Insights

Com o log de várias linhas habilitado, os logs de contêiner divididos anteriormente são costurados e enviados como entradas únicas para a tabela ContainerLogV2. Se a linha de log costurada 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 .NET, Go, Python e Java, que aparecem como entradas únicas na tabela ContainerLogV2. Habilite o registro em log de várias linhas com o ConfigMap conforme descrito em Configurar a coleta de dados no Container insights usando o ConfigMap.

Nota

O configmap agora apresenta uma opção de especificação de idioma, na qual os clientes podem selecionar apenas os idiomas em que estão interessados. Esse recurso pode ser ativado 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 da pilha de exceções Go:

Registo de várias linhas desativado

Registro em log de várias linhas habilitado

Rastreamento de pilha Java

Rastreamento de pilha Python

Próximos passos

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