Dela via


Loggschema för Container Insights

Container Insights lagrar loggdata som samlas in i en tabell med namnet ContainerLogV2 på en Log Analytics-arbetsyta. I den här artikeln beskrivs schemat för den här tabellen och konfigurationsalternativen för den. Den jämför även den här tabellen med den äldre ContainerLog-tabellen och innehåller information om hur du migrerar från den.

Tabelljämförelse

ContainerLogV2 är standardschemat för CLI version 2.54.0 och senare. Det här är standardtabellen för kunder som registrerar containerinsikter med hanterad identitetsautentisering. ContainerLogV2 kan uttryckligen aktiveras via CLI version 2.51.0 eller senare med hjälp av datainsamlingsinställningar.

Viktigt!

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

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.

1 Om LogMessage är giltig JSON och har en nyckel med namnet levelanvänds dess värde. Annars används regex-baserad nyckelordsmatchning för att härleda LogLevel från LogMessage. Den här slutsatsdragningen kan resultera i vissa felklassificeringar. LogLevelär ett strängfält med ett hälsovärde som , , , , , , TRACEeller UNKNOWN. DEBUGINFOWARNINGERRORCRITICAL

2 KubernetesMetadata är en valfri kolumn som är aktiverad med Kubernetes-metadata. Värdet för det här fältet är JSON med fälten podLabels, podAnnotations, podUid, Image, , ImageTagoch Image repo.

3 DCR-konfiguration kräver hanterad identitetsautentisering.

Kommentar

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

Aktivera ContainerLogV2-schemat

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. Tabellen ContainerLog används endast när både DCR och ConfigMap uttryckligen är inställda på av.

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. Kör följande Azure Resource Graph-fråga för att söka efter aviseringsregler som refererar till ContainerLog tabellen.

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

Kubernetes-metadata och loggfiltrering

Kubernetes-metadata och loggfiltrering utökar ContainerLogsV2-schemat med ytterligare Kubernetes-metadata. Funktionen för loggfiltrering ger filtreringsfunktioner för både arbetsbelastnings- och plattformscontainrar. Med de här funktionerna får du bättre kontext och bättre insyn i dina arbetsbelastningar.

Funktioner

  • Utökat ContainerLogV2-schema När Kubernetes-loggarnas metadata har aktiverats lägger det till en kolumn i ContainerLogV2 namnet KubernetesMetadata som förbättrar felsökningen med enkla loggfrågor och tar bort behovet av att ansluta till andra tabeller. Fälten i den här kolumnen är: PodLabels, PodAnnotations, PodUid, Image, ImageID, ImageRepo, ImageTag. De här fälten förbättrar felsökningen med hjälp av loggfrågor utan att behöva ansluta till andra tabeller. Mer information om hur du aktiverar Kubernetes-metadatafunktionen finns nedan.

  • Loggnivå Den här funktionen lägger till en LogLevel kolumn i ContainerLogV2 med möjliga värden som är kritiska, fel, varningar, information, felsökning, spårning eller okänd. Detta hjälper dig att utvärdera programmets hälsa baserat på allvarlighetsgrad. Genom att lägga till Grafana-instrumentpanelen kan du visualisera trender på loggnivå över tid och snabbt hitta berörda resurser.

  • Grafana-instrumentpanel för visualisering Grafana-instrumentpanelen ger en färgkodad visualisering av loggnivån och ger även insikter om loggvolym, loggfrekvens, loggposter, loggar. Du kan få tidskänslig analys, dynamiska insikter om trender på loggnivå över tid och viktig realtidsövervakning. Instrumentpanelen ger också en detaljerad uppdelning efter dator, podd och container, vilket ger djupgående analys och felsökning. Mer information om hur du installerar Grafana-instrumentpanelen finns nedan.

  • Anteckningsbaserad loggfiltrering för arbetsbelastningar Effektiv loggfiltrering via poddanteckningar. På så sätt kan du fokusera på relevant information utan att söka igenom brus. Med anteckningsbaserad filtrering kan du exkludera logginsamling för vissa poddar och containrar genom att kommentera podden, vilket skulle minska logganalyskostnaden avsevärt. Mer information om hur du konfigurerar anteckningsbaserad filtrering finns i Anteckningsbaserad loggfiltrering .

  • 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 kostnaden för data i Log Analytics-arbetsytan. I specifika felsökningsscenarier spelar dock containerloggar för systemcontainer en avgörande roll. Ett exempel är containern coredns kube-system i namnområdet.

Aktivera Kubernetes-metadata

Viktigt!

Insamling av Kubernetes-metadata kräver hanterad identitetsautentisering och ContainerLogsV2

Aktivera Kubernetes-metadata med hjälp av ConfigMap med följande inställningar. Alla metadatafält samlas in som standard när metadata_collection är aktiverat. Avkommentera include_fields för att ange enskilda fält som ska samlas in.

[log_collection_settings.metadata_collection]
    enabled = true
    include_fields = ["podLabels","podAnnotations","podUid","image","imageID","imageRepo","imageTag"]

Efter några minuter KubernetesMetadata ska kolumnen inkluderas i eventuella loggfrågor för ContainerLogV2 tabellen enligt nedan.

Skärmbild som visar containerlogv2.

Installera Grafana-instrumentpanelen

Viktigt!

Om du har aktiverat Grafana med hjälp av vägledningen i Aktivera övervakning för Kubernetes-kluster bör grafana-instansen redan ha åtkomst till din Azure Monitor-arbetsyta för Prometheus-mått. Instrumentpanelen för Kubernetes Logs-metadata kräver också åtkomst till din Log Analytics-arbetsyta som innehåller loggdata. Se Så här ändrar du åtkomstbehörigheter till Azure Monitor för vägledning om hur du beviljar Grafana-instansen rollen Övervakningsläsare för Log Analytics-arbetsytan.

Importera instrumentpanelen från Grafana-galleriet på ContainerLogV2-instrumentpanelen. Du kan sedan öppna instrumentpanelen och välja värden för DataSource, Prenumeration, ResourceGroup, Kluster, Namnområde och Etiketter.

Skärmbild som visar grafana-instrumentpanelen.

Kommentar

När du först läser in Grafana-instrumentpanelen kan det uppstå 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.

Loggning med flera rader

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

Skärmbild som visar att loggning med flera rader är inaktiverad.

Flerradsloggning aktiverad

Skärmbild som visar flerradsaktiverad.

Java-stackspårning

Skärmbild som visar flerradsaktiverad för Java.

Spårning av Python-stack

Skärmbild som visar flerradsaktiverad för Python.

Nästa steg