Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article décrit les problèmes courants liés au développement de requêtes Azure Stream Analytics, ainsi que la façon de résoudre les problèmes de requêtes et de corriger les problèmes. De nombreuses étapes de dépannage nécessitent d’activer les journaux de ressources pour votre tâche Stream Analytics. Si les journaux de ressources ne sont pas activés, consultez la section Résoudre les problèmes liés à Azure Stream Analytics à l’aide des journaux de ressources.
La requête ne produit pas la sortie attendue
Examinez les erreurs en effectuant un test local :
- Dans le portail Azure, dans l’onglet Requête, sélectionnez Test. Utilisez les exemples de données téléchargés pour tester la requête. Examinez les éventuelles erreurs et tentez de les corriger.
- Vous pouvez également tester votre requête localement en utilisant les outils Azure Stream Analytics pour Visual Studio ou Visual Studio Code.
Déboguer des requêtes étape par étape localement à l’aide du diagramme de travail dans les outils Azure Stream Analytics pour Visual Studio Code. Le diagramme de travail montre comment les données circulent depuis les sources d’entrée, par exemple Azure Event Hubs et Azure IoT Hub, à travers plusieurs étapes de requête et enfin vers les puits de sortie. Le script associe chaque étape de requête à un ensemble de résultats temporaire que vous définissez en utilisant l’instruction WITH. Consultez les données et les métriques de chaque ensemble de résultats intermédiaires pour trouver la source du problème.
Si vous utilisez l’objet Timestamp By, assurez-vous que les événements présentent des horodatages postérieurs à l’heure de début du travail.
Éliminez les pièges les plus courants, comme par exemple :
- Une clause WHERE dans la requête filtrait tous les événements, de sorte que la requête ne produit aucune sortie.
- Une fonction CAST échoue, ce qui provoque l’échec du travail. Pour éviter les échecs de conversion de type, utilisez plutôt TRY_CAST.
- Lorsque vous utilisez des fonctions de fenêtre, attendez la fin de toute la durée de la fenêtre pour voir un résultat de la requête.
- L’horodatage des événements précède l’heure de démarrage de la tâche, donc la tâche ignore les événements.
- Les conditions JOIN ne correspondent pas. S’il n’y a pas de correspondances, la requête ne produit aucune sortie.
Assurez-vous de configurer les politiques d’ordre des événements comme prévu. Accédez à Paramètres et sélectionnez Ordre des événements. Le bouton Test n’applique pas la politique lorsque vous testez la requête. Ce résultat est une différence entre tester dans le navigateur et exécuter le travail en production.
Déboguez à l’aide des journaux d’activité et de ressources :
- Utilisez les journaux d’activité et appliquez des filtres pour identifier et déboguer les erreurs.
- Utilisez les journaux des ressources de tâche pour identifier et déboguer les erreurs.
Déboguer les requêtes progressivement
En traitement de données en temps réel, il est utile de savoir à quoi ressemblent les données au milieu de la requête. Pour visualiser les données intermédiaires, utilisez le diagramme de tâches dans Visual Studio. Si vous n'avez pas Visual Studio, vous pouvez prendre des mesures supplémentaires pour produire des données intermédiaires.
Comme Azure Stream Analytics peut lire plusieurs fois les entrées ou les étapes d’un travail, vous pouvez ajouter des instructions SELECT INTO supplémentaires. Cela permet de générer des données intermédiaires dans le stockage et de vérifier la justesse des données, tout comme les variables de surveillance le font lors du débogage d’un programme.
L’exemple de requête suivant dans un travail Azure Stream Analytics comporte une entrée de flux, deux entrées de données de référence et une sortie vers le stockage de tables Azure. La requête joint les données du Event Hub et deux objets blob de référence pour obtenir les informations de nom et de catégorie :
La tâche est en cours d’exécution, mais elle ne génère aucun événement en sortie. Sur la tuile de surveillance , illustrée ici, vous pouvez voir que l’entrée produit des données, mais vous ne savez pas quelle étape du JOIN a supprimé tous les événements.
Dans ce cas, vous pouvez ajouter quelques instructions supplémentaires SELECT INTO pour « enregistrer » les résultats intermédiaires JOIN et les données lues à partir de l’entrée.
Dans cet exemple, nous avons ajouté deux nouvelles « sorties temporaires ». Ils peuvent être n’importe quel évier que vous voulez. Ici, nous utilisons Stockage Azure comme exemple :
Vous pouvez ensuite réécrire la requête comme suit :
À présent, relancez le travail et laissez-le s’exécuter pendant quelques minutes. Ensuite, interrogez temp1 et temp2 utilisez Visual Studio Cloud Explorer pour produire les tableaux suivants :
tableau temp1
Tableau temp2
Comme vous pouvez le voir, temp1 et temp2 les deux ont des données, et la name colonne est correctement remplie dans temp2. Cependant, comme la sortie ne contient toujours pas de données, quelque chose ne va pas :
En échantillonnant les données, vous pouvez être presque certain que le problème vient du second JOIN. Vous pouvez télécharger les données de référence depuis le blob et y jeter un coup d’œil :
Comme vous pouvez le voir, le format du GUID dans ces données de référence est différent du format de la [from] colonne dans temp2. C’est pourquoi les données ne sont pas arrivées dans output1 comme prévu.
Corrigez le format des données, téléchargez-le sur le blob de référence, puis réessayez :
Cette fois, les données dans la sortie sont mises en forme et remplies comme prévu.
L’utilisation des ressources est élevée
Veillez à tirer parti de la parallélisation dans Azure Stream Analytics. Apprenez à mettre à l’échelle des travaux Stream Analytics avec parallélisation des requêtes en configurant des partitions d’entrée et en réglant la définition des requêtes Analytics.
Si l’utilisation des ressources est régulièrement supérieure à 80 %, le délai en filigrane augmente; tout comme le nombre d’événements retardés. Dans ce cas, vous pouvez d’augmenter les unités de streaming. Une utilisation intensive indique que la tâche atteint une limite proche de la quantité maximale de ressources allouées.
Obtenir de l’aide
Pour obtenir de l’aide supplémentaire, essayez notre page de questions Microsoft Q&A pour Azure Stream Analytics.