Loggschema för Container Insights

Container Insights lagrar loggdata som samlas in i en tabell med namnet ContainerLogV2. Den här artikeln beskriver schemat för den här tabellen och dess jämförelse och migrering från den äldre ContainerLog-tabellen .

Viktigt!

ContainerLogV2 är standardschemat via ConfigMap för CLI version 2.54.0 och senare. ContainerLogV2 är standardformatet för inmatning för kunder som registrerar containerinsikter med hanterad identitetsautentisering med arm-, Bicep-, Terraform-, princip- och portalregistrering. ContainerLogV2 kan uttryckligen aktiveras via CLI version 2.51.0 eller senare med datainsamlingsinställningar.

Stöd för tabellen ContainerLog dras tillbaka den 30 september 2026.

Tabelljämförelse

I följande tabell visas de viktigaste skillnaderna mellan att använda ContainerLogV2 och ContainerLog-schemat.

Funktionsskillnader	ContainerLog	ContainerLogV2
Schema	Information på ContainerLog.	Information på ContainerLogV2. Ytterligare kolumner är: - ContainerName - PodName - PodNamespace - LogLevel1 - KubernetesMetadata2
Introduktion	Kan endast konfigureras via ConfigMap.	Kan konfigureras via både ConfigMap och DCR. 3
Prissättning	Endast kompatibel med fullständiga analysloggar.	Stöder lågkostnadsnivån för grundläggande loggar utöver analysloggar.
Fråga	Kräver flera kopplingsåtgärder med inventeringstabeller för standardfrågor.	Innehåller ytterligare podd- och containermetadata för att minska frågekomplexitet och kopplingsåtgärder.
Multiline	Flerradsposter stöds inte och delas upp i flera rader.	Stöd för flerradsloggning för att tillåta konsoliderade, enskilda poster för flerradsutdata.

¹Om LogMessage är en giltig JSON och har en nyckel med namnet level används dess värde. Annars använder vi en regex-baserad metod för nyckelordsmatchning för att härleda LogLevel från själva LogMessage. Observera att du kan se vissa felklassificeringar eftersom det här värdet härleds.

²KubernetesMetadata är valfri kolumn och insamling av det här fältet kan aktiveras med kubernetes-metadatafunktionen. Värdet för det här fältet är JSON och innehåller fält som podLabels, podAnnotations, podUid, Image, ImageTag och Image-lagringsplatsen.

³DCR-konfiguration stöds inte för kluster som använder autentiseringsbaserade kluster med tjänstens huvudnamn. Om du vill använda den här upplevelsen migrerar du dina kluster med tjänstens huvudnamn till hanterad identitet.

Kommentar

Export till Händelsehubb och Lagringskonto stöds inte om den inkommande LogMessage inte är en giltig JSON. För bästa prestanda rekommenderar vi att du skickar containerloggar i JSON-format.

Utvärdera effekten på befintliga aviseringar

Innan du aktiverar ContainerLogsV2-schemat bör du utvärdera om du har några aviseringsregler som är beroende av tabellen ContainerLog . Sådana aviseringar måste uppdateras för att använda den nya tabellen.

Om du vill söka efter aviseringar som refererar till tabellen ContainerLog kör du följande Azure Resource Graph-fråga:

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

Aktivera ContainerLogV2-schemat

Du kan aktivera ContainerLogV2-schemat för ett kluster med hjälp av klustrets datainsamlingsregel (DCR) eller ConfigMap. Om båda inställningarna är aktiverade har ConfigMap företräde. Stdout- och stderr-loggar matas bara in i tabellen ContainerLog när både DCR och ConfigMap uttryckligen är inställda på av.

Kubernetes-metadata och loggfiltrering

Kubernetes-metadata och loggfiltrering förbättrar ContainerLogsV2-schemat med fler Kubernetes-metadata som PodLabels, PodAnnotations, PodUid, Image, ImageID, ImageRepo och ImageTag. Dessutom innehåller funktionen Loggfiltrering filtreringsfunktioner för både arbetsbelastnings- och plattformscontainrar (dvs. systemnamnområden). Med de här funktionerna får användarna bättre kontext och bättre insyn i sina arbetsbelastningar.

Nyckelfunktioner

• Utökat ContainerLogV2-schema med Kubernetes-metadatafält: Kubernetes Logs Metadata introducerar andra valfria metadatafält som förbättrar felsökningsupplevelsen med enkla Log Analytics-frågor och tar bort behovet av att ansluta till andra tabeller. Dessa fält innehåller viktig information som "PodLabels", "PodAnnotations", "PodUid", "Image", "ImageID", "ImageRepo" och "ImageTag". Genom att ha den här kontexten lättillgänglig kan användarna snabbt utexpediera felsökningen och identifiera problemen.

• Anpassad inkluderingslistkonfiguration: Användare kan skräddarsy nya metadatafält som de vill se genom att redigera konfigurationskartan. Observera att alla metadatafält samlas in som standard när metadata_collection är aktiverat och om du vill välja specifika fält avkommentarer include_fields och anger de fält som måste samlas in.

• Utökat ContainerLogV2-schema med loggnivå: Användare kan nu utvärdera programmets hälsa baserat på färgkodade allvarlighetsnivåer som CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE eller UNKNOWN. Det är ett viktigt verktyg för incidenthantering och proaktiv övervakning. Genom att visuellt särskilja allvarlighetsgraderna kan användarna snabbt hitta berörda resurser. Det färgkodade systemet effektiviserar undersökningsprocessen och gör det möjligt för användare att öka detaljnivån ytterligare genom att välja panelen för en utforskande upplevelse för ytterligare felsökning. Det är dock viktigt att observera att den här funktionen endast gäller när du använder Grafana. Om du använder Log Analytics-arbetsytan är LogLevel helt enkelt en annan kolumn i tabellen ContainerLogV2.

• Anteckningsbaserad loggfiltrering för arbetsbelastningar: Effektiv loggfiltreringsteknik via podanteckningar. Användare kan fokusera på relevant information utan att söka igenom brus. Med anteckningsbaserad filtrering kan användare exkludera logginsamling för vissa poddar och containrar genom att kommentera podden, vilket skulle minska logganalyskostnaden avsevärt.

• ConfigMap-baserad loggfiltrering för plattformsloggar (System Kubernetes-namnområden): Plattformsloggar genereras av containrar i systemets (eller liknande begränsade) namnområden. Som standard undantas alla containerloggar från systemnamnområdet för att minimera Log Analytics-kostnaden. I specifika felsökningsscenarier spelar dock containerloggar för systemcontainer en avgörande roll. Tänk till exempel på coredns-containern i kube-system-namnområdet. Om du vill samla in loggar (stdout och stderr) exklusivt från coredns containerformen kube-system kan du aktivera följande inställningar i konfigurationskartan.

• Grafana-instrumentpanel för visualisering: Grafana-instrumentpanelen visar inte bara färgkodade visualiseringar av loggnivåer som sträcker sig från KRITISK till OKÄND, utan även i Loggvolym, Loggfrekvens, Loggposter, Loggar. Användare kan få tidskänslig analys, dynamiska insikter om trender på loggnivå över tid och viktig realtidsövervakning. Vi tillhandahåller också en detaljerad uppdelning efter dator, podd och container, vilket ger djupgående analys och felsökning. Och slutligen i den nya tabellen Loggar kan användarna visa detaljerad information med visningsvyn och visa data i varje kolumn och zooma in den information de vill se.

Här är en video som visar Grafana-instrumentpanelen:

Så här aktiverar du Kubernetes-metadata och loggfiltrering

Förutsättningar

1. Migrera till hanterad identitetsautentisering. Läs mer.

2. Kontrollera att ContainerLogV2 är aktiverat. Hanterade identitetsautentiseringskluster har det här schemat aktiverat som standard. Om inte aktiverar du ContainerLogV2-schemat.

Begränsningar

Instrumentpanelen ContainerLogV2 Grafana stöds inte med Basic Logs SKU i tabellen ContainerLogV2.

Aktivera Kubernetes-metadata

1. Ladda ned konfigurationskartanoch ändra inställningarna från false till true enligt skärmbilden nedan. Observera att alla metadatafält som stöds samlas in som standard. Om du vill samla in specifika fält anger du de obligatoriska fälten i include_fields.

2. Använd ConfigMap. Mer information om hur du distribuerar och konfigurerar ConfigMap finns i konfigurera konfigurationsmappen .

3. Efter några minuter bör data flöda till din ContainerLogV2-tabell med Kubernetes-loggarnas metadata, enligt skärmbilden nedan.

Registrera dig för Grafana-instrumentpanelen

1. Under fliken Insikter väljer du övervakningsinställningar och registrerar till Grafana-instrumentpanelen med version 10.3.4+

2. Kontrollera att du har någon av Grafana Admin/Editor/Reader-rollerna genom att kontrollera åtkomstkontroll (IAM). Om inte lägger du till dem.

3. Kontrollera att Grafana-instansen har åtkomst till arbetsytan Azure Logs Analytics (LA). Om den inte har åtkomst måste du ge Rollen Grafana-instansövervakningsläsare åtkomst till la-arbetsytan.

4. Gå till Grafana-arbetsytan och importera ContainerLogV2-instrumentpanelen från Grafana-galleriet.

5. Välj din information för DataSource, Subscription, ResourceGroup, Cluster, Namespace och Labels. Instrumentpanelen fylls sedan i enligt beskrivningen i skärmbilden nedan.

Kommentar

När du först läser in Grafana-instrumentpanelen kan det utlösa vissa fel på grund av att variabler ännu inte har valts. Om du vill förhindra att detta upprepas sparar du instrumentpanelen när du har valt en uppsättning variabler så att den blir standard vid den första öppningen.

Aktivera anteckningsbaserad filtrering

Följ stegen nedan för att aktivera anteckningsbaserad filtrering. Hitta länken här när den relaterade filtreringsdokumentationen har publicerats.

1. Ladda ned konfigurationskartan och ändra inställningarna från false till true enligt skärmbilden nedan.

2. Använd ConfigMap. Mer information om hur du distribuerar och konfigurerar ConfigMap finns i konfigurera konfigurationsmappen .

3. Lägg till de anteckningar som krävs i arbetsbelastningspoddens specifikation. Följande tabell visar olika möjliga poddanteckningar och beskrivningar av vad de gör.

Anteckning	beskrivning
fluentbit.io/exclude: "true"	Undantar både stdout- och stderr-strömmar på alla containrar i podden
fluentbit.io/exclude_stdout: "true"	Exkluderar endast stdout-dataström på alla containrar i podden
fluentbit.io/exclude_stderr: "true"	Exkluderar endast stderr-ström på alla containrar i podden
fluentbit.io/exclude_container1: "true"	Undanta både stdout- och stderr-strömmar endast för container1 i podden
fluentbit.io/exclude_stdout_container1: "true"	Undanta endast stdout för container1 i podden

Kommentar

Dessa anteckningar är flytande bitbaserade. Om du använder din egen fluent-bit-baserade loggsamlingslösning med Kubernetes-plugin-filtret och anteckningsbaserad exkludering slutar den att samla in loggar från både Container Insights och din lösning.

Här är ett exempel på fluentbit.io/exclude: "true" anteckningar i poddspecifikationen:

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 

ConfigMap-baserad loggfiltrering för plattformsloggar (System Kubernetes-namnområden)

1. Ladda ned konfigurationskartan och ändra inställningarna relaterade till collect_system_pod_logs och exclude_namespaces.

Om du till exempel vill samla in stdout- och stderr-loggar för coredns-containern i kube-system-namnområdet kontrollerar du att kube-systemnamnområdet inte finns i exclude_namespaces och att den här funktionen endast är begränsad till följande systemnamnområden: kube-system, gatekeeper-system, calico-system, azure-arc, kube-public och kube-node-lease namespaces.

2. Använd ConfigMap. Mer information om hur du distribuerar och konfigurerar ConfigMap finns i konfigurera konfigurationsmappen .

Flerradsloggning i Container Insights

Med flerradsloggning aktiverat sys tidigare delade containerloggar ihop och skickas som enskilda poster till tabellen ContainerLogV2. Om den sydda logglinjen är större än 64 kB trunkeras den på grund av Log Analytics-arbetsytegränser. Den här funktionen har också stöd för .NET-, Go-, Python- och Java-stackspårningar, som visas som enskilda poster i tabellen ContainerLogV2. Aktivera flerradig loggning med ConfigMap enligt beskrivningen i Konfigurera datainsamling i Container insights med hjälp av ConfigMap.

Kommentar

Konfigurationskartan har nu ett språkspecifikationsalternativ, där kunderna bara kan välja de språk som de är intresserade av. Den här funktionen kan aktiveras genom att redigera språken i alternativet stacktrace_languages i konfigurationskartan.

Följande skärmbilder visar loggning med flera rader för Spårning av Go-undantagsstack:

Loggning med flera rader har inaktiverats

Flerradsloggning aktiverad

Java-stackspårning

Spårning av Python-stack

Nästa steg

• Konfigurera grundläggande loggar för ContainerLogv2.
• Lär dig hur du frågar efter data från ContainerLogV2