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

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

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

ContainerLogV2 — это схема по умолчанию для CLI версии 2.54.0 и больше. Это таблица по умолчанию для клиентов, которые подключены к аналитике контейнеров с проверкой подлинности управляемого удостоверения. ContainerLogV2 можно явно включить с помощью CLI версии 2.51.0 или более поздней с помощью параметров сбора данных.

Внимание

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

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

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

1 Если LogMessage является допустимым JSON и имеет ключ с именем level, его значение будет использоваться. В противном случае сопоставление ключевых слов на основе регулярных выражений используется для вывода LogLevel из LogMessage. Это вывод может привести к некоторым неправильным классификациям. LogLevel— строковое поле со значением работоспособности, например CRITICAL, ERROR, WARNING, INFO, TRACEDEBUGили UNKNOWN.

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

Для конфигурации DCR 3 требуется проверка подлинности управляемого удостоверения.

Примечание.

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

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

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

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

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

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

Функции

  • Расширенная схема ContainerLogV2 при включении метаданных журналов Kubernetes добавляет столбец, который ContainerLogV2 KubernetesMetadata улучшает устранение неполадок с простыми запросами журналов и удаляет необходимость объединения с другими таблицами. Поля в этом столбце включают: PodLabels, PodAnnotations, PodUid, Image, ImageID, , ImageRepo. ImageTag Эти поля расширяют возможности устранения неполадок с помощью запросов журналов, не присоединяясь к другим таблицам. Дополнительные сведения о включении функции метаданных Kubernetes см. ниже.

  • Уровень журнала Эта функция добавляет LogLevel столбец в ContainerLogV2 с возможными значениями, критическими, ошибками, предупреждением, сведениями, отладкой, трассировкой или неизвестными. Это помогает оценить работоспособность приложений на основе уровня серьезности. Добавление панели мониторинга Grafana позволяет визуализировать тенденции на уровне журнала с течением времени и быстро определять затронутые ресурсы.

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

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

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

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

Внимание

Для сбора метаданных Kubernetes требуется проверка подлинности управляемого удостоверения и ContainerLogsV2

Включите метаданные Kubernetes с помощью ConfigMap со следующими параметрами. Все поля метаданных собираются по умолчанию при metadata_collection включении. Раскомментируйте include_fields данные, чтобы указать отдельные поля для сбора.

[log_collection_settings.metadata_collection]
    enabled = true
    include_fields = ["podLabels","podAnnotations","podUid","image","imageID","imageRepo","imageTag"]

Через несколько минут KubernetesMetadata столбец должен быть включен в любые запросы журнала для ContainerLogV2 таблицы, как показано ниже.

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

Установка панели мониторинга Grafana

Внимание

Если вы включили Grafana, используя рекомендации по включению мониторинга для кластеров Kubernetes, экземпляр Grafana уже должен иметь доступ к рабочей области Azure Monitor для метрик Prometheus. Панель мониторинга метаданных журналов Kubernetes также требует доступа к рабочей области Log Analytics, содержащей данные журнала. Сведения о предоставлении экземпляра Grafana роли средства чтения мониторинга для рабочей области Log Analytics см. в статье "Изменение разрешений на доступ к Azure Monitor" в Azure Monitor .

Импортируйте панель мониторинга из коллекции Grafana на панели мониторинга ContainerLogV2. Затем можно открыть панель мониторинга и выбрать значения для DataSource, подписки, ResourceGroup, кластера, пространства имен и меток.

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

Примечание.

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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