Share via

Схема журнала аналитики контейнеров

  • Статья

Аналитика контейнеров хранит данные журнала, собираемые в таблице с именем ContainerLogV2. В этой статье описывается схема этой таблицы и ее сравнение и миграция из устаревшей таблицы ContainerLog .

Внимание

ContainerLogV2 будет схемой по умолчанию с помощью ConfigMap для CLI версии 2.54.0 и более поздней. ContainerLogV2 будет формат приема по умолчанию для клиентов, которые будут подключены к аналитике контейнеров с помощью проверки подлинности управляемого удостоверения с помощью ARM, Bicep, Terraform, политики и портала. КонтейнерLogV2 можно явно включить с помощью ИНТЕРФЕЙСА командной строки 2.51.0 или более поздней с помощью параметров сбора данных.

Поддержка таблицы ContainerLog будет прекращена 30 сентября 2026 г.

Сравнение таблиц

В следующей таблице перечислены основные различия между использованием схемы ContainerLogV2 и ContainerLog.

Отличия функций Журнал контейнера ContainerLogV2
Схема Сведения в ContainerLog. Сведения о ContainerLogV2.
Дополнительные столбцы:
- ContainerName
- PodName
- PodNamespace
- LogLevel1
- KubernetesMetadata2
Переход Настраивается только с помощью ConfigMap. Настраиваемая с помощью ConfigMap и DCR. 3
Цены Совместим только с журналами аналитики с полной ценой. Поддерживает уровень базовых журналов с низкими затратами в дополнение к журналам аналитики.
Выполнение запроса Требуется несколько операций соединения с таблицами инвентаризации для стандартных запросов. Включает дополнительные метаданные pod и контейнера для уменьшения сложности запросов и операций соединения.
Многострочный Не поддерживается многострочное разделение записей на несколько строк. Поддержка многострочного ведения журнала, разрешая консолидированные однозаготовые записи для многострочных выходных данных.

1Если LogMessage является допустимым JSON и имеет уровень именованного ключа, будет использоваться его значение. В противном случае для вывода LogLevel из самого LogMessage используется регрессия на основе ключевое слово сопоставления. Обратите внимание, что некоторые неправильные классификации могут отображаться, так как это значение выводится.

2KubernetesMetadata является необязательным столбцом и коллекцией этого поля можно включить с помощью функции метаданных Kubernetes. Значением этого поля является JSON, и он содержит такие поля, как podLabels, podAnnotations, podUid, Image, ImageTag и Image repo.

Конфигурация DCR 3не поддерживается для кластеров с использованием кластеров на основе проверки подлинности субъекта-службы. Чтобы использовать этот интерфейс, перенесите кластеры с субъектом-службой в управляемое удостоверение.

Примечание.

Экспорт в Концентратор событий и учетная запись служба хранилища не поддерживается, если входящий logMessage не является допустимым JSON. Для повышения производительности рекомендуется создавать журналы контейнеров в формате JSON.

Оценка влияния на существующие оповещения

Прежде чем включить схему ContainerLogsV2 , необходимо оценить наличие правил генерации оповещений, использующих таблицу ContainerLog . Для использования новой таблицы необходимо обновить все такие оповещения.

Чтобы проверить наличие оповещений, ссылающихся на таблицу ContainerLog , выполните следующий запрос 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

Включение схемы ContainerLogV2

Схему ContainerLogV2 для кластера можно включить с помощью правила сбора данных кластера (DCR) или ConfigMap. Если оба параметра включены, ConfigMap имеет приоритет. Журналы Stdout и stderr отправляются только в таблицу ContainerLog, если DCR и ConfigMap явно настроены.

Фильтрация метаданных и журналов Kubernetes

Фильтрация метаданных и журналов Kubernetes улучшает схему ContainerLogsV2 с большими метаданными Kubernetes, такими как PodLabels, PodAnnotations, PodUid, ImageID, ImageID, ImageRepo и ImageTag. Кроме того, функция фильтрации журналов предоставляет возможности фильтрации для контейнеров рабочей нагрузки и платформы (то есть системных пространств имен). Благодаря этим функциям пользователи получают более широкий контекст и улучшают видимость рабочих нагрузок.

Ключевые функции

  • Расширенная схема ContainerLogV2 с полями метаданных Kubernetes. Метаданные журналов Kubernetes представляют другие необязательные поля метаданных, которые повышают удобство устранения неполадок с простыми запросами Log Analytics и удаляют необходимость объединения с другими таблицами. Эти поля включают основные сведения, такие как PodLabels, PodAnnotations, PodUid, ImageID, ImageID, ImageRepo и ImageTag. Имея этот контекст легкодоступным, пользователи могут быстро устранять неполадки и выявлять проблемы.

  • Настраиваемая конфигурация списка: пользователи могут настраивать новые поля метаданных, которые они хотят просмотреть, изменив конфигурацию. Обратите внимание, что все поля метаданных собираются по умолчанию, когда metadata_collection включена и если вы хотите выбрать определенные поля, раскомментировать include_fields и указать поля, которые необходимо собрать.

Снимок экрана: поля метаданных.

  • Расширенная схема ContainerLogV2 с уровнем журнала: теперь пользователи могут оценивать работоспособность приложений на основе цветового уровня серьезности, таких как КРИТИЧЕСКОЕ, ОШИБКА, ПРЕДУПРЕЖДЕНИЕ, ИНФОРМАЦИЯ, ОТЛАДКА, ТРАССИРОВКА или НЕИЗВЕСТНО. Это важный инструмент для реагирования на инциденты и упреждающего мониторинга. Визуально различая уровни серьезности, пользователи могут быстро определить затронутые ресурсы. Цветовая система упрощает процесс исследования и позволяет пользователям детализировать еще больше, выбрав панель для изучения для дальнейшего отладки. Однако важно отметить, что эта функция применима только при использовании Grafana. Если вы используете рабочую область Log Analytics, LogLevel — это просто другой столбец в таблице ContainerLogV2.

  • Фильтрация журналов на основе заметок для рабочих нагрузок: эффективный метод фильтрации журналов с помощью заметок Pod. Пользователи могут сосредоточиться на релевантной информации, не просеивая шум. Фильтрация на основе заметок позволяет пользователям исключить коллекцию журналов для определенных модулей pod и контейнеров, заключив модуль pod, что поможет значительно сократить затраты на аналитику журналов.

  • Фильтрация журналов на основе ConfigMap для журналов платформы (пространства имен System Kubernetes): журналы платформы создаются контейнерами в пространствах имен системы (или аналогичных ограниченных). По умолчанию все журналы контейнеров из системного пространства имен исключаются, чтобы свести к минимуму затраты Log Analytics. Однако в конкретных сценариях устранения неполадок журналы контейнеров системного контейнера играют важную роль. Например, рассмотрим контейнер coredns в пространстве имен kube-system. Чтобы собирать журналы (stdout и stderr) исключительно из формы kube-system формы coredns, можно включить следующие параметры в файле конфигурации.

Снимок экрана: поля фильтрации.

  • Панель мониторинга Grafana для визуализации: панель мониторинга Grafana отображает не только цветовые визуализации уровней журналов, начиная от КРИТИЧЕСКИ ВАЖНЫх до НЕИЗВЕСТНЫх, но и сведения о томе журнала, частоте журналов, записях журналах, журналах. Пользователи могут получать анализ с учетом времени, динамические аналитические сведения о тенденциях уровня журнала с течением времени и критически важный мониторинг в режиме реального времени. Кроме того, мы предоставляем подробную разбивку по компьютеру, pod и контейнеру, что обеспечивает подробный анализ и точное устранение неполадок. И, наконец, в новом интерфейсе таблицы журналов пользователи могут просматривать подробные сведения с расширением представления и просматривать данные в каждом столбце и увеличивать масштаб информации, которую они хотят видеть.

Вот видео, показывающее панель мониторинга Grafana:

Включение фильтрации метаданных и журналов Kubernetes

Необходимые компоненты

  1. Миграция на проверку подлинности управляемого удостоверения. Подробнее здесь.

  2. Убедитесь, что контейнер ContainerLogV2 включен. Кластеры проверки подлинности управляемых удостоверений включают эту схему по умолчанию. Если нет, включите схему ContainerLogV2.

Ограничения

Панель мониторинга ContainerLogV2 Grafana не поддерживается с номером SKU "Базовые журналы" в таблице ContainerLogV2.

Включение метаданных Kubernetes

  1. Скачайте карту конфигурации и измените параметры с false на true, как показано на снимке экрана ниже. Обратите внимание, что все поддерживаемые поля метаданных собираются по умолчанию. Если вы хотите собрать определенные поля, укажите необходимые поля в include_fields.

Снимок экрана: включение полей метаданных.

  1. Примените ConfigMap. Дополнительные сведения о развертывании и настройке ConfigMap см . в разделе "Настройка конфигурации ".

  2. Через несколько минут данные должны передаваться в таблицу ContainerLogV2 с метаданными Журналов Kubernetes, как показано на снимке экрана ниже.

Снимок экрана: containerlogv2.

Подключение к панели мониторинга Grafana

  1. На вкладке Аналитика выберите параметры монитора и подключение к панели мониторинга Grafana с версией 10.3.4+

Снимок экрана: подключение grafana.

  1. Убедитесь, что у вас есть одна из ролей Grafana Администратор/Editor/Reader, проверка управления доступом (IAM). В противном случае добавьте их.

Снимок экрана: роли grafana.

  1. Убедитесь, что экземпляр Grafana имеет доступ к рабочей области Azure Logs Analytics(LA). Если у него нет доступа, необходимо предоставить роль средства чтения мониторинга экземпляров Grafana в рабочей области LA.

Снимок экрана: grafana.

  1. Перейдите в рабочую область Grafana и импортируйте панель мониторинга ContainerLogV2 из коллекции Grafana.

  2. Выберите сведения для DataSource, подписки, ResourceGroup, кластера, пространства имен и меток. Затем панель мониторинга заполняется, как показано на снимке экрана ниже.

Снимок экрана: панель мониторинга grafana.

Примечание.

При первоначальной загрузке панели мониторинга Grafana может возникнуть некоторые ошибки из-за переменных, которые еще не выбраны. Чтобы предотвратить повторение, сохраните панель мониторинга после выбора набора переменных, чтобы он стал по умолчанию на первом открытии.

Включение фильтрации на основе заметок

Выполните приведенные ниже упоминание действия, чтобы включить фильтрацию на основе заметок. Найдите ссылку после публикации соответствующей документации по фильтрации.

  1. Скачайте карту конфигурации и измените параметры с false на true, как показано на снимке экрана ниже.

Снимок экрана: заметки.

  1. Примените ConfigMap. Дополнительные сведения о развертывании и настройке ConfigMap см . в разделе "Настройка конфигурации ".

  2. Добавьте необходимые заметки в спецификацию pod рабочей нагрузки. В следующей таблице показаны различные возможные заметки и описания объектов Pod.

Номер Description
fluentbit.io/exclude: "true" Исключает потоки stdout и stderr во всех контейнерах в pod
fluentbit.io/exclude_stdout: "true" Исключает только поток stdout во всех контейнерах в pod.
fluentbit.io/exclude_stderr: "true" Исключает только поток stderr во всех контейнерах в Pod.
fluentbit.io/exclude_container1: "true" Исключение потоков stdout и stderr только для контейнера1 в pod
fluentbit.io/exclude_stdout_container1: "true" Исключение только stdout только для контейнера1 в pod

Примечание.

Эти заметки основаны на простом бите. Если вы используете собственное решение для сбора журналов на основе fluent-bit с фильтром подключаемых модулей Kubernetes и исключением на основе заметок, то он перестанет собирать журналы из контейнера Аналитика и вашего решения.

Ниже приведен пример заметки в спецификации fluentbit.io/exclude: "true" Pod:

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 для журналов платформы (пространства имен System Kubernetes)

  1. Скачайте карту конфигурации и измените параметры, связанные collect_system_pod_logs с ним.exclude_namespaces

Например, чтобы собирать журналы stdout и stderr контейнера coredns в пространстве имен kube-system, убедитесь, что пространство имен kube-system не включено exclude_namespaces , и эта функция ограничена только следующими пространствами имен системы: kube-system, gatekeeper-system, calico-system, azure-arc, kube-public и kube-node-lease namespaces.

Снимок экрана: поля фильтрации.

  1. Примените ConfigMap. Дополнительные сведения о развертывании и настройке ConfigMap см . в разделе "Настройка конфигурации ".

Многострочный журнал в контейнере Аналитика

При включении многострочного ведения журнала ранее разделенные журналы контейнеров объединяются и отправляются в виде отдельных записей в таблицу ContainerLogV2. Если сшитая строка журнала превышает 64 КБ, она будет усечена из-за ограничений рабочей области Log Analytics. Эта функция также поддерживает трассировки стека .NET, Go, Python и Java, которые отображаются в виде отдельных записей в таблице ContainerLogV2. Включение многострочного ведения журнала с помощью ConfigMap, как описано в разделе "Настройка сбора данных в аналитике контейнеров" с помощью ConfigMap.

Примечание.

Теперь в конфигурации есть параметр спецификации языка, в котором клиенты могут выбрать только интересующие их языки. Эту функцию можно включить, изменив языки в параметре stacktrace_languages в конфигурации.

На следующих снимках экрана показано многострочный журнал для трассировки стека исключений Go:

Отключено многострочный журнал

Снимок экрана: отключено многострочный журнал.

Ведение журнала с несколькими строками

Снимок экрана: многострочный режим.

Трассировка стека Java

Снимок экрана, на котором показана поддержка нескольких строк для Java.

Трассировка стека Python

Снимок экрана: многострочный режим для Python.

Следующие шаги