Анализ текстовых данных в журналах Azure Monitor

  • Статья

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

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

Необходимые разрешения

Методы анализа

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

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

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

Преимущества.

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

Недостатки.

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

Анализ данных во время выполнения запроса

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

Преимущества.

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

Недостатки.

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

Выполнение анализа данных после их сбора

Дополнительные сведения о анализе данных по мере их сбора см. в статье Структура преобразования в Azure Monitor. Этот подход создает в таблице настраиваемые свойства, которые могут использоваться запросами, как и любое другое свойство.

Анализ данных в запросе с помощью шаблонов

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

Простые текстовые шаблоны

Используйте в запросе оператор Выполнить анализ, чтобы создать одно или несколько пользовательских свойств, которые могут быть извлечены из выражения строки. Вы указываете шаблон, который нужно идентифицировать, и имена свойств, которые нужно создать. Этот подход полезен для данных со строками "ключ—значение" в форме, аналогичной key=value.

Рассмотрим пользовательский журнал с данными в следующем формате:

Time=2018-03-10 01:34:36 Event Code=207 Status=Success Message=Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected
Time=2018-03-10 01:33:33 Event Code=208 Status=Warning Message=Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
Time=2018-03-10 01:35:44 Event Code=209 Status=Success Message=Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
Time=2018-03-10 01:38:22 Event Code=302 Status=Error Message=Application could not connect to database
Time=2018-03-10 01:31:34 Event Code=303 Status=Error Message=Application lost connection to database

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

MyCustomLog_CL
| parse RawData with * "Time=" EventTime " Event Code=" Code " Status=" Status " Message=" Message
| project EventTime, Code, Status, Message

В этом примере вырывается имя пользователя имени участника-пользователя в AzureActivity таблице.

AzureActivity
| parse  Caller with UPNUserPart "@" * 
| where UPNUserPart != "" //Remove non UPN callers (apps, SPNs, etc)
| distinct UPNUserPart, Caller

Регулярные выражения

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

AzureActivity
| extend UPNUserPart = extract("([a-z.]*)@", 1, Caller) 
| distinct UPNUserPart, Caller

Чтобы обеспечить эффективный анализ в большом масштабе, Azure Monitor использует версию регулярных выражений re2, которая похожа, но не идентична некоторым другим вариантам регулярных выражений. Дополнительные сведения см. в описании синтаксиса выражения re2.

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

Данные с разделителями разделяют поля общим символом, например запятой в CSV-файле. Используйте функцию split для анализа данных с разделителями с помощью указанного разделителя. Этот подход можно использовать с оператором extend , чтобы вернуть все поля в данных или указать отдельные поля, которые будут включены в выходные данные.

Примечание

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

Рассмотрим пользовательский журнал с данными в следующем формате CSV:

2018-03-10 01:34:36, 207,Success,Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected
2018-03-10 01:33:33, 208,Warning,Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
2018-03-10 01:35:44, 209,Success,Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
2018-03-10 01:38:22, 302,Error,Application could not connect to database
2018-03-10 01:31:34, 303,Error,Application lost connection to database

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

MyCustomCSVLog_CL
| extend CSVFields  = split(RawData, ',')
| extend EventTime  = todatetime(CSVFields[0])
| extend Code       = toint(CSVFields[1]) 
| extend Status     = tostring(CSVFields[2]) 
| extend Message    = tostring(CSVFields[3]) 
| where getyear(EventTime) == 2018
| summarize count() by Status,Code

Выполнение анализа предопределенных структур в запросе

Если данные отформатированы в известной структуре, вы можете использовать одну из функций в язык запросов Kusto для анализа предопределенных структур:

В следующем примере запроса анализируется Properties поле AzureActivity таблицы, структурированное в формате JSON. Он сохраняет результаты в динамическом свойстве с именем parsedProp, которое включает отдельное именованное значение в JSON. Эти значения используются для фильтрации и суммирования результатов запроса.

AzureActivity
| extend parsedProp = parse_json(Properties) 
| where parsedProp.isComplianceCheck == "True" 
| summarize count() by ResourceGroup, tostring(parsedProp.tags.businessowner)

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

В следующем примере показана разбивка типа контроллера TGT Preauth домена. Тип существует только в EventData поле , которое является XML-строкой. Другие данные из этого поля не требуются. В этом случае анализ используется для выбора необходимого фрагмента данных.

SecurityEvent
| where EventID == 4768
| parse EventData with * 'PreAuthType">' PreAuthType '</Data>' * 
| summarize count() by PreAuthType

Использование функции для имитации таблицы

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

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

MyCustomCSVLog_CL
| extend CSVFields = split(RawData, ',')
| extend DateTime  = tostring(CSVFields[0])
| extend Code      = toint(CSVFields[1]) 
| extend Status    = tostring(CSVFields[2]) 
| extend Message   = tostring(CSVFields[3])

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

MyCustomCSVLog
| summarize count() by Status,Code

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

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