Руководство. Замена настраиваемых полей в рабочей области Log Analytics настраиваемыми столбцами на основе KQL

Настраиваемые поля — это функция Azure Monitor, которая позволяет извлекать данные отдельного столбца из другого текстового столбца одной таблицы. Создание новых настраиваемых полей будет отключено с 31 марта 2023 г. Функции настраиваемых полей будут устаревшими, а существующие настраиваемые поля перестают функционировать 31 марта 2026 года.

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

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

При внедрении правил сбора данных (DCR) преобразования на основе KQL являются стандартным методом настройки таблицы, заменив устаревшие настраиваемые поля.

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

Необходимые компоненты

• Рабочая область Log Analytics с таблицей, содержащей настраиваемые поля
• Достаточно привилегий учетной записи для создания и изменения правил сбора данных (DCR)

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

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

1. Перейдите в рабочую область Log Analytics, в которой находится таблица с настраиваемыми полями.

2. В боковом меню выберите "Таблицы". Выберите " Управление таблицей " в контекстном меню таблицы.

   

3. Обратите внимание, что любые правила сбора данных (DCR) связаны с данной таблицей.

   • Если какие-либо контроллеры домена присутствуют в соответствующем разделе, это означает, что все уже существующие настраиваемые поля были реализованы в этих контроллерах домена или были отменены при создании DCR. Вы изучите содержимое настраиваемых полей на следующем шаге этого руководства и определите, требуются ли дополнительные обновления для контроллеров домена.
   • Если нет правил сбора данных, связанных с таблицей, все столбцы в данной таблице с именами, заканчивающимися "_CF", будут настраиваемыми полями, подлежащими замене.

   

4. Закройте диалоговое окно свойств таблицы и выберите "Изменить схему " в контекстном меню таблицы. Прокрутите страницу внизу страницы, в которой перечислены настраиваемые столбцы. Эти столбцы заканчиваются _CF.

   

5. Обратите внимание на имена этих столбцов, так как вы определите их содержимое на следующем шаге.

Общие сведения о содержимом настраиваемого поля

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

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

   

2. Найдите столбцы, отмеченные на предыдущем шаге, и проверьте их содержимое.

   • Если столбец не пуст и есть контроллеры домена, связанные с таблицей, то логика настраиваемого поля уже реализована с преобразованием. Никаких действий не требуется
   • Если столбец пуст (или отсутствует в результатах запроса) и есть контроллеры домена, связанные с таблицей, логика настраиваемого поля не была реализована с помощью DCR. Добавьте преобразование в поток данных в существующем DCR.
   • Если столбец не пуст и с таблицей нет контроллеров домена , логика настраиваемого поля должна реализоваться как преобразование в DCR рабочей области.

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

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

Теперь вы готовы создать необходимый фрагмент KQL и добавить его в DCR. Эта логика применяется к каждой записи по мере приема в рабочую область.

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

   • Используйте оператор синтаксического анализа для поиска подстроки на основе шаблонов в строке.
   • Используйте функцию extract() для поиска подстроки на основе регулярных выражений.
   • Строковые функции как split(), substring()и многие другие также могут быть полезны.

   

2. Определите, где должно размещаться новое определение KQL настраиваемого столбца.

   • Для журналов, собранных с помощью агента Azure Monitor (AMA), измените DCR сбор данных для таблицы, добавив преобразование. Пример см. в рекомендациях и примерах для преобразований в Azure Monitor. Запрос преобразования определяется в элементе transformKql .
   • Для журналов ресурсов, собранных с параметрами диагностики, добавьте преобразование в DCR рабочей области по умолчанию. Таблица должна поддерживать преобразования.

Вопросы и ответы

Разделы справки перенести настраиваемые поля для текстового журнала, собранного с помощью устаревшего агента Log Analytics (MMA)?

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

Обязательно ли перенос настраиваемых полей в KQL?

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

Потеряет ли я существующие данные в соответствующих столбцах, если не переносите пользовательские поля вовремя?

Нет, пользовательские поля вычисляются во время приема данных. Удаление определения поля или их перенос вовремя не повлияет на данные, которые ранее были приема.

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

• Дополнительные сведения о преобразованиях в Azure Monitor.