Schema del log di Informazioni dettagliate sui contenitori

Informazioni dettagliate sui contenitori archivia i dati di log raccolti in una tabella denominata ContainerLogV2. Questo articolo descrive lo schema di questa tabella e il relativo confronto e migrazione dalla tabella ContainerLog legacy.

Importante

ContainerLogV2 sarà lo schema predefinito tramite ConfigMap per l'interfaccia della riga di comando versione 2.54.0 e successive. ContainerLogV2 sarà il formato di inserimento predefinito per i clienti che eseguiranno l'onboarding di informazioni dettagliate sui contenitori con l'autenticazione dell'identità gestita usando ARM, Bicep, Terraform, Criteri e onboarding del portale. ContainerLogV2 può essere abilitato in modo esplicito tramite l'interfaccia della riga di comando versione 2.51.0 o successiva usando le impostazioni di raccolta dati.

Il supporto per la tabella ContainerLog verrà ritirato il 30 settembre 2026.

Confronto tra tabelle

La tabella seguente evidenzia le differenze principali tra l'uso dello schema ContainerLogV2 e ContainerLog.

Differenze di funzionalità	ContainerLog	ContainerLogV2
Schema	Dettagli in ContainerLog.	Dettagli in ContainerLogV2. Le colonne aggiuntive sono: - ContainerName - PodName - PodNamespace - LogLevel1 - KubernetesMetadata2
Onboarding	Configurabile solo tramite ConfigMap.	Configurabile tramite ConfigMap e DCR. 3
Prezzi	Compatibile solo con i log di analisi a prezzi completi.	Supporta il livello di log di base a basso costo oltre ai log di analisi.
Query	Richiede più operazioni di join con tabelle di inventario per le query standard.	Include metadati aggiuntivi di pod e contenitori per ridurre la complessità delle query e le operazioni di join.
Multiline	Non supportato, le voci su più righe vengono suddivise in più righe.	Supporto per la registrazione su più righe per consentire voci singole consolidate per l'output multilinea.

¹Se LogMessage è un file JSON valido e ha una chiave denominata level, verrà usato il relativo valore. In caso contrario, viene usato un approccio basato su parole chiave regex per dedurre LogLevel da LogMessage stesso. Si noti che potrebbero essere visualizzate alcune sottoclassificazioni perché questo valore viene dedotto.

²KubernetesMetadata è una colonna facoltativa e la raccolta di questo campo può essere abilitata con la funzionalità Metadati kubernetes. Il valore di questo campo è JSON e contiene campi come podLabels, podAnnotations, podUid, Image, ImageTag e Image repository.

³Configurazione DCR non supportata per i cluster che usano cluster basati sull'autenticazione dell'entità servizio. Per usare questa esperienza, eseguire la migrazione dei cluster con l'entità servizio all'identità gestita.

Nota

L'esportazione nell'hub eventi e l'account Archiviazione non è supportato se LogMessage in ingresso non è un codice JSON valido. Per ottenere prestazioni ottimali, è consigliabile creare log dei contenitori in formato JSON.

Valutare l'impatto sugli avvisi esistenti

Prima di abilitare lo schema ContainerLogsV2 , è necessario valutare se sono presenti regole di avviso che si basano sulla tabella ContainerLog . Per usare la nuova tabella, è necessario aggiornare tali avvisi.

Per analizzare gli avvisi che fanno riferimento alla tabella ContainerLog , eseguire la query di Azure Resource Graph seguente:

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

Abilitare lo schema ContainerLogV2

È possibile abilitare lo schema ContainerLogV2 per un cluster usando la regola di raccolta dati del cluster o ConfigMap. Se entrambe le impostazioni sono abilitate, ConfigMap ha la precedenza. I log stdout e stderr vengono inseriti nella tabella ContainerLog solo quando sia DCR che ConfigMap vengono esplicitamente disattivati.

Filtro dei metadati e dei log kubernetes

Il filtro dei metadati e dei log di Kubernetes migliora lo schema ContainerLogsV2 con più metadati Kubernetes, ad esempio PodLabels, PodAnnotations, PodUid, Image, ImageID, ImageRepo e ImageTag. Inoltre, la funzionalità di filtro dei log offre funzionalità di filtro sia per i contenitori del carico di lavoro che per la piattaforma (ovvero gli spazi dei nomi di sistema). Con queste funzionalità, gli utenti ottengono un contesto più completo e migliorano la visibilità sui carichi di lavoro.

Funzionalità chiave

• Schema ContainerLogV2 avanzato con i campi dei metadati kubernetes: i metadati dei log di Kubernetes introduce altri campi di metadati facoltativi che migliorano l'esperienza di risoluzione dei problemi con semplici query di Log Analytics e elimina la necessità di unire altre tabelle. Questi campi includono informazioni essenziali, ad esempio "PodLabels", "PodAnnotations", "PodUid", "Image", "ImageID", "ImageRepo" e "ImageTag". Avendo questo contesto prontamente disponibile, gli utenti possono accelerare la risoluzione dei problemi e identificare rapidamente i problemi.

• Configurazione dell'elenco di inclusione personalizzata: gli utenti possono personalizzare nuovi campi di metadati da visualizzare modificando la mappa di configurazione. Si noti che tutti i campi dei metadati vengono raccolti per impostazione predefinita quando metadata_collection è abilitato e se si desidera selezionare campi specifici, rimuovere il commento include_fields e specificare i campi che devono essere raccolti.

• Schema ContainerLogV2 avanzato con livello di log: gli utenti possono ora valutare l'integrità dell'applicazione in base ai livelli di gravità codificati a colori, ad esempio CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE o UNKNOWN. È uno strumento fondamentale per la risposta agli eventi imprevisti e il monitoraggio proattivo. Distinguendo visivamente i livelli di gravità, gli utenti possono individuare rapidamente le risorse interessate. Il sistema codificato a colori semplifica il processo di indagine e consente agli utenti di eseguire il drill-down ulteriormente selezionando il pannello per un'esperienza di esplorazione per un'ulteriore debug. Tuttavia, è importante notare che questa funzionalità è applicabile solo quando si usa Grafana. Se si usa l'area di lavoro Log Analytics, LogLevel è semplicemente un'altra colonna nella tabella ContainerLogV2.

• Filtro dei log basato sulle annotazioni per i carichi di lavoro: tecnica efficiente di filtro dei log tramite annotazioni pod. Gli utenti possono concentrarsi sulle informazioni pertinenti senza analizzare il rumore. Il filtro basato sulle annotazioni consente agli utenti di escludere la raccolta di log per determinati pod e contenitori annotando il pod, che consente di ridurre significativamente il costo di Log Analytics.

• Filtro dei log basato su ConfigMap per i log della piattaforma (spazi dei nomi kubernetes di sistema): i log della piattaforma vengono generati dai contenitori negli spazi dei nomi con restrizioni simili o nel sistema. Per impostazione predefinita, tutti i log dei contenitori dello spazio dei nomi di sistema vengono esclusi per ridurre al minimo il costo di Log Analytics. Tuttavia, in scenari di risoluzione dei problemi specifici, i log dei contenitori del contenitore di sistema svolgono un ruolo fondamentale. Si consideri ad esempio il contenitore coredns all'interno dello spazio dei nomi kube-system. Per raccogliere log (stdout e stderr) esclusivamente dal modulo del contenitore coredns kube-system, è possibile abilitare le impostazioni seguenti in configmap.

• Dashboard di Grafana per la visualizzazione: il dashboard di Grafana non solo visualizza visualizzazioni codificate a colori dei livelli di log che vanno da CRITICAL a UNKNOWN, ma anche in Log Volume, Log Rate, Log Records, Logs. Gli utenti possono ottenere analisi sensibili al tempo, informazioni dettagliate dinamiche sulle tendenze a livello di log nel tempo e monitoraggio cruciale in tempo reale. Viene inoltre fornito un dettaglio dettagliato per computer, pod e contenitore, che consente l'analisi approfondita e la risoluzione dei problemi individuata. Infine, nella nuova esperienza della tabella Log, gli utenti possono visualizzare dettagli approfonditi con la visualizzazione espandi e visualizzare i dati in ogni colonna e ingrandire le informazioni che vogliono visualizzare.

Ecco un video che illustra il dashboard di Grafana:

Come abilitare il filtro dei metadati e dei log di Kubernetes

Prerequisiti

1. Eseguire la migrazione all'autenticazione dell'identità gestita. Scopri di più.

2. Assicurarsi che ContainerLogV2 sia abilitato. Per impostazione predefinita, i cluster di autenticazione con identità gestita dispongono di questo schema abilitato. In caso contrario, abilitare lo schema ContainerLogV2.

Limiti

Il dashboard Grafana ContainerLogV2 non è supportato con lo SKU Dei log di base nella tabella ContainerLogV2.

Abilitare i metadati di Kubernetes

1. Scaricare il file configmap e modificare le impostazioni da false a true , come illustrato nello screenshot seguente. Si noti che tutti i campi di metadati supportati vengono raccolti per impostazione predefinita. Se si desidera raccogliere campi specifici, specificare i campi obbligatori in include_fields.

2. Applicare ConfigMap. Vedere Configurare configmap per altre informazioni sulla distribuzione e la configurazione di ConfigMap.

3. Dopo alcuni minuti, i dati devono essere trasmessi alla tabella ContainerLogV2 con i metadati dei log di Kubernetes, come illustrato nello screenshot seguente.

Eseguire l'onboarding nell'esperienza dashboard di Grafana

1. Nella scheda Informazioni dettagliate selezionare Monitor settings and onboard to Grafana Dashboard with version 10.3.4+ (Monitorare le impostazioni ed eseguire l'onboarding nel dashboard Grafana con la versione 10.3.4+

2. Assicurarsi di disporre di uno dei ruoli Grafana Amministrazione/Editor/Lettore selezionando Controllo di accesso (IAM). In caso contrario, aggiungerli.

3. Verificare che l'istanza di Grafana abbia accesso all'area di lavoro Analisi log di Azure(LA). Se non ha accesso, è necessario concedere l'accesso al ruolo lettore del monitoraggio dell'istanza di Grafana all'area di lavoro la.

4. Passare all'area di lavoro Grafana e importare il dashboard ContainerLogV2 dalla raccolta Grafana.

5. Selezionare le informazioni per DataSource, Subscription, ResourceGroup, Cluster, Namespace e Labels. Il dashboard viene quindi popolato come illustrato nello screenshot seguente.

Nota

Quando si carica inizialmente il dashboard di Grafana, potrebbe generare alcuni errori a causa di variabili non ancora selezionate. Per evitare che ciò venga ricorrente, salvare il dashboard dopo aver selezionato un set di variabili in modo che diventi predefinito nella prima apertura.

Abilitare il filtro basato sulle annotazioni

Seguire i passaggi indicati di seguito per abilitare il filtro basato sulle annotazioni. Trovare il collegamento qui dopo la pubblicazione della documentazione di filtro correlata.

1. Scaricare il file configmap e modificare le impostazioni da false a true, come illustrato nello screenshot seguente.

2. Applicare ConfigMap. Vedere Configurare configmap per altre informazioni sulla distribuzione e la configurazione di ConfigMap.

3. Aggiungere le annotazioni necessarie nella specifica del pod del carico di lavoro. La tabella seguente evidenzia le diverse annotazioni e descrizioni dei pod di ciò che fanno.

Annotazione	Descrizione
fluentbit.io/exclude: "true"	Esclude entrambi i flussi stdout e stderr in tutti i contenitori nel pod
fluentbit.io/exclude_stdout: "true"	Esclude solo il flusso stdout in tutti i contenitori nel pod
fluentbit.io/exclude_stderr: "true"	Esclude solo il flusso stderr in tutti i contenitori nel pod
fluentbit.io/exclude_container1: "true"	Escludere entrambi i flussi stdout e stderr solo per il contenitore1 nel pod
fluentbit.io/exclude_stdout_container1: "true"	Escludere solo stdout per il contenitore1 nel pod

Nota

Queste annotazioni sono basate su bit fluente. Se si usa la propria soluzione di raccolta log basata su fluent bit con il filtro del plug-in Kubernetes e l'esclusione basata su annotazione, la raccolta dei log da Container Insights e dalla soluzione verrà interrotta.

Di seguito è riportato un esempio di annotazione nella specifica pod fluentbit.io/exclude: "true" :

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 

Filtro dei log basato su ConfigMap per i log della piattaforma (spazi dei nomi Kubernetes di sistema)

1. Scaricare il file configmap e modificare le impostazioni correlate a collect_system_pod_logs e exclude_namespaces.

Ad esempio, per raccogliere i log stdout e stderr del contenitore coredns nello spazio dei nomi kube-system, assicurarsi che lo spazio dei nomi kube-system non sia incluso exclude_namespaces e questa funzionalità sia limitata solo agli spazi dei nomi di sistema seguenti: kube-system, gatekeeper-system, calico-system, azure-arc, kube-public e kube-node-lease namespaces.

2. Applicare ConfigMap. Vedere Configurare configmap per altre informazioni sulla distribuzione e la configurazione di ConfigMap.

Registrazione su più righe in Container Insights

Con la registrazione su più righe abilitata, i log dei contenitori suddivisi in precedenza vengono uniti e inviati come singole voci alla tabella ContainerLogV2. Se la linea di log punti è superiore a 64 KB, verrà troncata a causa dei limiti dell'area di lavoro Log Analytics. Questa funzionalità include anche il supporto per le tracce dello stack .NET, Go, Python e Java, che vengono visualizzate come singole voci nella tabella ContainerLogV2. Abilitare la registrazione su più righe con ConfigMap come descritto in Configurare la raccolta dati in Informazioni dettagliate contenitore con ConfigMap.

Nota

La mappa di configurazione include ora un'opzione specifica del linguaggio, in cui i clienti possono selezionare solo le lingue a cui sono interessati. Questa funzionalità può essere abilitata modificando le lingue nell'opzione stacktrace_languages nella mappa di configurazione.

Gli screenshot seguenti mostrano la registrazione su più righe per l'analisi dello stack di eccezioni Go:

Registrazione su più righe disabilitata

Registrazione su più righe abilitata

Analisi dello stack Java

Traccia dello stack Python

Passaggi successivi

• Configurare i log di base per ContainerLogv2.
• Informazioni su come eseguire query sui dati da ContainerLogV2