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


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

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

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

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

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

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

Совет

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

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

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

Дополнительные сведения о метрике SearchQueriesPerSecond см. в статье "Поисковые запросы в секунду".

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

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

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

Задержка поиска указывает, сколько времени занимает запрос. Дополнительные сведения о метрии SearchLatency см. в статье "Задержка поиска".

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

Агрегаты задержки

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

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

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

Агрегаты регулируемых запросов

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

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

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

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

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

    Обозреватель метрик для метрики QPS

  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-11-01&search=*"
    | where IndexName_s != "realestate-us-sample-index"
    
  3. При необходимости задайте для фильтра "Столбец" значение Query_s для поиска по конкретному синтаксису или строке. Например, можно выполнить фильтрацию равным?api-version=2023-11-01&search=*&%24filter=HotelName.

    Зарегистрированные строки запросов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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