Оптимизация затрат на мониторинг для аналитики контейнеров

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

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

Анализ приема данных

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

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

Снимок экрана: раскрывающийся список

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

Снимок экрана: пример книги об использовании данных.

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

Например, на следующем снимка экрана показана модификация запроса журнала, используемого для таблицы by table , в котором отображаются данные по пространству имен и таблице.

Снимок экрана: запрос журнала, отображающий использование пространства имен и таблицы.

Фильтрация собранных данных

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

Предустановки затрат

Самый простой способ фильтрации данных — использовать предустановки затрат в портал Azure. Каждая предустановка включает различные наборы таблиц для сбора на основе различных профилей операций и затрат. Предустановки затрат предназначены для быстрого настройки сбора данных на основе распространенных сценариев.

Снимок экрана: параметры собранных данных.

Совет

Если вы настроили кластер для использования интерфейса Prometheus для аналитики контейнеров, вы можете отключить сбор производительности, так как данные о производительности собираются Prometheus.

Дополнительные сведения о выборе предустановки затрат см. в разделе "Настройка DCR" с помощью портал Azure

Параметры фильтрации

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

Фильтровать по Description
Таблицы Вручную измените DCR, если вы хотите выбрать отдельные таблицы, чтобы заполнить другие группы предустановок затрат. Например, вы можете собирать ContainerLogV2, но не собирать KubeEvents, которые включены в ту же предустановку затрат.

Ознакомьтесь со значениями Stream в DCR для списка потоков, используемых в DCR , и используйте инструкции в этой статье.
Журналы контейнеров ContainerLogV2 хранит записи stdout/stderr, созданные контейнерами в кластере. Хотя вы можете отключить коллекцию всей таблицы с помощью DCR, можно настроить коллекцию журналов stderr и stdout отдельно с помощью ConfigMap для кластера. Так как stdout и stderr параметры можно настроить отдельно, можно включить одно и не другое.

Дополнительные сведения о фильтрации журналов контейнеров см . в журналах контейнеров фильтра.
Пространство имен Пространства имен в Kubernetes используются для группировки ресурсов в кластере. Вы можете отфильтровать данные из ресурсов в определенных пространствах имен, которые не требуются. С помощью DCR можно фильтровать только данные о производительности по пространству имен, если вы включили коллекцию Perf для таблицы. Используйте ConfigMap для фильтрации данных для определенных пространств имен и stdout stderr журналов.

Дополнительные сведения о пространстве имен и фильтрации журналов платформы (пространства имен System Kubernetes) см. в журналах фильтрации контейнеров фильтра по пространству имен системы.
Модули pod и контейнеры Фильтрация заметок позволяет отфильтровать журналы контейнеров на основе заметок, которые вы делаете в модуле pod. С помощью ConfigMap можно указать, следует ли собирать журналы stdout и stderr для отдельных модулей pod и контейнеров.

Сведения об обновлении ConfigMap и настройке заметок в модулях pod см . в фильтрации на основе заметок на основе заметок для рабочих нагрузок .

Преобразования

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

Например, можно отфильтровать журналы контейнеров на основе уровня журнала в ContainerLogV2. Вы можете добавить преобразование в DCR службы аналитики контейнеров, которая будет выполнять функциональные возможности на следующей схеме. В этом примере собираются только error события уровня, critical а другие события игнорируются.

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

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

Настройка ценовых категорий

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

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

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

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