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

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

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

Требуемые разрешения

• Для синтаксического анализа данных во время сбора требуются Microsoft.Insights/dataCollectionRuleAssociations/* разрешения, как указано встроенной ролью участника Log Analytics, например.
• Для синтаксического анализа данных во время запроса требуются Microsoft.OperationalInsights/workspaces/query/*/read разрешения, как указано встроенной ролью Log Analytics Reader.

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

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

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

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

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

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

Недостатки.

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

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

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

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

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

Недостатки.

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

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

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

Примечание.

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

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

• JSON
• XML
• IРv4
• URL-адрес
• Запрос URL-адреса
• Путь к файлу
• Агент пользователя
• Версия строки

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

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

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