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

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

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

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

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

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

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

Преимущества этого метода таковы:

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

Недостатки этого метода таковы:

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

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

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

Преимущества этого метода таковы:

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

Недостатки этого метода таковы:

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

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

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

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

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

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

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

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

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

Следующий запрос проанализирует эти данные с разделением на отдельные свойства. Строка с проектом добавляется только для того, чтобы возвращать вычисленные свойства, а не 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-файле. Используйте функцию разделить для анализа данных с разделителями с помощью указанного вами разделителя. Вы можете использовать ее с оператором расширить, чтобы вернуть все поля в данных, или указать отдельные поля, которые будут включены в выходные данные.

Примечание

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

Рассмотрим пользовательский журнал с данными в формате 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 для анализа предопределенных структур:

В следующем примере запроса анализируется поле Свойства таблицы 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

Дальнейшие действия

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