Настройка схемы ContainerLogV2

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

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

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

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

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

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

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

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

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

Прежде чем включить схему ContainerLogV2 , оцените наличие правил генерации оповещений, использующих таблицу 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 расширяет схему ContainerLogV2 с дополнительными метаданными Kubernetes. Функция фильтрации журналов предоставляет возможности фильтрации как для рабочих нагрузок, так и для контейнеров платформы. Эти функции улучшают видимость рабочих нагрузок.

Функции

• Расширенная схема ContainerLogV2 При включении метаданных ContainerLogV2 Kubernetes таблица содержит новый столбец с именем KubernetesMetadata. Этот столбец упрощает устранение неполадок с помощью простых запросов журналов и удаляет необходимость соединения с другими таблицами. Поля в этом столбце включают podLabels, podAnnotations, podUid, , image, imageID, imageRepoи imageTag. Чтобы включить эту функцию, см. раздел "Включить метаданные Kubernetes".

• Уровень журнала Эта функция добавляет LogLevel столбец ContainerLogV2 к возможным значениям CRITICAL, ERROR, , WARNING, INFO, DEBUGили TRACEUNKNOWN. Этот столбец помогает оценить работоспособность приложений на основе уровня серьезности. Панель мониторинга 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, Cluster, Namespace и Labels.

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

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

Ограничения

• Многострочное логирование объединяет трассировки стека исключений из контейнеров, используя Java, Python, .NET и Go. Другие записи журнала с несколькими линиями, включая пользовательские исключения и произвольные сообщения журнала, не объединяются.
• Многострочный журнал не поддерживается для трассировок стека исключений Python с fine-grained-error-locations-in-tracebacks. Для работы многострочной записи журнала необходимо отключить эту функцию, как описано в документации Python.
• По умолчанию среда выполнения контейнера усечена строк журнала в 16 КБ. При включении многостроного ведения журнала поддерживает строки журналов ContainerLogV2 до 64 КБ.

Примеры

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

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

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

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

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

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