Surveiller les demandes de requête dans Azure AI Search
Cet article explique comment mesurer les performances et le volume des requêtes à l’aide des métriques et de la journalisation des ressources intégrées. Il explique également comment obtenir les chaînes de requête entrées par les utilisateurs de l’application.
Le portail Azure affiche les métriques de base relatives à la latence des requêtes, à la charge des requêtes (QPS) et à la limitation. Les données historiques qui alimentent ces métriques sont accessibles dans le portail pendant 30 jours. Pour une conservation plus longue, ou pour générer des rapports sur les données opérationnelles et les chaînes de requêtes, vous devez ajouter un paramètre de diagnostic spécifiant l’option de stockage relative aux métriques et opérations consignées persistantes. Nous vous recommandons l’utilisation de l’'espace de travail Log Analytics en tant que destination pour les opérations journalisées. Les requêtes Kusto et l’exploration des données ciblent un espace de travail Log Analytics.
Pour optimiser l'intégrité de la mesure des données, appliquez notamment les conditions suivantes :
Utilisez un service facturable (service créé au niveau De base ou Standard). Le service gratuit est partagé par différents abonnés, ce qui introduit une certaine volatilité à mesure que les charges se déplacent.
Si possible, utilisez un réplica et une partition uniques afin de créer un environnement autonome et isolé. Si vous utilisez différents réplicas, la moyenne des métriques de requête est calculée sur différents nœuds, ce qui peut nuire à la précision des résultats. De même, si vous utilisez différentes partitions, les données sont éparpillées, avec le risque que certaines partitions présentent des données différentes si une indexation est également en cours. Lors du paramétrage des performances des requêtes, un nœud et une partition uniques offrent un environnement plus stable pour les tests.
Conseil
Grâce à un code côté client supplémentaire et à Application Insights, vous pouvez également capturer des données de clics pour bénéficier d'insights plus approfondis sur ce qui suscite l'intérêt des utilisateurs de votre application. Pour plus d’informations, consultez Analytique du trafic des recherches.
Volume de requêtes (RPS)
Le volume est mesuré en requêtes de recherche par seconde (RPS), une métrique intégrée qui peut être exprimée en tant que moyenne, nombre, minimum ou maximum de requêtes exécutées sur une période d'une minute. Pour les métriques, des intervalles d'une minute (TimeGrain = "PT1M") sont fixés dans le système.
Les requêtes sont souvent exécutées en quelques millisecondes, par conséquent seules les requêtes mesurées en secondes apparaissent dans les métriques.
| Type d’agrégation | Description |
|---|---|
| Moyenne | Sur une période d'une minute, nombre moyen de secondes nécessaires à l'exécution de la requête. |
| Count | Nombre de métriques émises dans le journal pendant l'intervalle d'une minute. |
| Maximum | Nombre maximum de requêtes de recherche par seconde enregistrées en une minute. |
| Minimum | Nombre minimum de requêtes de recherche par seconde enregistrées en une minute. |
| Somme | Somme de toutes les requêtes exécutées pendant l'intervalle d'une minute. |
Par exemple, sur une minute, le schéma peut être le suivant : une seconde de charge élevée, qui représente votre valeur SearchQueriesPerSecond maximale, puis 58 secondes de charge moyenne, et enfin une seconde avec une seule requête, qui représente la valeur minimale.
Autre exemple : si un nœud émet 100 métriques, sachant que la valeur de chaque métrique est égale à 40, alors "Count" = 100, "Sum" = 4000, "Average" = 40 et "Max" = 40.
Performances des requêtes
À l'échelle du service, les performances des requêtes sont mesurées en termes de latence de recherche (durée d'exécution d'une requête) et de requêtes limitées qui ont été abandonnées en raison d'un conflit de ressources.
Latence de recherche
| Type d’agrégation | Latence |
|---|---|
| Moyenne | Durée moyenne de la requête en millisecondes. |
| Count | Nombre de métriques émises dans le journal pendant l'intervalle d'une minute. |
| Maximum | Requête la plus longue de l'échantillon. |
| Minimum | Requête la plus courte de l'échantillon. |
| Total | Durée d'exécution totale de toutes les requêtes de l'échantillon, exécutées dans l'intervalle (une minute). |
Prenons l’exemple suivant de métriques de latence de recherche : 86 requêtes ont été échantillonnées, avec une durée moyenne de 23,26 millisecondes. Un minimum de 0 indique que certaines requêtes ont été abandonnées. La requête la plus longue s'est exécutée en 1 000 millisecondes. La durée d'exécution totale a été de 2 secondes.
Requêtes limitées
Les requêtes limitées font référence aux requêtes qui sont abandonnées au lieu d'être traitées. Dans la plupart des cas, la limitation fait partie intégrante de l'exécution du service. Cela ne traduit pas nécessairement un problème.
La limitation se produit lorsque le nombre de requêtes en cours d’exécution dépasse la capacité. Vous pouvez constater une augmentation du nombre de demandes limitées lorsqu'un réplica est retiré de la rotation ou pendant l'indexation. Les demandes de requête et d'indexation sont gérées par le même ensemble de ressources.
Le service détermine s'il faut abandonner les demandes en fonction de la consommation des ressources. Le pourcentage de ressources consommées sur la mémoire, le processeur et les E/S disque est calculé en moyenne sur une période donnée. Si ce pourcentage dépasse un certain seuil, toutes les demandes adressées à l'index sont limitées jusqu'à ce que le volume de demandes baisse.
Selon votre client, une demande limitée est signalée comme suit :
- Un service retourne une erreur
"You are sending too many requests. Please try again later." - Un code d'erreur 503 est renvoyé pour indiquer que le service est indisponible.
- Si vous utilisez le portail (par exemple, l'Explorateur de recherche), la requête est abandonnée en mode silencieux et vous devez à nouveau sélectionner Rechercher.
Pour confirmer les requêtes limitées, utilisez la métrique Requêtes de recherche limitées. Vous pouvez explorer les métriques sur le portail ou créer une métrique d'alerte comme décrit dans cet article. Pour les requêtes qui ont été abandonnées au cours de l'intervalle d'échantillonnage, utilisez Total afin d'obtenir le pourcentage de requêtes qui n'ont pas été exécutées.
| Type d’agrégation | Limitation |
|---|---|
| Moyenne | Pourcentage de requêtes abandonnées pendant l'intervalle. |
| Count | Nombre de métriques émises dans le journal pendant l'intervalle d'une minute. |
| Maximum | Pourcentage de requêtes abandonnées pendant l'intervalle. |
| Minimum | Pourcentage de requêtes abandonnées pendant l'intervalle. |
| Total | Pourcentage de requêtes abandonnées pendant l'intervalle. |
Pour Pourcentage de requêtes de recherche limitées, les valeurs minimales, maximales, moyennes et totales seront identiques : il s’agit du pourcentage de requêtes de recherche qui ont été limitées, en fonction du nombre total de requêtes de recherche pendant une minute.
Dans la capture d'écran suivante, la première valeur correspond au nombre de métriques envoyées au journal. Les autres agrégations, qui apparaissent en haut ou en pointant sur la métrique, incluent la moyenne, le maximum et le total. Dans cet exemple, aucune demande n'a été abandonnée.
Explorer les métriques sur le portail
Pour un aperçu rapide des valeurs actuelles, l'onglet Surveillance de la page de présentation du service affiche trois mesures (Latence de recherche, Requêtes de recherche par seconde (par unité de recherche), Pourcentage de requêtes de recherche limitées) sur des intervalles fixes mesurés en heures, jours et semaines, avec la possibilité de modifier le type d'agrégation.
Pour une exploration plus approfondie, ouvrez Metrics Explorer à partir du menu Surveillance. Vous pourrez ainsi ajouter des données, effectuer un zoom sur celles-ci et les visualiser afin d'explorer les tendances ou les anomalies. Pour en savoir plus sur Metrics Explorer, suivez ce tutoriel consacré à la création d'un graphique de métriques.
Dans la section Surveillance, sélectionnez Métriques pour ouvrir Metrics Explorer en veillant à ce que l'étendue soit définie en fonction de votre service de recherche.
Sous Métriques, choisissez-en une dans la liste déroulante et passez en revue la liste des agrégations disponibles pour sélectionner le type de votre choix. L'agrégation définit la manière dont les valeurs collectées seront échantillonnées sur chaque intervalle de temps.
Dans le coin supérieur droit, définissez l'intervalle de temps.
Choisissez une visualisation. La visualisation par défaut est un graphique en courbes.
Ajoutez des agrégations supplémentaires en choisissant Ajouter des métriques et en sélectionnant différentes agrégations.
Zoomez sur une zone d'intérêt du graphique en courbes. Placez le pointeur de la souris au début de la zone, sélectionnez et maintenez le bouton gauche de la souris enfoncé, faites glisser de l’autre côté de la zone, puis relâchez le bouton. Cet intervalle de temps est agrandi dans le graphique.
Retourner les chaînes de requête entrées par les utilisateurs
Quand vous activez la journalisation des ressources, le système capture les demandes de requête dans la table AzureDiagnostics. Comme prérequis, vous devez déjà avoir spécifié une destination pour les opérations journalisées, soit un espace de travail d’analytique des journaux, soit une autre option de stockage.
Dans la section Surveillance, sélectionnez Journaux afin d'ouvrir une fenêtre de requête vide dans Log Analytics.
Exécutez l'expression suivante pour rechercher des opérations
Query.Search. Vous obtiendrez un jeu de résultats, sous forme de tableau, avec le nom de l'opération, la chaîne de requête, l'index interrogé et le nombre de documents trouvés. Les deux dernières instructions excluent les chaînes de requêtes correspondant à une recherche vide ou non spécifiée, sur un exemple d'index, ce qui réduit le bruit dans vos résultats.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"Vous pouvez également définir un filtre de colonne sur Query_s pour effectuer une recherche sur une syntaxe ou une chaîne spécifique. Par exemple, vous pouvez appliquer le filtre suivant : est égal à
?api-version=2023-11-01&search=*&%24filter=HotelName.
Cette technique fonctionne pour une investigation ad hoc, mais la création d'un rapport vous permettra de regrouper les chaînes de requêtes et de les présenter dans un format plus propice à l'analyse.
Identifier les requêtes longues
Ajoutez une colonne de durée pour obtenir les valeurs de toutes les requêtes, et pas seulement celles récupérées en tant que métriques. Le tri de ces données vous indique quelles requêtes prennent le plus de temps.
Dans la section Surveillance, sélectionnez Journaux pour rechercher des informations de journal.
Exécutez la requête suivante pour renvoyer des requêtes de base, triées par durée en millisecondes. Les requêtes longues figurent en haut.
AzureDiagnostics | project OperationName, resultSignature_d, DurationMs, Query_s, Documents_d, IndexName_s | where OperationName == "Query.Search" | sort by DurationMs
Créer une alerte de métrique
Une alerte de métrique établit un seuil pour envoyer une notification ou déclencher une action corrective que vous définissez à l’avance. Vous pouvez créer des alertes liées à l’exécution des requêtes, mais vous pouvez également en créer pour l’intégrité des ressources, les modifications de configuration du service de recherche, l’exécution des compétences et le traitement des documents (indexation).
Tous les seuils sont définis par l’utilisateur. Vous devez donc avoir une idée du niveau d'activité qui devrait déclencher l'alerte.
Pour la surveillance des requêtes, il est fréquent de créer une alerte de métrique pour la latence de recherche et les requêtes limitées. Si vous savez quand les requêtes sont abandonnées, vous pouvez rechercher des solutions pour réduire la charge ou augmenter la capacité. Par exemple, si les requêtes limitées augmentent pendant l'indexation, vous pouvez reporter celle-ci jusqu'à ce que l'activité de requête diminue.
Si vous repoussez les limites d'une configuration réplica-partition particulière, il convient également de définir des alertes pour les seuils de volumes de requêtes (RPS).
Sous Surveillance, sélectionnez Alertes, puis Créer une règle d’alerte.
Sous Condition, sélectionnez Ajouter.
Configurez la logique du signal. Pour le type de signal, choisissez métriques, puis sélectionnez le signal.
Après avoir sélectionné le signal, vous pouvez utiliser un graphique afin de visualiser les données historiques et prendre une décision éclairée sur le mode de configuration des conditions.
Faites ensuite défiler jusqu'à Logique d'alerte. Pour la preuve de concept, vous pouvez spécifier une valeur artificiellement faible à des fins de test.
Ensuite, spécifiez ou créez un groupe d'actions. Il s'agit de la réponse à appeler lorsque le seuil est atteint. Il peut s'agir d'une notification Push ou d'une réponse automatisée.
Enfin, spécifiez les détails de l'alerte. Nommez et décrivez l'alerte, attribuez une valeur de gravité et spécifiez si la règle doit être activée ou désactivée.
Si vous avez spécifié une notification par e-mail, vous recevez un e-mail de « Microsoft Azure » dont l’objet sera : « Azure : Gravité activée 3 <your rule name> ».
Étapes suivantes
Si ce n’est déjà fait, passez en revue les principes de base de la surveillance des services de recherche pour en savoir plus sur les différentes capacités de surveillance disponibles.