Мониторинг запросов в Поиск с использованием ИИ Azure

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

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

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

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

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

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

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

Поиск с использованием ИИ Azure сохраняет 30 дней данных метрик по умолчанию. Вы можете включить ведение журнала для длительного хранения. QPS доступен на портале Azure на вкладке Monitoring службы поиска.

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

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

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

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

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

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

Ограниченные запросы

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

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

Изучение метрик на портале Azure

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

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

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

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

   

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

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

5. Добавьте больше агрегаций, выбрав Добавить метрику и выбирая различные агрегаты.

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

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

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

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

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

      AzureDiagnostics
   | project OperationName, Query_s, IndexName_s, Documents_d
   | where OperationName == "Query.Search"
   | where Query_s != "?api-version=2026-04-01&search=*"
   | where IndexName_s != "hotels-sample"
   

3. При необходимости задайте фильтр столбцов в Query_s для поиска по определенному синтаксису или строке. Например, можно отфильтровать равно?api-version=2026-04-01&search=*&%24filter=HotelName.

   

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

Определение длительных запросов

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

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>".

Дальнейшие действия

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