Настройка коллекции журналов контейнеров с помощью ConfigMap

Кластеры Kubernetes создают большой объем данных, собранных Azure Monitor. Так как плата взимается за прием и хранение этих данных, вы можете значительно сократить затраты на мониторинг, отфильтровав данные, которые вам не нужны. В этой статье описывается, как использовать ConfigMap для настройки и фильтрации коллекции журналов контейнеров и переменных среды из кластера. Вы также можете использовать ConfigMap для включения сбора журналов платформы из системных пространств имен Kubernetes и включения фильтрации на основе заметок для рабочих нагрузок.

Предпосылки

• Минимальная версия агента, поддерживаемая для сбора stdout, stderr и переменных среды из рабочих нагрузок контейнеров, — ciprod06142019 или более поздней версии.

Настройка и развертывание ConfigMap

Используйте следующую процедуру, чтобы настроить и развернуть файл конфигурации ConfigMap в кластере:

1. Скачайте шаблон https://aka.ms/container-azm-ms-agentconfig конфигурации агента ConfigMap и откройте его в редакторе.

2. Измените файл YAML ConfigMap в соответствии с вашими настройками. Шаблон содержит все допустимые параметры с описанием. Чтобы включить параметр, удалите символ комментария (#) и задайте его значение.

3. Создайте ConfigMap, выполнив следующую команду kubectl:

   kubectl config set-context <cluster-name>
   kubectl apply -f <configmap_yaml_file.yaml>
   
   # Example: 
   kubectl config set-context my-cluster
   kubectl apply -f container-azm-ms-agentconfig.yaml
   

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

   configmap "container-azm-ms-agentconfig" created`.
   

Проверка конфигурации

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

kubectl logs ama-logs-fdf58 -n kube-system -c ama-logs

Если в pod-ах Azure Monitor агента возникают ошибки конфигурации, результаты будут отображать ошибки, аналогичные следующим:

***************Start Config Processing******************** 
config::unsupported/missing config schema version - 'v21' , using defaults

Используйте следующие параметры для проведения более детальной диагностики внесенных изменений конфигурации.

• Используйте ту же kubectl logs команду из pod агента.

• Просмотрите динамические журналы для ошибок, аналогичных следующим:

  config::error::Exception while parsing config map for log collection/env variable settings: \nparse error on value \"$\" ($end), using defaults, please check config map for errors
  

Данные отправляются в таблицу KubeMonAgentEvents в вашей рабочей области Log Analytics каждый час с указанием степени серьезности конфигурационных ошибок. Если ошибки отсутствуют, запись в таблице будет содержать данные с информацией о серьезности, которая не сообщает об ошибках. Столбец Tags содержит дополнительные сведения об идентификаторе модуля pod и контейнера, на котором произошла ошибка, а также первое вхождение, последнее вхождение и подсчет за последний час.

Проверка версии схемы

Поддерживаемые версии схем конфигурации доступны в виде аннотации pod (версии схемы) в модуле агента Azure Monitor. Вы можете увидеть их с помощью следующей команды kubectl.

kubectl describe pod ama-logs-fdf58 -n=kube-system.

Фильтрация журналов контейнеров

Журналы контейнеров — это журналы stderr и stdout, созданные контейнерами в кластере Kubernetes. Эти журналы хранятся в таблице ContainerLogV2 в рабочей области Log Analytics. По умолчанию собираются все журналы контейнеров, но вы можете отфильтровать журналы из определенных пространств имен или полностью отключить сбор журналов контейнеров.

Измените раздел log_collection_settings в ConfigMap, чтобы настроить сбор stderr и stdout журналов отдельно для кластера. В следующем примере показаны параметры ConfigMap для сбора stdout и stderr, за исключением пространств имен kube-system и gatekeeper-system.

[log_collection_settings]
    [log_collection_settings.stdout]
        enabled = true
        exclude_namespaces = ["kube-system","gatekeeper-system"]

    [log_collection_settings.stderr]
        enabled = true
        exclude_namespaces = ["kube-system","gatekeeper-system"]

    [log_collection_settings.enrich_container_logs]
        enabled = true

Фильтрация журналов платформы (пространства имен System Kubernetes)

По умолчанию журналы контейнеров из системного пространства имен исключаются из коллекции, чтобы свести к минимуму затраты Log Analytics. Журналы контейнеров системы могут быть критически важными, хотя в определенных сценариях устранения неполадок. Эта функция ограничена следующими системными пространствами имен:

• kube-system
• gatekeeper-system
• calico-system
• azure-arc
• kube-public
• kube-node-lease.

Измените collect_system_pod_logs параметр в log_collection_settings разделе ConfigMap, чтобы включить журналы платформ для кластера. Кроме того, необходимо убедиться, что пространство имен системы не находится в параметре exclude_namespaces .

В следующем примере показаны параметры ConfigMap для сбора журналов контейнера stdout и stderr в пространстве имен coredns.

[log_collection_settings]
    [log_collection_settings.stdout]
        enabled = true
        exclude_namespaces = ["gatekeeper-system"]
        collect_system_pod_logs = ["kube-system:coredns"]

    [log_collection_settings.stderr]
        enabled = true
        exclude_namespaces = ["kube-system","gatekeeper-system"]
        collect_system_pod_logs = ["kube-system:coredns"]

Фильтрация рабочих нагрузок на основе аннотаций

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

Измените filter_using_annotations параметр в log_collection_settings разделе ConfigMap, чтобы включить фильтрацию на основе заметок.

[log_collection_settings.filter_using_annotations]
   enabled = true

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

Ниже приведен пример заметки в спецификации 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 

Фильтрация переменных среды

Измените параметр log_collection_settings.env_var в разделе log_collection_settings ConfigMap, чтобы включить сбор переменных окружения на всех узлах и подах.

[log_collection_settings.env_var]
    enabled = true

Если коллекция переменных среды включена глобально, ее можно отключить для определенного контейнера, установив переменную AZMON_COLLECT_ENVFalse среды в параметре Dockerfile или в файле конфигурации pod в разделе env: . Если коллекция переменных среды глобально отключена, невозможно включить коллекцию для определенного контейнера. Единственное переопределение, которое можно применить на уровне контейнера, — это отключение сбора данных, когда он уже включен глобально.

Параметры ConfigMap

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

Влияние на визуализации и оповещения

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

Чтобы проверить наличие оповещений, ссылающихся на эти таблицы, выполните следующий запрос 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 "Perf" or properties  contains "InsightsMetrics" or properties  contains "ContainerInventory" or properties  contains "ContainerNodeInventory" or properties  contains "KubeNodeInventory" or properties  contains"KubePodInventory" or properties  contains "KubePVInventory" or properties  contains "KubeServices" or properties  contains "KubeEvents" 
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc

Дальнейшие шаги

• См. Преобразования данных в Container Insights, чтобы добавить преобразования в DCR, которые будут дополнительно фильтровать данные на основе подробных критериев.