Protokollschema von Container Insights

Container Insights speichert Protokolldaten, die in einer Tabelle mit dem Namen ContainerLogV2 gesammelt werden. In diesem Artikel wird das Schema dieser Tabelle sowie deren Vergleich mit und die Migration aus der Legacytabelle ContainerLog beschrieben.

Wichtig

ContainerLogV2 wird das Standardschema über die ConfigMap für CLI-Version 2.54.0 und höher sein. ContainerLogV2 wird das Standarderfassungsschema für Kunden sein, die das Onboarding von Container-Einblicken mit verwalteter Identitätsauthentifizierung über ARM, Bicep, Terraform, Policy und Portal-Onboarding durchführen. ContainerLogV2 kann über die CLI-Version 2.51.0 oder höher mithilfe von Datensammlungseinstellungen explizit aktiviert werden.

Die Unterstützung für die ContainerLog-Tabelle wird am 30. September 2026 eingestellt.

Tabellenvergleich

In der folgenden Tabelle werden die wichtigsten Unterschiede zwischen der Verwendung des ContainerLogV2- und des ContainerLog-Schemas hervorgehoben.

Featureunterschiede	ContainerLog	ContainerLogV2
Schema	Details unter ContainerLog.	Details unter ContainerLogV2. Weitere Spalten sind: - ContainerName - PodName - PodNamespace - LogLevel1 - KubernetesMetadata2
Onboarding	Nur über ConfigMap konfigurierbar.	Konfigurierbar über ConfigMap und DCR. 3
Preiskalkulation	Nur kompatibel mit vollpreisigen Analyseprotokollen.	Unterstützt die kostengünstige Basisprotokollebene zusätzlich zu Analyseprotokollen.
Abfragen	Erfordert mehrere Verknüpfungsvorgänge mit Inventartabellen für Standardabfragen.	Enthält zusätzliche Pod- und Containermetadaten zur Verringerung der Abfragekomplexität und Verknüpfungsvorgänge.
Mehrzeilig	Nicht unterstützt, mehrzeilige Einträge werden in mehrere Datensätze unterteilt.	Unterstützung für mehrzeilige Protokollierung, um konsolidierte, einzelne Einträge für mehrzeilige Ausgaben zu ermöglichen.

¹Wenn LogMessage ein gültiger JSON-Code ist und über eine benannte Schlüsselebene verfügt, wird der Wert verwendet. Andernfalls verwenden wir einen Regex-basierten Schlüsselwortabgleichsansatz, um LogLevel von der LogMessage selbst abzuleiten. Beachten Sie, dass möglicherweise einige Fehlklassifizierungen angezeigt werden, da dieser Wert abgeleitet ist.

²KubernetesMetadata ist eine optionale Spalte und Sammlung. Dieses Felds kann mit der Option Kubernetes Metadata-Feature aktiviert werden. Der Wert dieses Felds ist JSON und es enthält Felder wie podLabels, podAnnotations, podUid, Image, ImageTag und ImageRepo.

³DCR-Konfiguration wird für Cluster, die auf Dienstprinzipalauthentifizierung basieren, nicht unterstützt. Um diese Oberfläche zu verwenden, migrieren Sie Ihre Cluster mit Dienstprinzipal zu einer verwalteten Identität.

Hinweis

Der Export zu Event Hub und Speicherkonto wird nicht unterstützt, wenn die eingehende LogMessage kein gültiges JSON ist. Für eine optimale Leistung empfehlen wir, Containerprotokolle im JSON-Format zu ausgeben.

Bewerten der Auswirkungen auf vorhandene Warnungen

Bevor Sie das ContainerLogsV2-Schema aktivieren, sollten Sie bewerten, ob Sie über Warnungsregeln verfügen, die auf der Tabelle ContainerLog basieren. Alle derartigen Warnungen müssen auf die Verwendung einer neuen Tabelle aktualisiert werden.

Führen Sie die folgende Azure Resource Graph-Abfrage aus, um nach Warnungen zu suchen, die auf die ContainerLog-Tabelle verweisen:

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

Aktivieren des ContainerLogV2-Schemas

Sie können das ContainerLogV2-Schema für einen Cluster entweder über die Datensammlungsregel (Data Collection Rule, DCR) des Clusters oder ConfigMap aktivieren. Wenn beide Einstellungen aktiviert sind, hat ConfigMap Vorrang. Stdout- und stderr-Protokolle werden nur dann in der ContainerLog-Tabelle erfasst, wenn sowohl DCR als auch ConfigMap explizit auf deaktiviert festgelegt sind.

Kubernetes-Metadaten- und Protokollfilterung

Die Kubernetes-Metadaten- und Protokollfilterung verbessert das ContainerLogsV2-Schema mit mehr Kubernetes-Metadaten wie PodLabels, PodAnnotations, PodUid, ImageID, ImageRepo und ImageTag. Darüber hinaus bietet das Protokollfilterfeature Filterfunktionen für Workload- und Plattformcontainer (d. h. Systemnamespaces). Mit diesen Features erhalten Benutzerinnen und Benutzer umfassenderen Kontext und verbessern die Sichtbarkeit ihrer Workloads.

Schlüsselfunktionen

• Erweitertes ContainerLogV2-Schema mit Kubernetes-Metadatenfeldern: Kubernetes Logs Metadata führt weitere optionale Metadatenfelder ein, die die Problembehandlung mit einfachen Log Analytics-Abfragen verbessern und die Notwendigkeit für die Verknüpfung mit anderen Tabellen entfernen. Zu diesen Feldern gehören wichtige Informationen wie PodLabels, PodAnnotations, PodUid, ImageID, ImageRepo und ImageTag. Wenn dieser Kontext leicht verfügbar ist, können Benutzerinnen und Benutzer ihre Problembehandlung beschleunigen und die Probleme schnell identifizieren.

• Benutzerdefinierte Konfiguration der Include-Liste: Benutzerinnen und Benutzer können neue Metadatenfelder, die sie sehen möchten, durch Bearbeiten der configmap anpassen. Beachten Sie, dass standardmäßig alle Metadatenfelder erfasst werden, wenn metadata_collection aktiviert ist. Wenn Sie bestimmte Felder auswählen möchten, entfernen Sie das Kommentarzeichen für include_fields und geben die Felder an, die erfasst werden sollen.

• Erweitertes ContainerLogV2-Schema mit Protokollebene: Benutzerinnen und Benutzer können jetzt den Anwendungsstatus basierend auf farbcodierten Schweregraden wie CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE oder UNKNOWN bewerten. Es ist ein wichtiges Tool für die Reaktion auf Vorfälle und eine proaktive Überwachung. Durch die visuelle Unterscheidung von Schweregraden können Benutzerinnen und Benutzer betroffene Ressourcen schnell identifizieren. Das farbcodierte System optimiert den Untersuchungsprozess und ermöglicht es Benutzerinnen und Benutzern, einen tiefergehenden Drilldown durchzuführen, indem sie den Bereich auswählen, um weitere Debuggingfunktionen zu erhalten. Es ist jedoch wichtig zu beachten, dass diese Funktion nur bei Verwendung von Grafana zur Verfügung steht. Wenn Sie den Log Analytics-Arbeitsbereich verwenden, ist LogLevel einfach eine weitere Spalte in der Tabelle „ContainerLogV2“.

• Anmerkungsbasierte Protokollfilterung für Workloads: Effiziente Protokollfilterung über Pod Annotations. Benutzerinnen und Benutzer können sich auf relevante Informationen konzentrieren, ohne sich durch Störgeräusche zu kämpfen. Die auf Anmerkungen basierende Filterung ermöglicht es Benutzerinnen und Benutzern, die Protokollerfassung für bestimmte Pods und Container auszuschließen, indem sie den Pod mit einer Anmerkung versehen, was die Kosten für die Protokollanalyse erheblich senken würde.

• ConfigMap-basierte Protokollfilterung für Plattformprotokolle (System Kubernetes-Namespaces): Plattformprotokolle werden von Containern im Systemnamespace (oder ähnlich eingeschränkten) Namespaces ausgegeben. Standardmäßig werden alle Containerprotokolle aus dem Systemnamespace ausgeschlossen, um die Log Analytics-Kosten zu minimieren. In bestimmten Fällen der Problembehandlung spielen die Containerprotokolle der Systemcontainer jedoch eine entscheidende Rolle. Nehmen Sie zum Beispiel den coredns-Container im kube-system-Namensraum. Um Protokolle (stdout und stderr) ausschließlich vom coredns Container aus kube-system zu sammeln, können Sie die folgenden Einstellungen in der configmap aktivieren.

• Grafana-Dashboard zur Visualisierung: Das Grafana-Dashboard zeigt nicht nur farbcodierte Visualisierungen der Protokollstufen von CRITICAL bis UNKNOWN, sondern auch Protokollvolumen, Protokollrate, Protokollsätze und Protokolle. Benutzerinnen und Benutzer erhalten zeitabhängige Analysen, dynamische Einblicke in die Entwicklung der Protokolldaten im Laufe der Zeit und eine wichtige Echtzeitüberwachung. Darüber hinaus bieten wir eine detaillierte Aufschlüsselung nach Computern, Pods und Containern, die eine eingehende Analyse und gezielte Problembehandlung ermöglicht. Und schließlich können Benutzerinnen und Benutzer in der neuen Logs-Tabelle mit der Erweiterungsansicht detaillierte Informationen anzeigen, die Daten in jeder Spalte betrachten und in die gewünschten Informationen hineinzoomen.

Hier ist ein Video, das das Grafana Dashboard zeigt:

Aktivieren der Kubernetes-Metadaten- und Protokollfilterung

Voraussetzungen

1. Migrieren zur Authentifizierung der verwalteten Identitäten Weitere Informationen.

2. Stellen Sie sicher, dass ContainerLogV2 aktiviert ist. Für Cluster zur Authentifizierung der verwalteten Identitäten ist dieses Schema standardmäßig aktiviert. Wenn nicht, aktivieren Sie das ContainerLogV2-Schema.

Begrenzungen

Das ContainerLogV2 Grafana-Dashboard wird mit der Standardprotokoll-SKU in der Tabelle „ContainerLogV2“ nicht unterstützt.

Aktivieren von Kubernetes-Metadaten

1. Laden Sie die configmap herunter, und ändern Sie die Einstellungen von false in true, wie im folgenden Screenshot dargestellt. Beachten Sie, dass alle unterstützten Metadatenfelder standardmäßig erfasst werden. Wenn Sie bestimmte Felder erfassen möchten, geben Sie die erforderlichen Felder in include_fields an.

2. Wenden Sie die ConfigMap an. Weitere Informationen zum Bereitstellen und Konfigurieren der ConfigMap finden Sie unter configmap konfigurieren.

3. Nach ein paar Minuten sollten die Daten in Ihre ContainerLogV2-Tabelle mit Kubernetes Logs Metadaten fließen, wie im folgenden Screenshot zu sehen ist.

Onboarding in die Grafana-Dashboardoberfläche

1. Wählen Sie auf der Registerkarte „Insights“ die Überwachungseinstellungen und wechseln Sie zu Grafana Dashboard mit Version 10.3.4+.

2. Vergewissern Sie sich, dass Sie eine der Grafana-Rollen Admin/Editor/Reader haben, indem Sie Zugriffskontrolle (IAM) aktivieren. Wenn dies nicht der Fall ist, fügen Sie sie hinzu.

3. Stellen Sie sicher, dass Ihre Grafana-Instanz Zugriff auf den Arbeitsbereich Azure Logs Analytics (LA) hat. Wenn sie keinen Zugriff hat, müssen Sie der Benutzerrolle mit Leseberechtigung für Überwachungsdaten der Grafana-Instanz Zugriff auf Ihren LA-Arbeitsbereich gewähren.

4. Navigieren Sie zu Ihrem Grafana Arbeitsbereich und importieren Sie das ContainerLogV2 Dashboard aus dem Grafana-Katalog.

5. Wählen Sie Ihre Informationen für DataSource, Subscription, ResourceGroup, Cluster, Namespace und Bezeichnungen aus. Das Dashboard wird dann wie im folgenden Screenshot dargestellt aufgefüllt.

Hinweis

Wenn Sie das Grafana Dashboard zum ersten Mal laden, kann es zu Fehlern kommen, weil die Variablen noch nicht ausgewählt sind. Um dies zu verhindern, speichern Sie das Dashboard, nachdem Sie eine Reihe von Variablen ausgewählt haben, damit es beim ersten Öffnen als Standard festgelegt wird.

Aktivieren der anmerkungsbasierten Filterung

Führen Sie die unten aufgeführten Schritte aus, um das anmerkungsbasierte Filtern zu aktivieren. Hier finden Sie den Link, sobald die zugehörige Filterdokumentation veröffentlicht wurde.

1. Laden Sie die configmap herunter, und ändern Sie die Einstellungen von „false“ in „true“, wie im folgenden Screenshot dargestellt.

2. Wenden Sie die ConfigMap an. Weitere Informationen zum Bereitstellen und Konfigurieren der ConfigMap finden Sie unter configmap konfigurieren.

3. Fügen Sie die erforderlichen Anmerkungen zur-Pod-Spezifikation Ihrer Workload hinzu. In der folgenden Tabelle werden verschiedene mögliche Pod-Anmerkungen und Beschreibungen ihrer Aufgaben hervorgehoben.

Anmerkung	Beschreibung
fluentbit.io/exclude: "true"	Schließt sowohl stdout- als auch stderr-Datenströme für alle Container im Pod aus.
fluentbit.io/exclude_stdout: "true"	Schließt nur den stdout-Datenstrom für alle Container im Pod aus.
fluentbit.io/exclude_stderr: "true"	Schließt nur stderr-Datenstrom für alle Container im Pod aus.
fluentbit.io/exclude_container1: "true"	Schließen beide stdout- und stderr-Datenströme nur für den Container1 im Pod aus.
fluentbit.io/exclude_stdout_container1: "true"	Schließen nur stdout für den Container1 im Pod aus.

Hinweis

Diese Anmerkungen sind Fluent-Bit-basiert. Wenn Sie Ihre eigene, auf Fluent-Bit basierende Lösung zum Sammeln von Protokollen mit dem Kubernetes-Plugin-Filter und dem anmerkungsbasierten Ausschluss verwenden, werden keine Protokolle mehr sowohl von Container Insights als auch von Ihrer Lösung gesammelt.

Nachfolgend sehen Sie ein Beispiel für fluentbit.io/exclude: "true"-Anmerkungen in der Pod-Spezifikation:

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-basierte Protokollfilterung für Plattformprotokolle (System Kubernetes-Namespaces)

1. Laden Sie die configmap herunter, und ändern Sie die Einstellungen für collect_system_pod_logs und exclude_namespaces.

Wenn Sie beispielsweise stdout- und stderr-Protokolle des coredns-Containers im kube-system-Namensraum sammeln möchten, stellen Sie sicher, dass der kube-system-Namespace nicht in exclude_namespaces enthalten ist und diese Funktion nur auf die folgenden System-Namespaces beschränkt ist: kube-system, gatekeeper-system, calico-system, azure-arc, kube-public und kube-node-lease-Namespaces.

2. Wenden Sie die ConfigMap an. Weitere Informationen zum Bereitstellen und Konfigurieren der ConfigMap finden Sie unter configmap konfigurieren.

Mehrzeilige Protokollierung in Container Insights

Wenn die mehrzeilige Protokollierung aktiviert ist, werden zuvor geteilte Containerprotokolle zusammengefügt und als einzelne Einträge an die Tabelle ContainerLogV2 gesendet. Wenn die zusammengefügte Protokollzeile größer als 64 KB ist, wird sie aufgrund der Grenzwerte des Log Analytics-Arbeitsbereichs abgeschnitten. Dieses Feature bietet auch Unterstützung für .NET-, Go-, Python- und Java-Stapelüberwachungen, die als einzelne Einträge in der ContainerLogV2-Tabelle angezeigt werden. Aktivieren Sie die mehrzeilige Protokollierung mit ConfigMap, wie in Konfigurieren der Datensammlung in Container Insights mithilfe von ConfigMap beschrieben.

Hinweis

Die configmap verfügt jetzt über eine Sprachspezifikationsoption, bei der Kunden nur die Sprachen auswählen können, an denen sie interessiert sind. Dieses Feature kann durch Bearbeiten der Sprachen in der Option stacktrace_languages in der Configmapaktiviert werden.

Die folgenden Screenshots zeigen die mehrzeilige Protokollierung für die Go-Ausnahmestapelüberwachung:

Mehrzeilige Protokollierung deaktiviert

Mehrzeilige Protokollierung aktiviert

Java-Stapelüberwachung

Python-Stapelüberwachung

Nächste Schritte

• Konfigurieren Sie die Basisprotokolle für ContainerLogv2.
• Erfahren Sie, wie Sie aus ContainerLogV2 Daten abfragen.