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

Преобразования в Azure Monitor фильтруют или изменяют входящие данные перед их отправкой в рабочую область Log Analytics. Преобразования выполняются после того, как источник данных доставляет данные и перед его отправкой в место назначения. Они определены в правиле сбора данных (DCR).

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

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

Поддерживаемые таблицы

Следующие таблицы в рабочей области Log Analytics поддерживают преобразования.

• Любая таблица Azure из числа перечисленных в таблицах, поддерживающих преобразования в журналах Azure Monitor. Справочник по данным Azure Monitor также включает, поддерживает ли таблица преобразования и перечисляет другие атрибуты для каждой таблицы.
• Любая пользовательская таблица, созданная для агента Azure Monitor.
• Настраиваемые таблицы с Auxiliary plan.

Создайте преобразование

Некоторые сценарии сбора данных поддерживают добавление преобразования через портал Azure, но для большинства сценариев требуется создать новый DCR с помощью определения JSON или добавить преобразование в существующий DCR. См. статью "Создание преобразования в Azure Monitor" для различных вариантов и рекомендаций и примеров преобразований в Azure Monitor для примеров запросов преобразования распространенных сценариев.

Многоэтапные преобразования (предварительная версия)

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

При многоэтапных преобразованиях DCR определяет конвейер обработки данных, а не один шаг преобразования. Данные проходят через следующие этапы:

1. Сбор данных. агент Azure Monitor (AMA) собирает данные из ресурса на основе параметров источника данных в DCR.
2. Обработка на стороне клиента. Преобразования выполняются локально на агенте до отправки данных по сети. Преобразование применяется к данным в необработанной форме, которая может отличаться от стандартного представления таблицы.
3. Обработка при приеме данных. После того как данные поступают в Azure Monitor, при приеме к ним применяются преобразования, прежде чем данные записываются в целевую таблицу в Log Analytics. Это преобразование применяется после того, как данные были полностью приведены к схеме и обогащены.
4. Доставка данных. Обработанные журналы доставляются в конечное место назначения.

Processors

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

• Компонуемая. В одном преобразовании можно объединить несколько процессоров.
• Заказано. Процессоры выполняются последовательно в порядке, заданном в преобразовании.
• Независимо от этапа. Один и тот же тип процессора можно использовать в разных источниках данных, этапах или сценариях с некоторыми ограничениями во время предварительной версии.

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

Доступны следующие семейства процессоров:

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

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

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

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

Аспекты многоэтапной DCR

• Для многоэтапных преобразований требуется версия 2025-05-11 API или более поздняя. Раздел transformations и свойство transform в источниках данных и потоках данных не распознаются в более ранних версиях API.
• Свойство transform является взаимоисключающим для transformKql каждого потока данных. DCR может смешивать старые и новые потоки данных между разными стримами.
• В режиме предварительного просмотра необходимо вручную согласовывать заголовок последующего преобразования с результатом предыдущего преобразования. Например, если применить агрегирование к необработанному потоку событий Windows, результат может быть несовместим с соответствующей таблицей событий, а преобразование времени приема должно начинаться с пользовательского заголовка потока.

Подход к проектированию для многоэтапной обработки

Выполните следующие действия при проектировании многоэтапного DCR:

1. Оцените источники и назначения данных. Определите типы источников данных и решите, в какую таблицу попадает каждый тип: в стандартную таблицу по умолчанию или в пользовательскую таблицу.
2. Определение потребностей агрегирования. Агрегированные журналы должны перейти в отдельную таблицу, так как их форма отличается от необработанной формы.
3. Планирование разностной обработки. Если необходимо обрабатывать части одного и того же журнала по-разному, создайте несколько источников данных одного типа с разными параметрами коллекции и примените к каждому из них различные преобразования на стороне клиента.
4. Создавайте преобразования на стороне клиента. Используйте стандартные потоки (Microsoft-*), если выходные данные сохраняют схему заголовка или пользовательские потоки (Custom-*) в противном случае. Определите пользовательские потоки в streamDeclarations.
5. Определение потоков данных. Для каждого потока создайте поток данных. Используйте потоки данных во время приема, чтобы разделить один поток между несколькими целевыми таблицами, применяя разные критерии фильтрации для каждого потока данных.

DCR трансформация рабочей области

Преобразования определяются в правиле сбора данных (DCR), но в Azure Monitor по-прежнему существуют коллекции данных, которые еще не используют DCR. Примеры включают журналы ресурсов, собранные с помощью параметров диагностики, и данные приложения, собранные с помощью Application Insights.

Правило сбора данных преобразования рабочей области (DCR) — это специальный DCR, который применяется непосредственно к рабочей области Log Analytics. Цель этого DCR заключается в том, чтобы выполнять преобразования данных, которые еще не используют DCR для сбора данных, и поэтому не имеет средств для определения преобразования.

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

Например, таблица событий используется для хранения событий из виртуальных машин Windows. Если вы создаете преобразование рабочей области в DCR для таблицы событий, оно будет применено к событиям, собранным виртуальными машинами, использующими агент Log Analytics¹, поскольку агент не использует DCR. Преобразование будет игнорироваться, хотя любые данные, отправляемые агентом Azure Monitor (AMA), так как он использует DCR для определения сбора данных. Вы по-прежнему можете использовать преобразование с агентом Azure Monitor, но вы бы включили это преобразование в DCR, связанный с агентом, а не в DCR преобразования рабочей области.

¹ Агент Log Analytics устарел, но некоторые среды по-прежнему могут использовать его. Это только один пример источника данных, который не использует DCR.

Преобразования конвейера Azure Monitor

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

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

В следующей таблице приведены основные различия между преобразованиями конвейера Azure Monitor и преобразованиями Azure Monitor во время приема данных:

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

Затраты на преобразования

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

Вспомогательные журналы

Для вспомогательных журналов предусмотрена оплата за обработку данных и приём данных в рабочую область Log Analytics. Плата за обработку данных взимается за все входящие данные, которые получает Azure Monitor, если местом назначения в рабочей области Log Analytics является таблица Auxiliary Logs. Это включает объем данных, обработанных преобразованиями Azure Monitor во время приема данных. Плата за приём данных применяется только к данным после преобразования во время приёма, доставляемым в таблицу Auxiliary Logs. Преобразования могут увеличивать или уменьшать размер данных.

В следующей таблице приведены некоторые примеры.

См. цены на Azure Monitor для обработки журналов и приема данных журнала.

Аналитика или базовые журналы

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

• Если преобразование увеличивает размер входящих данных, например путем добавления вычисляемого столбца, взимается стандартная скорость приема для дополнительных данных.
• Если преобразование уменьшает объем полученных данных более чем на 50%, плата взимается за объем данных, отфильтрованных выше 50%.

Чтобы вычислить плату за обработку данных, полученную из преобразований, используйте следующую формулу:

[ДАННЫЕ ГБ, удаленные преобразованием] — ([размер входящих данных в ГБ] / 2).

В следующей таблице показаны примеры.

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

См. Цены на Azure Monitor для получения информации о ценах на обработку журналов и загрузку данных журнала.

Связанный контент

• Дополнительные сведения о правилах сбора данных (DCR).
• Создайте преобразование в Azure Monitor, включая многоэтапные преобразования.
• Структура правила сбора данных (DCR) для полной схемы JSON, включая многоэтапный transformations раздел.
• Создайте преобразование рабочей области DCR для данных, не собранных с помощью DCR.
• Анонс многоэтапных преобразований в блоге Azure Observability, чтобы узнать подробности об общедоступной предварительной версии.