Оптимизация запросов журналов в Azure Monitor

Azure Monitor журналы используют Azure обозреватель данных (ADX) для хранения данных журнала и выполнения запросов для анализа этих данных. Он создает, управляет и обслуживает кластеры ADX, а также оптимизирует их для рабочей нагрузки анализа журналов. При выполнении запроса он оптимизирован и направляется в соответствующий кластер ADX, в котором хранятся данные рабочей области. В обоих журналах Azure Monitor и Azure обозреватель данных используется множество механизмов автоматического оптимизации запросов. Хотя автоматическая оптимизация обеспечивает значительное повышение производительности, в некоторых случаях можно значительно повысить производительность запросов. В этой статье описываются вопросы производительности и несколько способов их устранения.

Большинство методов являются общими для запросов, которые выполняются непосредственно в журналах обозреватель данных и Azure Monitor Azure, хотя существует несколько уникальных вопросов, касающихся журналов Azure Monitor, которые обсуждаются здесь. Дополнительные советы по оптимизации Azure обозреватель данных см. в разделе рекомендации по запросам.

Оптимизированные запросы будут:

  • Ускорить выполнение, сократить общую длительность выполнения запроса.
  • Меньше шансов на регулирование или отклонение.

Следует уделить особое внимание запросам, используемым для повторной и многовременных использования, таких как панели мониторинга, оповещения, Logic Apps и Power BI. Влияние неэффективного запроса в таких случаях существенно.

Панель производительности запросов

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

Панель производительности запросов

Индикаторы производительности запросов

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

  • Общий ЦП: Общее вычисление, используемое для обработки запроса на всех вычислительных узлах. Он представляет время, используемое для вычисления, анализа и выборки данных.

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

  • Интервал времени обработанного запроса: разрыв между последними и самыми старыми данными, которые были доступны для обработки запроса. Влияет на явный диапазон времени, указанный для запроса.

  • Возраст обработанных данных: разрыв между Now и самыми старыми данными, к которым осуществлялся доступ для обработки запроса. Это сильно влияет на эффективность выборки данных.

  • Число рабочих областей: сколько рабочих областей было обращено во время обработки запроса из-за неявного или неявного выбора.

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

  • Параллелизм. указывает, сколько система смогла выполнить этот запрос на нескольких узлах. Относится только к запросам с высоким потреблением ресурсов ЦП. Влияет на использование конкретных функций и операторов.

Всего ресурсов ЦП

Фактический вычислительный ЦП, который был инвестирован для обработки этого запроса на всех узлах обработки запросов. Так как большинство запросов выполняются на большом количестве узлов, обычно это будет намного больше, чем длительность выполнения запроса.

Запрос, в котором используется более 100 секунд ЦП, считается запросом, использующим чрезмерные ресурсы. Запрос, в котором используется более 1 000 секунд ЦП, считается нежелательным запросом и может регулироваться.

Время обработки запроса затрачено на следующее:

  • Получение данных. Извлечение старых данных будет потреблять больше времени, чем получение последних данных.
  • Обработка данных — логика и вычисление данных.

Кроме времени, затраченного на узлы обработки запросов, существует дополнительное время, затрачиваемое Azure Monitor журналов на: проверка подлинности пользователя и проверка того, что им разрешен доступ к этим данным, обнаружение хранилища данных, анализ запроса и выделение узлов обработки запросов. Это время не включено в общее время ЦП запроса.

Ранний отбор записей перед использованием функций высокой загрузки ЦП

Некоторые команды и функции запросов сильно загружены ЦП. Это особенно справедливо для команд, которые анализируют JSON и XML или извлекают сложные регулярные выражения. Такой синтаксический анализ может выполняться явно с помощью функций parse_json () или parse_xml () или неявно при ссылке на динамические столбцы.

Эти функции потребляют производительность ЦП пропорционально количеству обрабатываемых строк. Наиболее эффективная оптимизация заключается в том, чтобы добавить условия WHERE на раннем этапе запроса, которые могут отфильтровывать максимально возможное количество записей до выполнения функции с интенсивным использованием ЦП.

Например, следующие запросы выдают тот же результат, но второй из них гораздо эффективнее, чем условие WHERE перед синтаксическим анализом исключает многие записи:

//less efficient
SecurityEvent
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32"  // Problem: irrelevant results are filtered after all processing and parsing is done
| summarize count() by FileHash, FilePath
//more efficient
SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32"  // exact removal of results. Early filter is not accurate enough
| summarize count() by FileHash, FilePath
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before

Избегайте использования вычисляемых предложений WHERE

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

//less efficient
Syslog
| extend Msg = strcat("Syslog: ",SyslogMessage)
| where  Msg  has "Error"
| count 
//more efficient
Syslog
| where  SyslogMessage  has "Error"
| count 

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

//less efficient
SecurityEvent
| where tolower(Process) == "conhost.exe"
| count 
//more efficient
SecurityEvent
| where Process =~ "conhost.exe"
| count 

Использование эффективных статистических команд и измерений в итогах и объединении

Хотя некоторые команды статистической обработки, такие как Max (), Sum (), Count ()и AVG () , имеют низкую нагрузку на ЦП из-за их логики, другие являются более сложными и включают эвристику и оценки, которые позволяют эффективно выполнять их. Например, функция DCount () использует алгоритм хиперлоглог, чтобы предоставить более четкое оценочное число больших наборов данных без фактического учета каждого значения. функции процентиля выполняют аналогичные приближения с использованием ближайшего алгоритма оценки процентиля. Некоторые команды включают необязательные параметры, которые снижают их влияние. Например, функция make () имеет необязательный параметр, определяющий максимальный размер набора, который значительно влияет на ЦП и память.

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

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

//less efficient
Perf
| summarize avg(CounterValue) 
by CounterName, CounterPath, ObjectName
//make the group expression more compact improve the performance
Perf
| summarize avg(CounterValue), any(CounterName), any(ObjectName) 
by CounterPath

Потребление ресурсов ЦП также может затронуть условием расположения или расширенными столбцами, требующими интенсивного вычисления. Все тривиальные сравнения строк, такие как EQUAL = = и StartsWith , имеют примерно одинаковое воздействие на ЦП, в то время как расширенные совпадения текста имеют больше влияния. В частности, оператор имеет более эффективный оператор Contains . Из-за методов обработки строк более эффективным является поиск строк, длина которых превышает четыре символа, чем короткие строки.

Например, следующие запросы дают аналогичные результаты, в зависимости от политики именования компьютеров, но второй из них является более эффективным:

//less efficient – due to filter based on contains
Heartbeat
| where Computer contains "Production" 
| summarize count() by ComputerIP 
//less efficient – due to filter based on extend
Heartbeat
| extend MyComputer = Computer
| where MyComputer startswith "Production" 
| summarize count() by ComputerIP 
//more efficient
Heartbeat
| where Computer startswith "Production" 
| summarize count() by ComputerIP 

Примечание

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

Избегайте полного синтаксического анализа XML и JSON, когда выполняется синтаксический анализ строк

Полный синтаксический анализ объекта XML или JSON может потреблять большие ресурсы ЦП и памяти. Во многих случаях, когда требуется только один или два параметра и объекты XML или JSON, проще анализировать их как строки с помощью оператора Parse или других методов синтаксического анализа текста. Повышение производительности будет более значительным, так как количество записей в объекте XML или JSON увеличится. Это важно, когда число записей достигает десятка миллионов.

Например, следующий запрос возвратит точно те же результаты, что и вышеприведенные запросы, без выполнения полного синтаксического анализа XML. Обратите внимание, что он делает некоторые предположения относительно структуры XML-файла, например, когда элемент FilePath находится после FileHash и ни один из них не имеет атрибутов.

//even more efficient
SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" *
| summarize count() by FileHash, FilePath
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before

Данные, используемые для обработанного запроса

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

Запрос, обрабатывающий более 2 000KB данных, считается запросом, использующим чрезмерные ресурсы. Запрос, обрабатывающий более 20 000KB данных, считается запросом с нарушениями и может регулироваться.

В журналах Azure Monitor столбец timegenerated используется в качестве способа индексирования данных. Ограничение значений timegenerated таким образом, чтобы максимально сократить диапазон, может значительно повысить производительность запросов, значительно ограничивая объем данных, которые должны быть обработаны.

Избегайте ненужного использования операторов поиска и объединения

Другой фактор, увеличивающий объем обрабатываемых данных, — использование большого количества таблиц. Обычно это происходит при search * union * использовании команд и. Эти команды заставляют систему оценивать и проверять данные из всех таблиц в рабочей области. В некоторых случаях в рабочей области могут быть сотни таблиц. Старайтесь не столько, сколько возможно, используя "Поиск *" или любой поиск, не выполняя его с определенной таблицей.

Например, следующие запросы выдают точно такой же результат, но последний из них является наиболее эффективным:

// This version scans all tables though only Perf has this kind of data
search "Processor Time" 
| summarize count(), avg(CounterValue)  by Computer
// This version scans all strings in Perf tables – much more efficient
Perf
| search "Processor Time" 
| summarize count(), avg(CounterValue)  by Computer
// This is the most efficient version 
Perf 
| where CounterName == "% Processor Time"  
| summarize count(), avg(CounterValue)  by Computer

Добавление ранних фильтров в запрос

Другим методом уменьшения объема данных является Размещение условий в начале запроса. Платформа обозреватель данных Azure включает в себя кэш, позволяющий понять, какие секции содержат данные, относящиеся к конкретному условию WHERE. Например, если запрос содержит, то where EventID == 4624 запрос будет распределяться только на узлы, обрабатывающие секции с совпадающими событиями.

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

//less efficient
SecurityEvent
| summarize LoginSessions = dcount(LogonGuid) by Account
//more efficient
SecurityEvent
| where EventID == 4624 //Logon GUID is relevant only for logon event
| summarize LoginSessions = dcount(LogonGuid) by Account

Предотвращение нескольких просмотров одних и тех же исходных данных с помощью условных агрегатных функций и функции материализации

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

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

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

//Scans the SecurityEvent table twice and perform expensive join
SecurityEvent
| where EventID == 4624 //Login event
| summarize LoginCount = count() by Account
| join 
(
    SecurityEvent
    | where EventID == 4688 //Process execution event
    | summarize ExecutionCount = count(), ExecutedProcesses = make_set(Process) by Account
) on Account
//Scan only once with no join
SecurityEvent
| where EventID == 4624 or EventID == 4688 //early filter
| summarize LoginCount = countif(EventID == 4624), ExecutionCount = countif(EventID == 4688), ExecutedProcesses = make_set_if(Process,EventID == 4688)  by Account

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

//Scan SecurityEvent table twice
union(
SecurityEvent
| where EventID == 8002 
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" *
| distinct FilePath
),(
SecurityEvent
| where EventID == 4799
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" * 
| distinct CallerProcessName1
)
//Single scan of the SecurityEvent table
SecurityEvent
| where EventID == 8002 or EventID == 4799
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" * //Relevant only for event 8002
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" *  //Relevant only for event 4799
| extend FilePath = iif(isempty(CallerProcessName1),FilePath,"")
| distinct FilePath, CallerProcessName1

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

Уменьшение числа извлекаемых столбцов

Так как Azure обозреватель данных представляет собой хранилище данных по столбцам, извлечение всех столбцов не зависит от других. Число извлекаемых столбцов напрямую влияет на общий объем данных. Следует включать в выходные данные только те столбцы, которые необходимы для суммирования результатов или проецирования конкретных столбцов. Обозреватель данных Azure имеет несколько оптимизаций для уменьшения числа извлеченных столбцов. Если он определяет, что столбец не требуется, например если на него нет ссылки в команде обобщить , он не будет извлекать его.

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

//Less columns --> Less data
SecurityEvent
| summarize count() by Computer  
//More columns --> More data
SecurityEvent
| summarize count(), dcount(EventID), avg(Level) by Computer  

Интервал времени обработанного запроса

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

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

Диапазон времени можно задать с помощью селектора диапазона времени на экране Log Analytics, как описано в разделе область запроса журнала и диапазон времени в Azure Monitor log Analytics. Это рекомендуемый метод, так как выбранный диапазон времени передается серверной части с помощью метаданных запроса.

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

Убедитесь, что все вложенные запросы имеют фильтр TimeGenerated

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

Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
    Heartbeat
    //No time span filter in this part of the query
    | summarize IPs = makeset(ComputerIP, 10) by  Computer
) on Computer

Обычно такая ошибка возникает, когда arg_max () используется для поиска последнего вхождения. Пример:

Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
    Heartbeat
    //No time span filter in this part of the query
    | summarize arg_max(TimeGenerated, *), min(TimeGenerated)   
by Computer
) on Computer

Это можно легко исправить, добавив фильтр времени во внутренний запрос:

Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
    Heartbeat
    | where TimeGenerated > ago(1d) //filter for this part
    | summarize arg_max(TimeGenerated, *), min(TimeGenerated)   
by Computer
) on Computer

Еще один пример для этой ошибки — выполнение фильтрации области времени сразу после объединения нескольких таблиц. При выполнении объединения каждый вложенный запрос должен быть ограничен. Для обеспечения согласованности области можно использовать инструкцию let .

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

Heartbeat 
| summarize arg_min(TimeGenerated,*) by Computer
| union (
    Perf 
    | summarize arg_min(TimeGenerated,*) by Computer) 
| where TimeGenerated > ago(1d)
| summarize min(TimeGenerated) by Computer

Этот запрос следует исправить следующим образом:

let MinTime = ago(1d);
Heartbeat 
| where TimeGenerated > MinTime
| summarize arg_min(TimeGenerated,*) by Computer
| union (
    Perf 
    | where TimeGenerated > MinTime
    | summarize arg_min(TimeGenerated,*) by Computer) 
| summarize min(TimeGenerated) by Computer

Ограничения периода измерения времени

Измерение всегда будет больше указанного фактического времени. Например, если фильтр для запроса составляет 7 дней, система может проверить 7,5 или 8,1 дней. Это связано с тем, что система разделяет данные на фрагменты в переменной размере. Чтобы гарантировать сканирование всех соответствующих записей, оно сканирует весь раздел, который может охватывать несколько часов и даже более суток.

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

Важно!

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

Возраст обработанных данных

Azure обозреватель данных использует несколько уровней хранилища: в памяти, на локальных дисках SSD и в более медленных больших двоичных объектах Azure. Чем более новые данные, тем выше вероятность того, что она будет храниться на более производительном уровне с меньшими задержками, уменьшая длительность запроса и ЦП. Кроме самих данных, система также имеет кэш для метаданных. Чем выше данные, тем меньше вероятность того, что метаданные будут находиться в кэше.

Запрос, который обрабатывает данные более чем за 14 дней назад, считается запросом, использующим чрезмерные ресурсы.

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

Например, можно использовать следующие варианты:

  • Не устанавливайте диапазон времени в Log Analytics с неограниченным вложенным запросом. пример выше.
  • Использование API без необязательных параметров временного диапазона.
  • Использование клиента, который не выполняет принудительный период времени, например Power BI соединителя.

См. примеры и примечания в разделе предыдущей, так как они также важны в этом случае.

Число регионов

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

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

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

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

Важно!

Если запрос выполняется в нескольких регионах, измерения ЦП и данных будут неточными и будут представлять измерение только в одном из регионов.

Число рабочих областей

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

Использование нескольких рабочих областей может быть результатом:

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

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

Запрос, охватывающий более 5 рабочих областей, считается запросом, использующим чрезмерные ресурсы. Запросы не могут охватывать более 100 рабочих областей.

Важно!

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

Parallelism

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

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

Варианты поведения запросов, которые могут сократить параллелизм, включают:

  • Использование сериализации и оконных функций, таких как оператор сериализации, Next (), prev ()и функций строк . В некоторых случаях можно использовать временные ряды и функции анализа пользователей. Неэффективная сериализация также может возникнуть, если следующие операторы используются не в конце запроса: Range, Sort, Order, Top, Top-hitters, GetSchema.
  • Использование функции агрегирования DCount () заставляет систему иметь центральную копию уникальных значений. Когда масштаб данных высок, рассмотрите возможность использования необязательных параметров функции DCount для снижения точности.
  • Во многих случаях оператор Join снижает общий параллелизм. Изучите случайное соединение в качестве альтернативы при возникновении проблем с производительностью.
  • В запросах области ресурсов проверки, выполняемые перед выполнением Kubernetes RBAC или Azure RBAC, могут быть ограничены в ситуациях, когда имеется очень большое количество назначений ролей Azure. Это может привести к более длинным проверкам, которые приведут к более низкому параллелизму. Например, запрос выполняется в подписке, в которой есть тысячи ресурсов, и каждый ресурс имеет много назначений ролей на уровне ресурса, а не в подписке или группе ресурсов.
  • Если запрос обрабатывает небольшие фрагменты данных, его параллелизм будет небольшим, так как система не будет распределять их между несколькими вычислительными узлами.

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