Schemat dziennika usługi Container Insights

Usługa Container Insights przechowuje dane dziennika, które zbiera w tabeli o nazwie ContainerLogV2. W tym artykule opisano schemat tej tabeli oraz jej porównanie i migrację ze starszej tabeli ContainerLog .

Ważne

ContainerLogV2 będzie domyślnym schematem za pośrednictwem narzędzia ConfigMap dla interfejsu wiersza polecenia w wersji 2.54.0 lub nowszej. KontenerLogV2 będzie domyślnym formatem pozyskiwania dla klientów, którzy będą dołączać szczegółowe informacje o kontenerze przy użyciu uwierzytelniania tożsamości zarządzanej przy użyciu usługi ARM, Bicep, Terraform, zasad i dołączania portalu. KontenerLogV2 można jawnie włączyć za pomocą interfejsu wiersza polecenia w wersji 2.51.0 lub nowszej przy użyciu ustawień zbierania danych.

Obsługa tabeli ContainerLog zostanie wycofana 30 września 2026 r.

Porównanie tabel

W poniższej tabeli przedstawiono najważniejsze różnice między używaniem schematu ContainerLogV2 i ContainerLog.

Różnice między funkcjami	ContainerLog	ContainerLogV2
Schemat	Szczegółowe informacje na stronie ContainerLog.	Szczegóły na stronie ContainerLogV2. Dodatkowe kolumny to: - ContainerName - PodName - PodNamespace - LogLevel1 - KubernetesMetadata2
Wprowadzanie	Można konfigurować tylko za pomocą narzędzia ConfigMap.	Konfigurowalne za pomocą narzędzia ConfigMap i DCR. 3
Cennik	Tylko zgodne z pełnowartościowymi dziennikami analitycznymi.	Obsługuje warstwę dzienników podstawowych o niskich kosztach oprócz dzienników analitycznych.
Wykonywanie zapytania	Wymaga wielu operacji sprzężenia z tabelami spisu dla standardowych zapytań.	Zawiera dodatkowe metadane zasobnika i kontenera, aby zmniejszyć złożoność zapytań i operacje łączenia.
Wiele wierszy	Nieobsługiwane wpisy wielowierszowe są podzielone na wiele wierszy.	Obsługa rejestrowania wielowierszowego w celu umożliwienia skonsolidowanych, pojedynczych wpisów dla danych wyjściowych wielowierszowych.

¹Jeśli logMessage jest prawidłowym kodem JSON i ma klucz o nazwie level, zostanie użyta jego wartość. W przeciwnym razie użyjemy podejścia do dopasowywania słów kluczowych opartych na wyrażeniach regularnych, aby wywnioskować element LogLevel z samej funkcji LogMessage. Pamiętaj, że niektóre błędy klasyfikacji mogą być widoczne, ponieważ ta wartość jest wywnioskowana.

²Platforma KubernetesMetadata jest opcjonalną kolumną, a kolekcja tego pola może być włączona za pomocą funkcji metadanych platformy Kubernetes. Wartość tego pola to JSON i zawiera pola, takie jak podLabels, podAnnotations, podUid, Image, ImageTag i Image repo.

³Konfiguracja dcR nie jest obsługiwana w przypadku klastrów korzystających z klastrów opartych na uwierzytelnianiu jednostki usługi. Aby korzystać z tego środowiska, przeprowadź migrację klastrów z jednostką usługi do tożsamości zarządzanej.

Uwaga

Eksportowanie do centrum zdarzeń i konta magazynu nie jest obsługiwane, jeśli przychodzący komunikat LogMessage nie jest prawidłowym plikiem JSON. Aby uzyskać najlepszą wydajność, zalecamy emitowanie dzienników kontenerów w formacie JSON.

Ocena wpływu na istniejące alerty

Przed włączeniem schematu ContainerLogsV2 należy ocenić, czy istnieją reguły alertów, które opierają się na tabeli ContainerLog . Aby korzystać z nowej tabeli, należy zaktualizować wszystkie takie alerty.

Aby przeprowadzić skanowanie pod kątem alertów odwołujących się do tabeli ContainerLog , uruchom następujące zapytanie usługi Azure Resource Graph:

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

Włączanie schematu ContainerLogV2

Można włączyć schemat ContainerLogV2 dla klastra przy użyciu reguły zbierania danych klastra (DCR) lub ConfigMap. Jeśli oba ustawienia są włączone, pierwszeństwo ma ConfigMap. Dzienniki Stdout i stderr są pozyskiwane tylko do tabeli ContainerLog, gdy zarówno dcR, jak i ConfigMap są jawnie wyłączone.

Filtrowanie metadanych i dzienników platformy Kubernetes

Filtrowanie metadanych i dzienników kubernetes rozszerza schemat ContainerLogsV2 dzięki większej zwiększeniu liczby metadanych platformy Kubernetes, takich jak PodLabels, PodAnnotations, PodUid, ImageID, ImageRepo i ImageTag. Ponadto funkcja filtrowania dzienników zapewnia funkcje filtrowania zarówno dla kontenerów obciążeń, jak i platformy (czyli przestrzeni nazw systemowych). Dzięki tym funkcjom użytkownicy uzyskują bogatszy kontekst i lepszy wgląd w obciążenia.

Kluczowe cechy i funkcje

• Ulepszony schemat ContainerLogV2 z polami metadanych platformy Kubernetes: Metadane dzienników kubernetes wprowadza inne opcjonalne pola metadanych, które zwiększają środowisko rozwiązywania problemów przy użyciu prostych zapytań usługi Log Analytics i eliminuje potrzebę łączenia z innymi tabelami. Te pola obejmują podstawowe informacje, takie jak "PodLabels", "PodAnnotations", "PodUid", "ImageID", "ImageID", "ImageRepo" i "ImageTag". Dzięki łatwej dostępności tego kontekstu użytkownicy mogą przyspieszyć rozwiązywanie problemów i szybko zidentyfikować problemy.

• Niestandardowa konfiguracja listy dołączania: użytkownicy mogą dostosować nowe pola metadanych, które chcą zobaczyć podczas edytowania mapy konfiguracji. Należy pamiętać, że wszystkie pola metadanych są zbierane domyślnie, gdy metadata_collection jest włączona, a jeśli chcesz wybrać określone pola, usuń komentarz include_fields i określ pola, które należy zebrać.

• Ulepszony schemat ContainerLogV2 z poziomem dziennika: użytkownicy mogą teraz oceniać kondycję aplikacji na podstawie poziomów ważności kodowanych kolorami, takich jak KRYTYCZNE, BŁĄD, OSTRZEŻENIE, INFO, DEBUG, TRACE lub UNKNOWN. Jest to kluczowe narzędzie do reagowania na zdarzenia i proaktywnego monitorowania. Wizualnie rozróżniając poziomy ważności, użytkownicy mogą szybko wskazać zasoby, których dotyczy problem. System kodowany kolorami usprawnia proces badania i umożliwia użytkownikom dalsze przechodzenie do szczegółów, wybierając panel na potrzeby eksplorowania w celu dalszego debugowania. Należy jednak pamiętać, że ta funkcja ma zastosowanie tylko w przypadku korzystania z narzędzia Grafana. Jeśli używasz obszaru roboczego usługi Log Analytics, wartość LogLevel to po prostu kolejna kolumna w tabeli ContainerLogV2.

• Filtrowanie dzienników na podstawie adnotacji dla obciążeń: efektywna technika filtrowania dzienników za pomocą adnotacji zasobników. Użytkownicy mogą skupić się na odpowiednich informacjach bez przesiewania szumu. Filtrowanie oparte na adnotacjach umożliwia użytkownikom wykluczanie zbierania dzienników dla niektórych zasobników i kontenerów przez dodawanie adnotacji do zasobnika, co znacznie zmniejszyłoby koszt analizy dzienników.

• Filtrowanie dzienników opartych na programie ConfigMap dla dzienników platformy (przestrzenie nazw platformy Kubernetes): dzienniki platformy są emitowane przez kontenery w systemach (lub podobnych ograniczonych) przestrzeniach nazw. Domyślnie wszystkie dzienniki kontenera z przestrzeni nazw systemu są wykluczone, aby zminimalizować koszt usługi Log Analytics. Jednak w określonych scenariuszach rozwiązywania problemów dzienniki kontenera kontenera pełnią kluczową rolę. Rozważmy na przykład kontener coredns w przestrzeni nazw kube-system. Aby zbierać dzienniki (stdout i stderr) wyłącznie z kontenera coredns formularza kube-system, możesz włączyć następujące ustawienia w mapie konfiguracji.

• Pulpit nawigacyjny narzędzia Grafana do wizualizacji: pulpit nawigacyjny narzędzia Grafana nie tylko wyświetla wizualizacje z kolorami poziomów dzienników, od KRYTYCZNY do NIEZNANY, ale także szczegółowe informacje na temat woluminu dziennika, szybkości dzienników, rekordów dzienników, dzienników. Użytkownicy mogą uzyskiwać analizę czasową, dynamiczny wgląd w trendy na poziomie dziennika w czasie i kluczowe monitorowanie w czasie rzeczywistym. Udostępniamy również szczegółowy podział według komputerów, zasobników i kontenerów, co umożliwia szczegółową analizę i wskazanie rozwiązywania problemów. Na koniec w nowym środowisku tabeli Dzienniki użytkownicy mogą wyświetlać szczegółowe informacje z widokiem rozwijania i wyświetlać dane w każdej kolumnie i powiększać informacje, które chcą zobaczyć.

Oto wideo przedstawiające pulpit nawigacyjny narzędzia Grafana:

Jak włączyć filtrowanie metadanych i dzienników kubernetes

Wymagania wstępne

1. Migrowanie do uwierzytelniania tożsamości zarządzanej. Dowiedz się więcej.

2. Upewnij się, że opcja ContainerLogV2 jest włączona. Klastry uwierzytelniania tożsamości zarządzanej mają domyślnie włączony ten schemat. Jeśli nie, włącz schemat ContainerLogV2.

Ograniczenia

Pulpit nawigacyjny ContainerLogV2 Grafana nie jest obsługiwany w przypadku jednostki SKU dzienników podstawowych w tabeli ContainerLogV2.

Włączanie metadanych platformy Kubernetes

1. Pobierz configmap i zmodyfikuj ustawienia z wartości false na true, jak pokazano na poniższym zrzucie ekranu. Należy pamiętać, że wszystkie obsługiwane pola metadanych są domyślnie zbierane. Jeśli chcesz zebrać określone pola, określ wymagane pola w pliku include_fields.

2. Zastosuj ConfigMap. Zobacz konfigurowanie mapy konfiguracji , aby dowiedzieć się więcej na temat wdrażania i konfigurowania obiektu ConfigMap.

3. Po kilku minutach dane powinny być przepływane do tabeli ContainerLogV2 za pomocą metadanych dzienników kubernetes, jak pokazano na poniższym zrzucie ekranu.

Dołączanie do środowiska pulpitu nawigacyjnego narzędzia Grafana

1. Na karcie Szczegółowe informacje wybierz pozycję Monitorowanie ustawień i dołącz do pulpitu nawigacyjnego narzędzia Grafana w wersji 10.3.4 lub nowszej

2. Upewnij się, że masz jedną z ról narzędzia Grafana Administracja/edytora/czytelnika, sprawdzając pozycję Kontrola dostępu (IAM). Jeśli nie, dodaj je.

3. Upewnij się, że wystąpienie narzędzia Grafana ma dostęp do obszaru roboczego usługi Azure Logs Analytics (LA). Jeśli nie ma dostępu, musisz przyznać roli Czytelnik monitorowania wystąpień narzędzia Grafana do obszaru roboczego la.

4. Przejdź do obszaru roboczego narzędzia Grafana i zaimportuj pulpit nawigacyjny ContainerLogV2 z galerii Grafana.

5. Wybierz informacje dotyczące źródła danych, subskrypcji, grupy zasobów, klastra, przestrzeni nazw i etykiet. Następnie pulpit nawigacyjny zostanie wypełniony, jak pokazano na poniższym zrzucie ekranu.

Uwaga

Podczas początkowego ładowania pulpitu nawigacyjnego narzędzia Grafana może on zgłaszać błędy z powodu nie zaznaczonych zmiennych. Aby zapobiec temu cyklicznemu, zapisz pulpit nawigacyjny po wybraniu zestawu zmiennych, aby stał się domyślnym ustawieniem pierwszego otwarcia.

Włączanie filtrowania opartego na adnotacjach

Wykonaj poniższe kroki, aby włączyć filtrowanie oparte na adnotacjach. Link można znaleźć tutaj po opublikowaniu powiązanej dokumentacji filtrowania.

1. Pobierz configmap i zmodyfikuj ustawienia z wartości false na true, jak pokazano na poniższym zrzucie ekranu.

2. Zastosuj ConfigMap. Zobacz konfigurowanie mapy konfiguracji , aby dowiedzieć się więcej na temat wdrażania i konfigurowania obiektu ConfigMap.

3. Dodaj wymagane adnotacje na specyfikacji zasobnika obciążenia. W poniższej tabeli przedstawiono różne możliwe adnotacje i opisy tego, co robią.

Adnotacja	opis
fluentbit.io/exclude: "true"	Wyklucza oba strumienie stdout i stderr we wszystkich kontenerach w zasobniku
fluentbit.io/exclude_stdout: "true"	Wyklucza tylko strumień stdout we wszystkich kontenerach w zasobniku
fluentbit.io/exclude_stderr: "true"	Wyklucza tylko strumień stderr we wszystkich kontenerach w zasobniku
fluentbit.io/exclude_container1: "true"	Wyklucz oba strumienie stdout i stderr tylko dla kontenera1 w zasobniku
fluentbit.io/exclude_stdout_container1: "true"	Wyklucz tylko stdout tylko dla kontenera1 w zasobniku

Uwaga

Te adnotacje są płynnie oparte na bitach. Jeśli używasz własnego rozwiązania do zbierania dzienników opartych na płynnym bitzie z filtrem wtyczki Kubernetes i wykluczeniem opartym na adnotacjach, przestanie zbierać dzienniki zarówno z Szczegółowe informacje kontenera, jak i rozwiązania.

Oto przykład adnotacji w specyfikacji fluentbit.io/exclude: "true" zasobnika:

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 

Filtrowanie dzienników opartych na mapie dla dzienników platformy (przestrzenie nazw platformy System Kubernetes)

1. Pobierz configmap i zmodyfikuj ustawienia powiązane z collect_system_pod_logs elementami i exclude_namespaces.

Na przykład w celu zbierania dzienników stdout i stderr kontenera coredns w przestrzeni nazw kube-system upewnij się, że przestrzeń nazw kube-system nie znajduje się i exclude_namespaces ta funkcja jest ograniczona tylko do następujących przestrzeni nazw systemowych: kube-system, gatekeeper-system, calico-system, azure-arc, kube-public i kube-node-lease przestrzeni nazw.

2. Zastosuj ConfigMap. Zobacz konfigurowanie mapy konfiguracji , aby dowiedzieć się więcej na temat wdrażania i konfigurowania obiektu ConfigMap.

Rejestrowanie wielowierszowe w usłudze Container Szczegółowe informacje

Po włączeniu rejestrowania wielowierszowego wcześniej podzielone dzienniki kontenerów są łączone i wysyłane jako pojedyncze wpisy do tabeli ContainerLogV2. Jeśli linia dziennika szwów jest większa niż 64 KB, zostanie obcięta z powodu limitów obszaru roboczego usługi Log Analytics. Ta funkcja obsługuje również ślady stosu .NET, Go, Python i Java, które są wyświetlane jako pojedyncze wpisy w tabeli ContainerLogV2. Włącz rejestrowanie wielowierszowe za pomocą narzędzia ConfigMap zgodnie z opisem w temacie Konfigurowanie zbierania danych w usłudze Container Insights przy użyciu narzędzia ConfigMap.

Uwaga

Mapa konfiguracji zawiera teraz opcję specyfikacji języka, w której klienci mogą wybrać tylko języki, które cię interesują. Tę funkcję można włączyć, edytując języki w opcji stacktrace_languages na mapie konfiguracji.

Na poniższych zrzutach ekranu przedstawiono rejestrowanie wielowierszowe dla śledzenia stosu wyjątków języka Go:

Rejestrowanie wielowierszowe jest wyłączone

Włączono rejestrowanie wielowierszowe

Ślad stosu języka Java

Ślad stosu języka Python

Następne kroki

• Skonfiguruj podstawowe dzienniki dla konteneraLogv2.
• Dowiedz się, jak wykonywać zapytania o dane z konteneraLogV2