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

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

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

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

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

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

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

^{Конфигурация DCR}требует аутентификации управляемой учетной записи.

Включение схемы 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 добавляет столбец, который ContainerLogV2KubernetesMetadata улучшает устранение неполадок с простыми запросами журналов и удаляет необходимость объединения с другими таблицами. Поля в этом столбце включают: PodLabels, PodAnnotations, PodUid, Image, ImageID, , ImageRepo. ImageTag Эти поля расширяют возможности устранения неполадок с помощью запросов журналов, не присоединяясь к другим таблицам. Дополнительные сведения о включении функции метаданных Kubernetes см. ниже.

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

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

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

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

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

Включите метаданные 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 на панели мониторинга ContainerLogV2. Затем вы можете открыть приборную панель и выбрать значения для DataSource, Subscription, ResourceGroup, кластера, пространства имен и меток.

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

При включении многострочного ведения журнала ранее разделенные журналы контейнеров объединяются и отправляются в виде отдельных записей в таблицу ContainerLogV2. Включение многострочного ведения журнала с помощью ConfigMap, как описано в разделе "Настройка сбора данных в аналитике контейнеров" с помощью ConfigMap.

Ограничения

• Многострочное ведение журнала объединяет трассировки стека исключений из контейнеров с помощью Java, Python, .NET и Go. Другие записи журнала с несколькими линиями, включая пользовательские исключения и произвольные сообщения журнала, не объединяются.

• Если строка журнала превышает 16 КБ, вместо того чтобы по умолчанию усекаться средой выполнения контейнера, она будет поддерживаться до 64 КБ.

Примеры

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

Включено многострочное ведение журнала многострочной трассировки стека исключений Go

Многострочное ведение журнала трассировки стека Java включено

Включено многострочное ведение журнала для трассировки стека Python

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

• Настройте базовые журналы для ContainerLogv2.
• Узнайте, как запрашивать данные из ContainerLogV2