Схема журнала аналитики контейнеров
Аналитика контейнеров хранит данные журнала, собираемые в таблице с именем 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 - LogLevel 1- KubernetesMetadata 2 |
Переход | Настраивается только с помощью ConfigMap. | Настраиваемая с помощью ConfigMap и DCR. 3 |
Цены | Совместим только с журналами аналитики с полной ценой. | Поддерживает уровень базовых журналов с низкими затратами в дополнение к журналам аналитики. |
Выполнение запроса | Требуется несколько операций соединения с таблицами инвентаризации для стандартных запросов. | Включает дополнительные метаданные pod и контейнера для уменьшения сложности запросов и операций соединения. |
Многострочный | Не поддерживается многострочное разделение записей на несколько строк. | Поддержка многострочного ведения журнала, разрешая консолидированные однозаготовые записи для многострочных выходных данных. |
1 Если LogMessage
является допустимым JSON и имеет ключ с именем level
, его значение будет использоваться. В противном случае сопоставление ключевых слов на основе регулярных выражений используется для вывода LogLevel
из LogMessage
. Это вывод может привести к некоторым неправильным классификациям. LogLevel
— строковое поле со значением работоспособности, например CRITICAL
, ERROR
, WARNING
, INFO
, TRACE
DEBUG
или UNKNOWN
.
2 KubernetesMetadata
— это необязательный столбец, который включен с метаданными Kubernetes. Значение этого поля — JSON с полями podLabels
, podAnnotations
, podUid
, , Image
и ImageTag
Image 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
таблицы, как показано ниже.
Установка панели мониторинга Grafana
Внимание
Если вы включили Grafana, используя рекомендации по включению мониторинга для кластеров Kubernetes, экземпляр Grafana уже должен иметь доступ к рабочей области Azure Monitor для метрик Prometheus. Панель мониторинга метаданных журналов Kubernetes также требует доступа к рабочей области Log Analytics, содержащей данные журнала. Сведения о предоставлении экземпляра Grafana роли средства чтения мониторинга для рабочей области Log Analytics см. в статье "Изменение разрешений на доступ к Azure Monitor" в Azure Monitor .
Импортируйте панель мониторинга из коллекции Grafana на панели мониторинга ContainerLogV2. Затем можно открыть панель мониторинга и выбрать значения для DataSource, подписки, ResourceGroup, кластера, пространства имен и меток.
Примечание.
При первоначальной загрузке панели мониторинга Grafana могут появиться ошибки из-за того, что переменные еще не выбраны. Чтобы предотвратить повторение, сохраните панель мониторинга после выбора набора переменных, чтобы он стал по умолчанию на первом открытии.
Ведение журнала с несколькими строками
При включении многострочного ведения журнала ранее разделенные журналы контейнеров объединяются и отправляются в виде отдельных записей в таблицу ContainerLogV2. Если сшитая строка журнала превышает 64 КБ, она будет усечена из-за ограничений рабочей области Log Analytics. Эта функция также поддерживает трассировки стека .NET, Go, Python и Java, которые отображаются в виде отдельных записей в таблице ContainerLogV2. Включение многострочного ведения журнала с помощью ConfigMap, как описано в разделе "Настройка сбора данных в аналитике контейнеров" с помощью ConfigMap.
Примечание.
Теперь в конфигурации есть параметр спецификации языка, в котором клиенты могут выбрать только интересующие их языки. Эту функцию можно включить, изменив языки в параметре stacktrace_languages в конфигурации.
На следующих снимках экрана показано многострочный журнал для трассировки стека исключений Go:
Отключено многострочный журнал
Ведение журнала с несколькими строками
Трассировка стека Java
Трассировка стека Python
Следующие шаги
- Настройте базовые журналы для ContainerLogv2.
- Узнайте, как запрашивать данные из ContainerLogV2