Поделиться через

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

  • Статья

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

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

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

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

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

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

Ниже приведено подробное видеоруководство по оптимизации запросов.

Панель "Сведения о запросе"

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

Снимок экрана: панель сведений о запросе в Azure Monitor Log Analytics.

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

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

  • Всего ЦП. Общий объем вычислений при обработке запроса на всех вычислительных узлах. Представляет значение времени, затраченное на вычисления, анализ и получение данных.
  • Данные, используемые для обработанного запроса. Общий объем данных, к которым производилось обращение с целью обработки запроса. Зависит от размера целевой таблицы, используемого интервала времени, примененных фильтров и количества столбцов, на которые имеются ссылки.
  • Интервал времени обработанного запроса. Разница в возрасте самых новых и самых старых данных, к которым происходило обращение для обработки запроса. На этот показатель влияет явный заданный диапазон времени для запроса.
  • Возраст обработанных данных. Возраст самых старых данных, к которым происходило обращение для обработки запроса, относительно текущего момента. Этот показатель существенно влияет на эффективность выборки данных.
  • Количество рабочих областей: Сколько рабочих областей было доступо во время обработки запросов на основе неявного или явного выбора.
  • Количество регионов: Сколько регионов было доступ к обработке запросов на основе неявного или явного выбора рабочих областей. Запросы с несколькими регионами гораздо менее эффективны, а показатели производительности представляют частичное покрытие.
  • Параллелизм. Указывает, насколько системе удалось выполнить этот запрос на нескольких узлах. Относится только к запросам с высоким потреблением ЦП. Зависит от использования определенных функций и операторов.

Всего ЦП

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

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

Время обработки запроса уходит на:

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

Помимо времени, затраченного на узлы обработки запросов, журналы Azure Monitor тратят время:

  • Проверка подлинности пользователя и проверка их разрешения на доступ к этим данным.
  • Поиск хранилища данных.
  • Анализ запроса.
  • Выделение узлов обработки запросов.

Затрачиваемое на это время не включено в общую длительность общей загрузки ЦП для запроса.

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

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

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

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

//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

Использование эффективных команд агрегирования и измерений в командах summarize и join

Некоторые команды агрегирования, такие как max(), sum(), count()и avg() имеют низкое влияние на ЦП из-за их логики. Другие команды являются более сложными и включают эвристики и оценки, которые позволяют эффективно выполнять их. Например, dcount() использует алгоритм HyperLog для обеспечения близкой оценки определенного количества больших наборов данных без фактического подсчета каждого значения.

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

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

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

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

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

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

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

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

Предотвращение ненужного использования операторов search и union

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

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

// 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

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

Другим методом уменьшения объема данных является размещение условий WHERE в начале запроса. Платформа Azure Data Explorer включает кэш, который позволяет ему знать, какие секции включают данные, относящиеся к конкретному 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

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

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

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

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

//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 относится только к своим событиям. Затем оператор 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

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

Уменьшите количество полученных столбцов.

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

Azure Data Explorer имеет несколько оптимизаций для уменьшения количества извлеченных столбцов. Если он определяет, что столбец не нужен, например, если он не указан в команде сводки , он не получит его.

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

//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. Этот метод рекомендуется, так как выбранный диапазон времени передается в внутренний конец с помощью метаданных запроса.

Альтернативный метод заключается в явном включении условия, в котором находится TimeGenerated в запросе. Используйте этот метод, так как он гарантирует исправление интервала времени, даже если запрос используется из другого интерфейса.

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

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

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

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 таблицах и Perf не только последний день:

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 Data Explorer использует несколько уровней хранилища: в памяти, локальные диски SSD и гораздо медленнее BLOB-объектов Azure. Чем более новые данные, тем выше вероятность того, что она хранится на более производительном уровне с меньшей задержкой, что снижает длительность запроса и ЦП. Кроме самих данных, система также имеет кэш для метаданных. Чем старше данные, тем меньше шансов, что его метаданные будут находиться в кэше.

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

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

Такие случаи могут быть, например:

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

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

Количество регионов

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

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

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

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

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

Внимание

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

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

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

Использование нескольких рабочих областей может привести к экземплярам, когда:

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

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

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

Внимание

  • В некоторых сценариях с несколькими рабочими областями измерения ЦП и данных не будут точными и будут представлять измерение только нескольких рабочих областей.
  • Запросы между рабочими областями имеют явный идентификатор: идентификатор рабочей области или идентификатор ресурса Azure, потребляют меньше ресурсов и являются более производительными.

Параллелизм

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

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

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

  • Использование функций сериализации и окон, таких как оператор сериализации, next(), prev() и функции строк . В некоторых случаях можно использовать временные ряды и функции аналитики пользователей. Неэффективная сериализация может также произойти, если следующие операторы не используются в конце запроса: диапазон, сортировка, порядок, верхний, верхний, топ-хиттеры и получаетchema.
  • Использование функции агрегирования dcount() заставляет систему иметь центральную копию отдельных значений. Если масштаб данных высок, рекомендуется использовать dcount необязательные параметры функции для уменьшения точности.
  • Во многих случаях оператор соединения уменьшает общий параллелизм. Проверьте shuffle join как альтернативу, если производительность проблематична.
  • В запросах области ресурсов контроль доступа на основе ролей Kubernetes (RBAC) или проверки Azure RBAC могут задерживаться в ситуациях, когда существует большое количество назначений ролей Azure. Эта ситуация может привести к более длительным проверкам, что приведет к снижению параллелизма. Например, запрос может выполняться в подписке, где есть тысячи ресурсов, и каждый ресурс имеет множество назначений ролей на уровне ресурса, а не в подписке или группе ресурсов.
  • Если запрос обрабатывает небольшие фрагменты данных, его параллелизм будет низким, так как система не будет распределять ее по многим вычислительным узлам.

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

Справочная документация по язык запросов Kusto