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 - LogLevel 1- KubernetesMetadata 2 |
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. |
1Wenn 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.
2KubernetesMetadata 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.
3DCR-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ürinclude_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
Migrieren zur Authentifizierung der verwalteten Identitäten Weitere Informationen.
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
- 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.
Wenden Sie die ConfigMap an. Weitere Informationen zum Bereitstellen und Konfigurieren der ConfigMap finden Sie unter configmap konfigurieren.
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
- Wählen Sie auf der Registerkarte „Insights“ die Überwachungseinstellungen und wechseln Sie zu Grafana Dashboard mit Version 10.3.4+.
- 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.
- 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.
Navigieren Sie zu Ihrem Grafana Arbeitsbereich und importieren Sie das ContainerLogV2 Dashboard aus dem Grafana-Katalog.
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.
- Laden Sie die configmap herunter, und ändern Sie die Einstellungen von „false“ in „true“, wie im folgenden Screenshot dargestellt.
Wenden Sie die ConfigMap an. Weitere Informationen zum Bereitstellen und Konfigurieren der ConfigMap finden Sie unter configmap konfigurieren.
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)
- Laden Sie die configmap herunter, und ändern Sie die Einstellungen für
collect_system_pod_logs
undexclude_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.
- 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.