Résoudre les problèmes liés aux sorties Azure Stream Analytics

Cet article décrit les problèmes courants liés aux connexions de sortie Azure Stream Analytics et comment les résoudre. Les problèmes abordés incluent les tâches qui ne génèrent aucune sortie, la sortie initiale retardée, la sortie qui prend du retard, les violations de clé dans Azure SQL Database et le comportement des nouvelles tentatives SQL. De nombreuses étapes de résolution des problèmes nécessitent que les journaux de ressources et autres journaux de diagnostic soient activés pour votre travail 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 tâche ne produit aucune sortie

  1. Vérifiez la connectivité aux sorties à l’aide du bouton Tester la connexion pour chaque sortie.

  2. Consultez Surveiller le travail Stream Analytics avec le Portail Azure sous l’onglet Surveiller. Comme les valeurs sont agrégées, les métriques sont différées de quelques minutes.

    • Si la valeur Événements d’entrée est supérieure à zéro, la tâche peut lire les données d’entrée. Si la valeur Événements d’entrée n’est pas supérieure à zéro, cela indique un problème dans les données d’entrée du job. Pour plus d’informations, consultez Résoudre les problèmes liés aux connexions d’entrée. Si votre travail a une entrée de données de référence, appliquez le fractionnement par nom logique lorsque vous examinez la métrique Événements d’entrée. S’il n’existe aucun événement d’entrée de vos données de référence uniquement, cela signifie probablement que cette source d’entrée n’a pas été configurée correctement pour extraire le jeu de données de référence approprié.
    • Si la valeur Erreurs de conversion de données est supérieure à zéro et est en augmentation, consultez Erreurs de données Azure Stream Analytics pour obtenir des informations détaillées sur les erreurs de conversion de données.
    • Si la valeur Erreurs d’exécution est supérieure à zéro, votre travail reçoit des données, mais génère des erreurs pendant le traitement de la requête. Pour trouver les erreurs, accédez aux journaux d’audit, puis filtrez sur l’état Échec.
    • Si la valeur Événements d’entrée est supérieure à zéro et que la valeur Événements de sortie est égale à zéro, l’une des instructions suivantes a l’état true :
      • Le traitement de la requête a abouti à un nombre nul d’événements de sortie.
      • Les événements ou les champs peuvent être formés de manière inappropriée et n’entraîner aucune sortie après le traitement des requêtes.
      • Le travail n’a pas pu envoyer (push) de données au récepteur de sortie pour des raisons d’authentification ou de connectivité.

    Les messages des journaux d’opérations donnent des détails supplémentaires, notamment sur le déroulé des événements, sauf lorsque la logique de requête filtre l’ensemble des événements. Si le traitement de plusieurs événements génère des erreurs, ces dernières sont regroupées toutes les 10 minutes.

La première sortie est retardée

Lorsqu’un travail de Stream Analytics démarre, les événements d’entrée sont lus. Toutefois, dans certaines circonstances la sortie peut être retardée.

Les valeurs de temps importantes dans les éléments de requête temporelle peuvent contribuer au retard de la sortie. Pour produire le résultat correct sur de longues fenêtres temporelles, la tâche de traitement en flux lit les données à partir de l’instant le plus récent possible afin de compléter la fenêtre temporelle. Les données peuvent dater de jusqu’à sept jours. Aucune sortie n’est produite tant que les événements d’entrée en attente ne sont pas lus. Ce problème peut apparaître lorsque le système met à niveau les travaux de diffusion en continu. Lorsqu’une mise à niveau a lieu, le travail redémarre. Ces mises à niveau sont généralement effectuées une fois tous les deux mois.

Faites preuve de discernement lors de la conception d’une requête Stream Analytics. Si vous utilisez une grande fenêtre de temps pour les éléments temporels dans la syntaxe de requête du travail, un retard de la première sortie peut survenir lorsque le travail démarre ou redémarre. Au-delà de plusieurs heures et jusqu’à sept jours sont considérées comme une grande fenêtre de temps.

Une façon d’atténuer ce type de retard de première sortie consiste à utiliser des techniques de parallélisation des requêtes, telles que le partitionnement des données. Sinon, vous pouvez ajouter davantage de Streaming Units pour améliorer le débit jusqu’à ce que le travail rattrape son retard. Pour plus d’informations, consultez Considérations relatives à la création de travaux Stream Analytics.

Ces facteurs affectent la rapidité d'exécution de la première sortie :

  • L’utilisation d’agrégats fenêtrés, tels qu’une clause GROUP BY de fenêtres de bascule, récurrentes et glissantes :

    • Pour les agrégats de fenêtres de bascule ou récurrentes, les résultats sont générés à la fin de la plage de temps de la fenêtre.
    • Pour une fenêtre glissante, les résultats sont générés lorsqu’un événement entre dans la fenêtre glissante ou en sort.
    • Si vous prévoyez d’utiliser une grande taille de fenêtre, par exemple supérieure à une heure, le mieux est de choisir une fenêtre récurrente ou glissante. Ces types de fenêtres vous permettent de voir la sortie plus fréquemment.

  • L’utilisation de jointures temporelles, telles que JOIN avec DATEDIFF :

    • génère des correspondances lorsque les deux côtés des événements correspondants surviennent.
    • Les données qui n’ont pas de correspondance telle que LEFT OUTER JOIN sont générées à la fin de la fenêtre DATEDIFF pour chaque événement sur le côté gauche.

  • L’utilisation de fonctions analytiques temporelles, telles que ISFIRST, LAST et LAG avec LIMIT DURATION :

    • Pour les fonctions analytiques, la sortie est générée pour chaque événement. Il n’y a pas de retard.

La sortie est en retard avec une latence croissante

Pendant le fonctionnement normal d’un travail, la sortie peut avoir des périodes de latence de plus en plus longues. Si la sortie prend un tel retard, vous pouvez identifier les causes racines en examinant les facteurs suivants :

  • si le récepteur en aval est limité
  • Si la source en amont est bridée
  • si la logique de traitement de la requête nécessite beaucoup de ressources système

Pour afficher les détails de sortie, sélectionnez le travail de diffusion en continu dans le portail Azure, puis sélectionnez Diagramme de travail. Pour chaque entrée, il existe une métrique de backlog d’événements pour chaque partition. Si la métrique continue à augmenter, cela indique que les ressources système sont limitées. L’augmentation peut être due à un bridage du flux de sortie ou à une utilisation élevée du processeur. Pour plus d’informations, consultez Débogage piloté par les données à l’aide du diagramme de travail.

Avertissement de violation de clé avec la sortie Azure SQL Database

Quand vous configurez une base de données Azure SQL comme sortie d’une tâche Stream Analytics, les enregistrements sont insérés en bloc dans la table de destination. En général, Azure Stream Analytics garantit une livraison au moins une fois vers le récepteur de sortie. Vous pouvez toujours obtenir une remise unique à une sortie SQL quand une contrainte unique est définie pour une table SQL.

Quand vous configurez des contraintes de clé unique sur la table SQL, Azure Stream Analytics supprime les enregistrements en double. Il fractionne les données en lots et insère récursivement ces lots jusqu’à ce qu’un seul enregistrement en double soit trouvé. Le processus de fractionnement et d’insertion ignore les doublons un par un. Pour une tâche de streaming comportant de nombreuses lignes dupliquées, le processus est inefficace et chronophage. Si vous voyez plusieurs messages d’avertissement de violation de clé dans votre journal d’activité pour l’heure précédente, il est probable que votre sortie SQL ralentit l’intégralité de la tâche.

Pour résoudre ce problème, configurez l’index qui provoque la violation de clé en activant l’option IGNORE_DUP_KEY. Cette option permet à SQL d’ignorer les valeurs dupliquées lors des insertions en bloc. Azure SQL Database produit simplement un message d’avertissement au lieu d’une erreur. Par conséquent, Azure Stream Analytics ne produit plus d’erreurs de violation de clé primaire.

Notez les observations suivantes lors de la configuration d’IGNORE_DUP_KEY pour plusieurs types d’index :

  • Vous ne pouvez pas définir IGNORE_DUP_KEY sur une clé primaire ni sur une contrainte unique qui utilise ALTER INDEX. Vous devez supprimer l’index et le recréer.
  • Vous pouvez définir IGNORE_DUP_KEY avec ALTER INDEX pour un index unique. Cette instance est différente d’une contrainte PRIMARY KEY/UNIQUE et est créée à l’aide d’une définition CREATE INDEX ou INDEX.
  • L’Option IGNORE_DUP_KEY ne s’applique pas aux index de stockage de colonnes, car vous ne pouvez pas leur imposer l’unicité.

Logique de nouvelle tentative de sortie pour Azure SQL Database

Lorsqu’un travail Stream Analytics avec sortie SQL reçoit le premier lot d’événements, les étapes suivantes se produisent :

  1. Le travail tente de se connecter à SQL.
  2. Le travail extrait le schéma de la table de destination.
  3. Le travail valide les noms de colonne et les types par rapport au schéma de la table de destination.
  4. La tâche prépare une table de données en mémoire à partir des enregistrements en sortie du lot.
  5. Le travail écrit la table de données dans SQL à l’aide de l’API BulkCopy.

Pendant ces étapes, la sortie SQL peut rencontrer les types d’erreurs suivants :

  • Les erreurs temporaires retentées avec une stratégie de nouvelle tentative de backoff exponentiel. L’intervalle minimal avant une nouvelle tentative dépend du code d’erreur individuel, mais les intervalles sont généralement inférieurs à 60 secondes. La limite supérieure peut être de cinq minutes au maximum.

    Les échecs de connexion et les problèmes de pare-feu sont retentés au moins cinq minutes après la tentative précédente jusqu’à leur réussite.

  • Les erreurs de données, telles que les erreurs de transtypage et les violations de contrainte de schéma, sont gérées à l’aide d’une stratégie de gestion des erreurs en sortie. Ces erreurs sont traitées en réessayant des lots de fractionnement binaire jusqu’à ce que l’enregistrement individuel à l’origine de l’erreur soit traité par saut ou nouvelle tentative. La violation de la contrainte d’unicité de la clé primaire est toujours gérée.

  • Des erreurs non temporaires peuvent se produire en cas de problèmes du service SQL ou de défaillances du code interne. Par exemple, lorsque des erreurs telles que (Code 1132) du pool élastique atteignent sa limite de stockage, les nouvelles tentatives ne résolvent pas l’erreur. Dans ces scénarios, le travail Stream Analytics se dégrade.

  • Les délais d’attente BulkCopy peuvent expirer pendant l’exécution de BulkCopy à l’étape 5. BulkCopy peut parfois faire l’expérience d’une expiration des délais d’attente pour les opérations. Le délai minimum configuré par défaut est de cinq minutes et il est doublé lorsqu’il est atteint consécutivement. Une fois que le délai d’attente est supérieur à 15 minutes, la taille maximale des lots indiquée dans BulkCopy est réduite de moitié jusqu’à ce qu’il reste 100 événements par lot.

    Important

    Pour les tâches ASA non injectées par le réseau, ne vous fiez en aucune façon à l’adresse IP source des connexions provenant d’ASA. Il peut s’agir d’IP publiques ou privées en fonction des opérations d’infrastructure de service qui se produisent de temps à autre.

Le nom des colonnes est en minuscules dans Azure Stream Analytics (1.0)

Avec le niveau de compatibilité d’origine (1.0), Azure Stream Analytics met le nom des colonnes en minuscules. Ce comportement a été résolu dans les niveaux de compatibilité ultérieurs. Pour conserver la casse, passez au niveau de compatibilité 1.1 ou ultérieur. Pour plus d’informations, consultez Niveau de compatibilité pour les travaux Azure Stream Analytics.

Obtenir de l’aide

Pour obtenir de l’aide supplémentaire, essayez notre page de questions Microsoft Q&A pour Azure Stream Analytics.

Étapes suivantes

  • Last updated on