Мониторинг запросов в службе "Поиск ИИ Azure"

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

На портале Azure приведены основные метрики для задержки запросов, загрузки запросов (QPS) и регулирования. Исторические данные, которые вставляется в эти метрики, можно получить на портале в течение 30 дней. Для более длительного хранения или отчета о операционных данных и строках запроса необходимо добавить параметр диагностики, указывающий параметр хранилища для сохранения операций и метрик журнала. Рекомендуется использовать рабочую область Log Analytics в качестве назначения для операций с журналами. Запросы Kusto и исследование данных предназначены для рабочей области Log Analytics.

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

  • Использование оплачиваемой службы (служба, созданная на уровне "Базовый" или "Стандартный"). Бесплатная служба, совместно используется несколькими подписчиками, что приводит к некоторой изменчивости при изменении нагрузок.

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

Совет

С помощью дополнительного кода на стороне клиента и Application Insights можно также собирать дополнительную информацию, чтобы получить более подробные сведения о том, что привлекает интерес пользователей приложения. Дополнительные сведения см. в статье Что такое аналитика поискового трафика?

Объем запросов (QPS)

Объем измеряется как количество поисковых запросов в секунду (Queries Per Second, QPS), встроенная метрика, которая может передаваться как среднее значение, число, минимальное или максимальное значение для запросов, выполняемых в течение окна длительностью одна минута. Интервал в одну минуту (TimeGrain = "PT1M") для метрик зафиксирован в системе.

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

Тип агрегирования Description
По средней Среднее число секунд за минуту, в течение которых выполнялся запрос.
Count Количество метрик, переданных в журнал в течение интервала времени длительностью одна минута.
Максимум Максимальное число поисковых запросов в секунду, зарегистрированное в течение минуты.
Минимум Минимальное число поисковых запросов в секунду, зарегистрированное в течение минуты.
Sum Сумма метрик для всех запросов, выполненных в течение минуты.

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

Еще один пример: если узел порождает 100 метрик и значение каждой метрики равно 40, то Count равно 100, Sum — 4000, Average — 40, а Max — 40.

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

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

Задержка поиска

Тип агрегирования Задержка
По средней Средняя длительность выполнения запроса в миллисекундах.
Count Количество метрик, переданных в журнал в течение интервала времени длительностью одна минута.
Максимум Максимальная длительность выполнения запроса в выборке.
Минимум Минимальная длительность выполнения запроса в выборке.
Итог Общее время выполнения всех запросов в выборке, выполненных в течение интервала (одна минута).

Рассмотрим следующий пример метрик Задержка поиска: выбрано 86 запросов средней длительностью 23,26 миллисекунды. Минимальное значение, равное 0, означает, что некоторые запросы были отброшены. Выполнение самого длительного запроса заняло 1000 миллисекунд. Общее время выполнения составило 2 секунды.

Latency aggregations

Регулируемые запросы

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

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

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

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

  • Служба возвращает ошибку "You are sending too many requests. Please try again later."
  • Служба возвращает код ошибки 503, указывающий, что служба в данный момент недоступна.
  • Если вы используете портал (например, поиск Обозреватель), запрос удаляется автоматически и необходимо снова выбрать поиск.

Чтобы подтвердить регулируемые запросы, используйте метрику Регулируемые поисковые запросы. Можно просмотреть метрики на портале или создать метрику оповещения, как описано в этой статье. Для запросов, которые были удалены в пределах интервала выборки, используйте Total , чтобы получить процент запросов, которые не выполнялись.

Тип агрегирования Регулирование
По средней Процент запросов, отброшенных в течение интервала.
Count Количество метрик, переданных в журнал в течение интервала времени длительностью одна минута.
Максимум Процент запросов, отброшенных в течение интервала.
Минимум Процент запросов, отброшенных в течение интервала.
Итог Процент запросов, отброшенных в течение интервала.

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

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

Throttled aggregations

Просмотр метрик на портале

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

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

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

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

    Metrics explorer for QPS metric

  3. В правом верхнем углу задайте интервал времени.

  4. Выберите вариант визуализации. По умолчанию это график.

  5. Настроив дополнительные агрегаты, выбрав "Добавить метрики " и выбрав различные агрегаты.

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

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

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

  1. В разделе "Мониторинг" выберите Журналы, чтобы открыть пустое окно запроса в Log Analytics.

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

       AzureDiagnostics
    | project OperationName, Query_s, IndexName_s, Documents_d
    | where OperationName == "Query.Search"
    | where Query_s != "?api-version=2023-07-01-preview&search=*"
    | where IndexName_s != "realestate-us-sample-index"
    
  3. При необходимости задайте для фильтра "Столбец" значение Query_s для поиска по конкретному синтаксису или строке. Например, можно отфильтровать его равным?api-version=2023-11-01&search=*&%24filter=HotelName.

    Logged query strings

Хотя этот метод работает для импровизированного исследования, создание отчета позволяет консолидировать и представлять строки запросов в макете, более пригодном для анализа.

Обнаружение долго выполняющихся запросов

Добавьте столбец Duration (длительность), чтобы получить числа для всех запросов, а не только для выбранных в качестве метрики. Сортировка этих данных показывает, какие запросы выполняются дольше других.

  1. В разделе "Мониторинг" выберите Журналы для запроса сведений о журнале.

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

    AzureDiagnostics
    | project OperationName, resultSignature_d, DurationMs, Query_s, Documents_d, IndexName_s
    | where OperationName == "Query.Search"
    | sort by DurationMs
    

    Sort queries by duration

Создание оповещения для метрики

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

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

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

Если вы отправляете ограничения определенной конфигурации реплика секции, настройка оповещений для пороговых значений тома запросов (QPS) также полезна.

  1. В разделе "Мониторинг" выберите "Оповещения" и выберите "Создать правило генерации оповещений".

  2. В разделе "Условие" нажмите кнопку "Добавить".

  3. Настройте логику сигнала. В поле "Тип сигнала" выберите метрики, а затем выберите сигнал.

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

  5. Затем прокрутите вниз до пункта "Логика оповещений". При проверке концепции для целей тестирования можно указать искусственно низкое значение.

  6. Затем укажите или создайте группу действий. Это реакция на достижение порогового значения. Он может быть push-уведомлением или автоматическим ответом.

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

Если вы указали уведомление по электронной почте, вы получите сообщение электронной почты из Microsoft Azure с строкой темы "Azure: активированная серьезность: 3 <your rule name>".

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

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