Руководство. Замена настраиваемых полей в рабочей области 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.
   • Если столбец не пуст и с таблицей не связано 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.