Общие сведения о затратах на мониторинг для Container insights

Статья
10/31/2023

В этой статье приведены рекомендации по ценам для аналитики контейнеров, которые помогут вам понять, как:

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

Совет

Стратегии снижения затрат Azure Monitor см. в статье "Оптимизация затрат" и Azure Monitor.

Модель ценообразования Azure Monitor в основном зависит от объема данных, принимаемых в гигабайтах в день в рабочую область Log Analytics. Стоимость рабочей области Log Analytics зависит не только от объема собранных данных, но также от выбранного плана и от того, как долго будут храниться данные из кластеров.

Примечание.

См. статью "Оценка затрат Azure Monitor", чтобы оценить затраты на аналитику контейнеров, прежде чем включить ее.

Следующие типы данных, собранных из кластера Kubernetes с помощью аналитики контейнеров, влияют на затраты и могут быть настроены на основе использования:

Perf, Inventory, Аналитика Metrics и KubeEvents можно управлять с помощью параметров оптимизации затрат.
Журналы контейнеров Stdout и stderr из каждого отслеживаемого контейнера в каждом пространстве имен Kubernetes в кластере с помощью агента ConfigMap
Переменные среды контейнера из каждого отслеживаемого контейнера в кластере
Завершенные задания и модули pod Kubernetes в кластере, для которых не требуется мониторинг
Активное извлечение метрик Prometheus
Коллекция журналов журналов основных узлов Kubernetes в кластере Служба Azure Kubernetes (AKS) для анализа данных журнала, созданных основными компонентами, такими как kube-apiserver иkube-controller-manager.

Управление приемом данных для сокращения затрат

Рассмотрим сценарий, в котором различные бизнес-подразделения организации совместно используют инфраструктуру Kubernetes и рабочую область Log Analytics. Каждое подразделение отделяется пространством имен Kubernetes. Вы можете визуализировать прием данных в каждой рабочей области с помощью модуля Runbook об использовании данных. Модуль Runbook доступен на вкладке "Отчеты ".

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

Общий объем оплачиваемых данных, принятых в ГБ по решению.
Оплачиваемые данные, принятые журналами контейнеров (журналы приложений).
Оплачиваемые журналы контейнеров записывают данные, принятые пространством имен Kubernetes.
Оплачиваемые журналы контейнеров регистрируют данные, принятые по имени кластера.
Оплачиваемые данные журнала контейнеров, принятые записью источника журнала.
Оплачиваемые диагностические данные, принятые журналами основных узлов диагностики.

Дополнительные сведения об управлении правами и разрешениями для книг см. в статье Управление доступом.

Определение основной причины приема данных

Данные Аналитика контейнера в основном состоят из счетчиков метрик (Perf, Inventory, Аналитика Metrics и пользовательских метрик) и журналов (ContainerLog). В зависимости от использования и размера кластера могут потребоваться различные требования и требования к мониторингу.

Перейдя к разделу "По таблице" книги "Использование данных", можно просмотреть разбивку размеров таблиц для контейнеров Аналитика.

Если большинство данных поступает из одной из следующих таблиц:

Производительность
InsightsMetrics
ContainerInventory
ContainerNodeInventory
KubeNodeInventory
KubePodInventory
KubePVInventory
KubeServices
KubeEvents

Вы можете настроить прием с помощью параметров оптимизации затрат и (или) миграции в надстройку метрик Prometheus

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

Сокращение затрат на контейнерную журналу

Завершив анализ, чтобы определить, какие источники создают данные, превышающие ваши требования, можно перенастроить сбор данных. Дополнительные сведения о настройке коллекции stdout, stderr и экологических переменных см. в разделе "Настройка параметров сбора данных агента".

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

Отключите журналы stdout во всех пространствах имен в кластере, изменив следующий код в файле ConfigMap для службы аналитики контейнеров Azure, которая извлекает метрики:
```
[log_collection_settings]       
   [log_collection_settings.stdout]          
      enabled = false
```
Отключите сбор журналов stderr из пространства имен разработки. Например, dev-test. Продолжайте собирать журналы stderr из других пространств имен, например prod , и defaultизменив следующий код в файле ConfigMap:

Примечание.

Сбор журналов в системе Kubernetes по умолчанию отключен. Параметр по умолчанию сохраняется. dev-test Добавление пространства имен в список пространств имен исключений применяется к коллекции журналов stderr.
```
[log_collection_settings.stderr]          
   enabled = true          
      exclude_namespaces = ["kube-system", "dev-test"]
```
Отключите коллекцию переменных среды в кластере, изменив следующий код в файле ConfigMap. Это изменение применяется ко всем контейнерам в каждом пространстве имен Kubernetes.
```
[log_collection_settings.env_var]
    enabled = false
```
Чтобы очистить готовые задания, укажите политику очистки в yaml определения задания. Ниже приведен пример определения задания с политикой очистки. Дополнительные сведения см. в документации по Kubernetes.
```
apiVersion: batch/v1
kind: Job
metadata:
  name: pi-with-ttl
spec:
  ttlSecondsAfterFinished: 100
```

После применения одного или нескольких этих изменений к конфигурации Карты примените его к кластеру с помощью командыkubectl apply -f <config3. map_yaml_file.yaml>. Например, выполните команду kubectl apply -f container-azm-ms-agentconfig.yaml , чтобы открыть файл в редакторе по умолчанию, чтобы изменить и сохранить его.

Настройка базовых журналов

Затраты на прием данных в ContainerLog можно сэкономить в рабочей области Log Analytics, которая в основном используется для отладки, устранения неполадок и аудита в качестве базовых журналов. Дополнительные сведения, включая ограничения базовых журналов, см. в разделе "Настройка базовых журналов" в Azure Monitor. ContainerLogV2 — это настроенная версия базовых журналов, которую использует служба "Аналитика контейнеров". Она содержит подробные записи с большим объемом текста.

Чтобы настроить базовые журналы, необходимо использовать схему ContainerLogV2. Дополнительные сведения см. в статье Включение схемы ContainerLogV2 (предварительная версия).

Извлечение метрик Prometheus

Примечание.

В этом разделе описывается коллекция метрик Prometheus в рабочей области Log Analytics. Эта информация не применяется, если вы используете Managed Prometheus для удаления метрик Prometheus.

Если вы собираете метрики Prometheus в рабочей области Log Analytics, убедитесь, что вы ограничиваете количество метрик, собираемых из кластера:

Убедитесь, что частота очистки оптимально задана. Значение по умолчанию ― 60 секунд. Вы можете увеличить частоту до 15 секунд, но необходимо убедиться, что метрики, которые вы ломаете, публикуются на этой частоте. В противном случае многие повторяющиеся метрики будут удалены и отправлены в рабочую область Log Analytics с интервалами, которые добавляются в прием данных и затраты на хранение, но имеют меньшее значение.
Аналитика контейнеров поддерживает списки исключений и включения по имени метрик. Например, если вы ломаете метрики kubedns в кластере, сотни из них могут быть удалены по умолчанию. Но вы, скорее всего, заинтересованы только в подмножестве метрик. Убедитесь, что вы указали список метрик для удаления или исключите другие, кроме нескольких, чтобы сэкономить на томе приема данных. Это легко включить очистку и не использовать многие из этих метрик, которые будут добавлять только расходы в счет Log Analytics.
При скребке заметок pod убедитесь, что фильтруется по пространству имен, чтобы исключить удаление метрик pod из пространств имен, которые не используются. Примером является dev-test пространство имен.

Данные, собранные из кластеров Kubernetes

Данные метрик

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

Тип Метрики

Метрики узлов cpuUsageNanoCores
cpuCapacityNanoCores
cpuAllocatableNanoCores
memoryRssBytes
memoryWorkingSetBytes
memoryCapacityBytes
memoryAllocatableBytes
restartTimeEpoch
used (диск)
free (диск)
used_percent (диск)
io_time (diskio)
writes (diskio)
reads (diskio)
write_bytes (diskio)
write_time (diskio)
iops_in_progress (diskio)
read_bytes (diskio)
read_time (diskio)
err_in (net)
err_out (net)
bytes_recv (net)
bytes_sent (net)
Kubelet_docker_operations (kubelet)

Метрики контейнеров cpuUsageNanoCores
cpuRequestNanoCores
cpuLimitNanoCores
memoryRssBytes
memoryWorkingSetBytes
memoryRequestBytes
memoryLimitBytes
restartTimeEpoch

Тип	Метрики
Метрики узлов	`cpuUsageNanoCores` `cpuCapacityNanoCores` `cpuAllocatableNanoCores` `memoryRssBytes` `memoryWorkingSetBytes` `memoryCapacityBytes` `memoryAllocatableBytes` `restartTimeEpoch` `used` (диск) `free` (диск) `used_percent` (диск) `io_time` (diskio) `writes` (diskio) `reads` (diskio) `write_bytes` (diskio) `write_time` (diskio) `iops_in_progress` (diskio) `read_bytes` (diskio) `read_time` (diskio) `err_in` (net) `err_out` (net) `bytes_recv` (net) `bytes_sent` (net) `Kubelet_docker_operations` (kubelet)
Метрики контейнеров	`cpuUsageNanoCores` `cpuRequestNanoCores` `cpuLimitNanoCores` `memoryRssBytes` `memoryWorkingSetBytes` `memoryRequestBytes` `memoryLimitBytes` `restartTimeEpoch`

Инвентаризация кластера

Ниже приведен список данных инвентаризации кластера, собираемых по умолчанию.

KubePodInventory — 1 за минуту на pod
KubeNodeInventory – 1 раз в минуту в каждом узле
KubeServices – 1 1 раз в минуту в каждой службе
ContainerInventory – 1 раз в минуту в каждом контейнере

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

Чтобы понять, какие затраты, скорее всего, основаны на последних шаблонах использования из данных, собранных с помощью аналитики контейнеров, см. в статье "Анализ использования в рабочей области Log Analytics".