Questions courantes sur l’ingestion d’Azure Data Explorer

Les mémoires tampons du gestionnaire de traitement par lots et les données d’entrée basées sur les paramètres d’ingestion dans la stratégie de traitement par lots d’ingestion. La stratégie de traitement par lots d’ingestion définit des limites de lot en fonction de trois facteurs de limitation, selon la première atteinte : le temps écoulé depuis la création du lot, le nombre cumulé d’éléments (objets blob) ou la taille totale du lot. Les paramètres de traitement par lots par défaut sont de 5 minutes / 1 Go / 1 000 objets blob, ce qui signifie qu’il y aura au moins un délai de 5 minutes lors de la mise en file d’attente d’un exemple de données pour l’ingestion.

L’ingestion mise en file d’attente est optimisée pour un débit d’ingestion élevé et est le type d’ingestion préféré et le plus performant. En revanche, l’ingestion de streaming est optimisée pour une faible latence d’ingestion. En savoir plus sur l’ingestion en file d’attente et sur la diffusion en continu.

Si les paramètres par défaut de la stratégie de traitement par lot d’ingestion ne correspondent pas à vos besoins, vous pouvez essayer de réduire la stratégie timede traitement par lots. Consultez Optimiser pour le débit. Vous devez également mettre à jour les paramètres lorsque vous effectuez un scale-up de l’ingestion. Lorsque vous modifiez les paramètres de stratégie de traitement par lots, il peut prendre jusqu’à 5 minutes.

La latence d’ingestion peut provenir des paramètres de stratégie de traitement par lot d’ingestion ou d’une build de backlog de données. Pour résoudre ce problème, ajustez les paramètres de stratégie de traitement par lots. Les latences qui font partie du processus d’ingestion peuvent être surveillées.

Pour afficher les métriques de latence d’ingestion mises en file d’attente, consultez la surveillance de la latence d’ingestion. Les métriques et Discovery Latency affichent les latences Stage Latency dans le processus d’ingestion et indiquent s’il existe de longues latences.

Vous pouvez en savoir plus sur les latences et ajuster les paramètres dans la stratégie de traitement par lots pour résoudre les problèmes qui provoquent des latences telles que les backlogs de données, le traitement par lot inefficace, le traitement par lot de grandes quantités de données non compressées ou l’ingestion de très petites quantités de données.

La taille des données de stratégie de traitement par lots est définie pour les données non compressées. Lors de l’ingestion de données compressées, la taille des données non compressées est calculée à partir des paramètres de traitement par lots d’ingestion, des métadonnées de fichiers ZIP ou du facteur sur la taille de fichier compressée.

Vous pouvez surveiller l’ingestion à l’aide de métriques, et en configurant et en utilisant des journaux de diagnostic d’ingestion détaillés pour une surveillance détaillée au niveau de la table, en affichant des codes d’erreur d’ingestion détaillés, et ainsi de suite. Vous pouvez sélectionner des métriques spécifiques à suivre, choisir comment agréger vos résultats et créer des graphiques de métriques à afficher sur votre tableau de bord. En savoir plus sur les métriques de streaming et sur la surveillance de l’ingestion en file d’attente.

Vous pouvez utiliser Azure Monitor Insights du portail pour vous aider à comprendre comment Azure Data Explorer fonctionne et comment il est utilisé. La vue Insight est basée sur les métriques et les journaux de diagnostic qui peuvent être diffusés en continu vers un espace de travail Log Analytics. Utilisez la commande .dup-next-ingest pour dupliquer l’ingestion suivante dans un conteneur de stockage et passer en revue les détails et les métadonnées de l’ingestion.

Le processus d’ingestion complet peut être supervisé à l’aide de métriques d’ingestion et de journaux de diagnostic. Les échecs d’ingestion peuvent être surveillés à l’aide de la IngestionResult métrique ou du journal de FailedIngestion diagnostic. La .show ingestion failures commande affiche les échecs d’ingestion associés aux commandes de gestion de l’ingestion des données et n’est pas recommandé pour la surveillance des erreurs. La .dup-next-failed-ingest commande fournit des informations sur l’ingestion ayant échoué suivante en chargeant des fichiers d’ingestion et des métadonnées dans un conteneur de stockage. Cela peut être utile pour vérifier un flux d’ingestion, mais n’est pas conseillé pour une surveillance stable.

Les métriques qui incluent l’état de la RetryAttemptsExceeded métrique plusieurs fois indiquent que l’ingestion a dépassé la limite de tentative de nouvelle tentative ou la limite d’intervalle de temps après une erreur temporaire récurrente. Si cette erreur apparaît également dans le journal des diagnostics avec le code General_RetryAttemptsExceeded d’erreur et les détails « Échec de l’accès au stockage et obtenir des informations pour l’objet blob », cela indique un problème d’accès au stockage à charge élevée. Pendant l’ingestion Event Grid, Azure Data Explorer demande des détails d’objet blob à partir du compte de stockage. Lorsque la charge est trop élevée sur un compte de stockage, l’accès au stockage peut échouer et les informations nécessaires à l’ingestion ne peuvent pas être récupérées. Si des tentatives réussissent la quantité maximale de nouvelles tentatives définies, Azure Data Explorer cesse d’essayer d’ingérer l’objet blob ayant échoué. Pour éviter un problème de chargement, utilisez un compte de stockage Premium ou divisez les données ingérées sur davantage de comptes de stockage. Pour découvrir les erreurs associées, consultez les FailedIngestion journaux de diagnostic pour les codes d’erreur et les chemins d’accès des objets blob ayant échoué.

Pour ingérer efficacement de grandes quantités de données historiques, utilisez LightIngest. Pour plus d’informations, consultez l’ingestion des données historiques. Pour améliorer les performances de nombreux petits fichiers, ajustez la stratégie de traitement par lots, modifiez les conditions de traitement par lots et corrigez les latences. Pour améliorer les performances d’ingestion lors de l’ingestion de fichiers de données extrêmement volumineux, utilisez Azure Data Factory (ADF), un service d’intégration de données basé sur le cloud.

Les données mal formées, nonparsables, trop volumineuses ou non conformes au schéma, peuvent ne pas être ingérées correctement. Pour plus d’informations, consultez Ingestion de données non valides.

Lors de l’ingestion via le SDK, vous pouvez utiliser les paramètres de stratégie de traitement par lots d’ingestion pour améliorer les performances. Essayez de réduire de façon incrémentielle la taille des données ingérées dans la stratégie de traitement par lots de la table ou de la base de données vers 250 Mo. Vérifiez s’il y a une amélioration.

Les utilisateurs du récepteur Kafka doivent paramétrer le connecteur pour qu’il fonctionne avec la stratégie de traitement par lots d’ingestion en réglant le temps de traitement par lot, la taille et le numéro d’élément.