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 - LogLevel 1- KubernetesMetadata 2 |
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 level
anvä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 , , , , , , TRACE
eller UNKNOWN
. DEBUG
INFO
WARNING
ERROR
CRITICAL
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
, , ImageTag
och 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
namnetKubernetesMetadata
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.
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.
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
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