Коллекция журналов с высоким масштабированием в Службе "Аналитика контейнеров"

Масштабный режим — это функция в Container Insights, которая позволяет собирать журналы консоли контейнеров (stdout и stderr) с высокой пропускной способностью с узлов кластера Azure Kubernetes Service (AKS). Эта функция позволяет собирать до 50 000 логов в секунду на узел.

Overview

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

Режим высокой шкалы влияет только на уровень сбора данных. Остальная часть интерфейса Container Insights остается той же, при этом журналы заносятся в ту же ContainerLogV2 таблицу. Существующие запросы и оповещения продолжают работать, так как собираются те же данные.

Чтобы обеспечить максимальную поддерживаемую пропускную способность журнала, следует использовать высокоуровневые номера SKU виртуальных машин с 16 ядрами ЦП или более для узлов кластера AKS. Использование SKU виртуальных машин низкого класса снижает пропускную способность логов.

Соответствует ли мой кластер?

Коллекция журналов высокого масштаба подходит для сред, отправляя более 2000 журналов в секунду (или 2 МБ/с) на узел в кластерах Kubernetes и был разработан и протестирован для отправки до 50 000 журналов/с на узел. Используйте следующие запросы журналов, чтобы определить, подходит ли кластер для сбора журналов высокого масштаба.

Логи в секунду и на один узел

ContainerLogV2 
| where _ResourceId =~ "<cluster-resource-id>" 
| summarize count() by bin(TimeGenerated, 1s), Computer 
| render timechart 

Размер журнала (в МБ) в секунду на узел

 ContainerLogV2 
| where _ResourceId =~ "<cluster-resource-id>"
| summarize BillableDataMB = sum(_BilledSize)/1024/1024 by bin(TimeGenerated, 1s), Computer 
| render timechart 

Prerequisites

• Azure CLI версии 2.74.0 или более поздней.
• Azure CLI k8s-extension версии 1.6.7 или более поздней, если вы управляете Kubernetes с поддержкой Azure Arc.
• Схема кластера должна быть настроена для ContainerLogV2.
• Если ограничения ресурсов по умолчанию (ЦП и память) в контейнере ama-logs set не соответствуют требованиям к масштабируемости журналов, обратитесь в канал поддержки Майкрософт, чтобы увеличить ограничения ресурсов контейнера ama-logs.

Требования к брандмауэры сети

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

Конечная точка — это конечная точка приема журналов из конечной точки сбора данных (DCE) для правила сбора данных (DCR), используемого кластером. Этот DCE создается при включении режима высокой шкалы для кластера и начинается с префикса MSCI-ingest.

Limitations

Не поддерживаются следующие сценарии:

• HTTP-прокси с доверенным сертификатом
• Подключение через портал Azure
• Настройка с помощью параметров монитора на портале AKS Insights
• Автоматическая миграция из уже существующей контейнерной аналитики
• Подключение с использованием Bicep, Terraform, Azure Policy для Kubernetes с поддержкой Azure Arc

Включение сбора журналов с высоким масштабированием

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

Обновление ConfigMap

Первым шагом является обновление ConfigMap для кластера, чтобы указать модулям daemonset pods ama-logs выполняться в режиме высокой масштабируемости.

1. Выполните инструкции по настройке и развертыванию ConfigMap, чтобы скачать и обновить ConfigMap для кластера.

2. Включите режим высокой шкалы с помощью следующего параметра в разделе agent-settings.

   [agent_settings.high_log_scale] 
     enabled = true 
   

3. Включите коллекцию внутренних метрик для заполнения панели мониторинга QoS Grafana, описанной ниже, следующим параметром в разделе agent-settings.

   [agent_settings.fbit_config]
     enable_internal_metrics = "true"
   

4. Примените ConfigMap к кластеру с помощью следующих команд.

   kubectl config set-context <cluster-name>
   kubectl apply -f <configmap_yaml_file.yaml>
   

После применения этого ConfigMap, ama-logs-* поды будут автоматически перезапущены и настроены для запуска ama-logs daemonset подов в режиме высокой нагрузки.

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

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

Существующий кластер AKS

az aks enable-addons -a monitoring -g <resource-group-name> -n <cluster-name> --enable-high-log-scale-mode

Существующий частный кластер AKS

az aks enable-addons -a monitoring -g <resource-group-name> -n <cluster-name> --enable-high-scale-mode --ampls-resource-id /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/microsoft.insights/privatelinkscopes/<resourceName> 

Новый кластер AKS

az aks create -g <resource-group-name> -n <cluster-name> enable-addons -a monitoring --enable-high-log-scale-mode

Новый частный кластер AKS

Дополнительные сведения о создании частного кластера Службы Azure Kubernetes (AKS) можно найти в статье «Создание частного кластера AKS». Используйте дополнительные параметры --enable-high-scale-mode и --ampls-resource-id, чтобы настроить режим масштаб больших журналов с помощью идентификатора ресурса области присутствия Private Link Azure Monitor.

Кластер с поддержкой ARC

az k8s-extension create --name azuremonitor-containers --resource-group <resource-group-name>  --cluster-name <cluster-name>  --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.enableHighLogScaleMode=true logAnalyticsWorkspaceResourceID=<workspace-resource-id> 

Migration

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

• Так как режим высокой шкалы использует другой конвейер данных, необходимо убедиться, что конечные точки конвейера не блокируются брандмауэром или другими сетевыми подключениями.
• Для приема данных в режиме высокого масштаба требуется конечная точка сбора данных (DCE) в дополнение к стандартному DCR для сбора данных. Если вы создали какие-либо DCR-ы, использующие Microsoft-ContainerLogV2, необходимо заменить их на Microsoft-ContainerLogV2-HighScale, иначе данные будут дублироваться. Кроме того, необходимо создать DCE для приема и связать его с DCR, если DCR еще не использует ни одного. Дополнительные сведения о подключении Container Insights с помощью Azure Resource Manager см. в справочнике по зависимостям.

Мониторинг метрик качества обслуживания с помощью Prometheus и Grafana

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