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.
Pour en savoir plus sur la métrique SearchQueriesPerSecond, consultez Requêtes de recherche par seconde.
Performances des requêtes
Les performances des requêtes à l’échelle du service sont mesurées en tant que latence de recherche et requêtes limitées.
Latence de recherche
La latence de recherche indique le temps nécessaire à l’exécution d’une requête. Pour en savoir plus sur la métrique SearchLatency, consultez Latence de recherche.
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. Pour en savoir plus sur la métrique ThrottledSearchQueriesPercentage, consultez Pourcentage de requêtes de recherche limitées.
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=2024-07-01&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=2024-07-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.