Partager via

Connexion de données Event Grid

  • Article

L’ingestion Event Grid est un pipeline qui écoute le stockage Azure et met à jour Azure Data Explorer pour extraire des informations quand des événements associés à des abonnements se produisent. Azure Data Explorer offre une ingestion continue depuis Stockage Azure (Stockage Blob et ADLSv2) avec un abonnement Azure Event Grid pour des notifications d’objet blob créé ou renommé, et le streaming de ces notifications vers Azure Data Explorer via un hub d’événements Azure.

Le pipeline d’ingestion Event Grid passe par plusieurs étapes. Vous créez une table cible dans Azure Data Explorer dans laquelle les données d’un format particulier sont ingérées. Vous créez ensuite une connexion de données Event Grid dans Azure Data Explorer. La connexion de données Event Grid doit connaître les informations de routage des événements, telles que la table à laquelle envoyer les données et le mappage de table. Vous spécifiez également les propriétés d’ingestion, qui décrivent les données à ingérer, la table cible et le mappage. Vous pouvez générer des exemples de données et charger des objets blob ou renommer des objets blob pour tester votre connexion. Supprimez des objets blob après ingestion.

L’ingestion Event Grid peut être managée via le portail Azure, à l’aide de l’Assistant Ingestion, programmatiquement avec du code C# ou Python, ou avec un modèle Azure Resource Manager.

Pour obtenir des informations générales sur l’ingestion de données dans Azure Data Explorer, consultez Vue d’ensemble de l’ingestion des données dans Azure Data Explorer.

Mécanismes d’authentification de connexion de données Event Grid

  • Connexion de données basée sur l’identité managée (recommandée) : l’utilisation d’une connexion de données basée sur une identité managée est la méthode la plus sécurisée pour se connecter aux sources de données. Elle offre un contrôle total sur la possibilité d’extraire des données à partir d’une source de données. La configuration d’une connexion de données Event Grid avec une identité managée nécessite les étapes suivantes :

    1. Ajouter une identité managée à votre cluster.
    2. Accorder des autorisations à l’identité managée sur la source de données. Pour extraire les données du Stockage Azure, l’identité managée doit avoir au moins les autorisations Lecteur des données Blob du stockage sur le compte Stockage Azure.
    3. Octroyez des autorisations à l’identité managée sur l’Event Hub. Pour extraire les notifications de blob de l’Event Hub, l’identité managée doit avoir les autorisations Récepteur des données Azure Event Hubs sur Azure Event Hubs.
    4. Définissez une stratégie d’identité managée sur les bases de données cibles.
    5. Créez une connexion de données à l’aide d’une authentification par identité managée pour extraire les données.

    Attention

    • Si les autorisations d’identité managée sont supprimées de la source de données, la connexion de données ne fonctionnera plus et ne pourra plus extraire de données de la source de données.
    • Si l’authentification locale est désactivée sur un espace de noms Event Hubs existant où les notifications de blob sont envoyées en streaming, vous devez utiliser une authentification par identité managée pour la connexion de données et configurer correctement les ressources. Pour plus d’informations, consultez Problèmes Event Grid connus.

  • Connexion de données basée sur des clés : si une authentification par identité managée n’est pas spécifiée pour la connexion de données, la connexion est automatiquement définie par défaut sur l’authentification basée sur des clés. Les connexions basées sur des clés extraient des données à l’aide d’une chaîne de connexion de ressource, telle que la chaîne de connexion Azure Event Hubs. Azure Data Explorer obtient la chaîne de connexion de ressource pour la ressource spécifiée et l’enregistre de façon sécurisée. La chaîne de connexion est ensuite utilisée pour extraire des données de la source de données.

    Attention

    Si la clé fait l’objet d’une rotation, la connexion de données ne fonctionnera plus et ne pourra plus extraire les données de la source de données. Pour résoudre le problème, mettez à jour ou recréez la connexion de données.

Format de données

  • Examinez les formats pris en charge.
  • Examinez les compressions prises en charge.

    • La taille des données non compressées d’origine doit faire partie des métadonnées d’objets blob, sinon Azure Data Explorer l’estime. La limite de taille décompressée d’ingestion par fichier est de 6 Go.

      Remarque

      L’abonnement aux notifications Event Grid peut être défini sur des comptes de stockage Azure pour BlobStorage, StorageV2 ou BlobStorage.

Propriétés d’ingestion

Vous pouvez spécifier les propriétés d’ingestion de l’ingestion d’objets blob via les métadonnées d’objet blob. Vous pouvez définir les propriétés suivantes :

Propriété Description
rawSizeBytes Taille des données brutes (non compressées). Pour Avro/ORC/Parquet, il s’agit de la taille avant l’application de la compression spécifique au format. Indiquez la taille des données d’origine en affectant à cette propriété la taille des données non compressées en octets.
kustoDatabase Nom de la base de données cible, respectant la casse. Par défaut, les données sont ingérées dans la base de données cible associée à la connexion de données. Utilisez cette propriété pour remplacer la base de données par défaut et envoyer les données à une autre base de données. Pour ce faire, vous devez d’abord configurer la connexion en tant que connexion à plusieurs bases de données.
kustoTable Nom de la table cible existante, respectant la casse. Remplace le paramètre Table défini dans le volet Data Connection.
kustoDataFormat Format de données. Remplace le paramètre Data format défini dans le volet Data Connection.
kustoIngestionMappingReference Nom du mappage d’ingestion existant à utiliser. Remplace le paramètre Column mapping défini dans le volet Data Connection.
kustoIgnoreFirstRecord Si la valeur définie est true, Kusto ignore la première ligne de l’objet blob. Utilisez dans les données au format tabulaire (CSV, TSV ou similaire) pour ignorer les en-têtes.
kustoExtentTags Chaîne représentant les balises qui seront attachées à l’étendue résultante.
kustoCreationTime Remplace Heure de création de l’extension pour l’objet blob, avec un format de chaîne ISO 8601. À utiliser pour le renvoi.

Routage d’événements

Quand vous créez une connexion de données à votre cluster, vous spécifiez le routage pour l’emplacement où les données ingérées doivent être envoyées. Le routage par défaut se fait vers la table cible spécifiée dans la chaîne de connexion associée à la base de données cible. Le routage par défaut de vos données est également appelé routage statique. Vous pouvez spécifier un autre routage pour vos données en utilisant les propriétés des données d’événement.

Router les données d’événement vers une autre base de données

Par défaut, le routage des données vers une autre base de données est désactivé. Pour envoyer les données vers une autre base de données, vous devez d’abord définir la connexion en tant que connexion à plusieurs bases de données. Vous pouvez le faire dans le portail Azure, C#, Python ou un modèle ARM. L’utilisateur, le groupe, le principal de service ou l’identité managée utilisé pour autoriser le routage de la base de données doit disposer au minimum du rôle Contributeur et d’autorisations d’écriture sur le cluster. Pour plus d’informations, consultez Créer une connexion de données Event Grid pour Azure Data Explorer.

Pour spécifier une autre base de données, définissez la propriété d’ingestion de la base de données.

Avertissement

Spécifier une autre base de données sans définir la connexion en tant que connexion de données à plusieurs bases de données entraîne l’échec de l’ingestion.

Router les données d’événement vers une autre table

Quand vous configurez une connexion de stockage Blob vers un cluster Azure Data Explorer, spécifiez les propriétés de la table cible :

  • Nom de la table
  • format de données
  • mapping

Vous pouvez également spécifier des propriétés de la table cible pour chaque objet blob, à l’aide des métadonnées d’objet blob. Les données sont routées dynamiquement, comme spécifié par les propriétés d’ingestion.

L’exemple ci-dessous vous montre comment définir les propriétés d’ingestion sur les métadonnées de l’objet blob avant de les charger. Les objets blob sont routés vers différentes tables.

En outre, vous pouvez spécifier la base de données cible. Une connexion de données Event Grid est créée dans le contexte d’une base de données spécifique. Par conséquent, cette base de données est le routage de la base de données par défaut de la connexion de données. Pour envoyer les données à une autre base de données, définissez la propriété d’ingestion « KustoDatabase » et définissez la connexion de données comme connexion de données à plusieurs bases de données. Le routage des données vers une autre base de données est désactivé par défaut (non autorisé). Définir une propriété d’ingestion de base de données différente de la base de données de la connexion de données sans autoriser le routage des données vers plusieurs bases de données (en définissant la connexion en tant que connexion de données avec plusieurs bases de données) entraîne l’échec de l’ingestion.

Pour plus d’informations, consultez Charger des objets blob.

var container = new BlobContainerClient("<storageAccountConnectionString>", "<containerName>");
await container.CreateIfNotExistsAsync();
var blob = container.GetBlobClient("<blobName>");
// Blob is dynamically routed to table `Events`, ingested using `EventsMapping` data mapping
await blob.SetMetadataAsync(
    new Dictionary<string, string>
    {
        { "rawSizeBytes", "4096" }, // the uncompressed size is 4096 bytes
        { "kustoTable", "Events" },
        { "kustoDataFormat", "json" },
        { "kustoIngestionMappingReference", "EventsMapping" },
        { "kustoDatabase", "AnotherDB" }
    }
);
await blob.UploadAsync(BinaryData.FromString(File.ReadAllText("<filePath>")));

Charger des objets blob

Vous pouvez créer un objet blob à partir d’un fichier local, définir des propriétés d’ingestion sur les métadonnées de l’objet blob, puis le charger. Pour obtenir des exemples, consultez Utiliser la connexion de données Event Grid.

Remarque

  • Nous vous recommandons vivement d’utiliser BlockBlob pour générer les données, car l’utilisation de AppendBlob peut entraîner un comportement inattendu.
  • L’utilisation du SDK de stockage Azure Data Lake Gen2 requiert l’utilisation de CreateFile pour charger les fichiers et de Flush à la fin avec le paramètre de fermeture défini sur true. Pour obtenir un exemple détaillé d’une bonne utilisation du SDK Data Lake Gen2, consultez Utiliser la connexion de données Event Grid.
  • Le déclenchement de l’ingestion après une opération CopyBlob n’est pas pris en charge pour les comptes de stockage qui ont la fonctionnalité d’espace de noms hiérarchique activée.
  • Quand le point de terminaison de hub d’événements n’accuse pas réception d’un événement, Azure Event Grid active un mécanisme de nouvelle tentative. Si cette nouvelle tentative de remise échoue, Event Grid peut délivrer les événements non remis à un compte de stockage en utilisant un processus de mise en file d’attente de lettres mortes. Pour plus d’informations, consultez la page Distribution et nouvelle tentative de distribution de messages avec Event Grid.

Renommer des objets blob

Lorsque vous utilisez ADLSv2, vous pouvez renommer un objet blob pour déclencher l’ingestion d’objets blob dans Azure Data Explorer. Par exemple, consultez Renommer des blobs.

Remarque

  • Le renommage de répertoire est possible dans ADLSv2, mais ne déclenche pas d’événements de renommage d’objets blob ni l’ingestion d’objets blob dans le répertoire. Pour ingérer les objets blob suite au renommage, renommez directement les objets blob souhaités.
  • Si vous avez défini des filtres pour suivre des sujets spécifiques pendant la création de la connexion de données ou lors de la création manuelle des ressources Event Grid, ces filtres sont appliqués sur le chemin du fichier de destination.

Supprimer des objets blob à l’aide du cycle de vie du stockage

Azure Data Explorer ne supprimera pas les objets blob après l’ingestion. Pour gérer la suppression des objets blob, utilisez le cycle de vie du stockage Blob Azure. Il est recommandé de conserver les objets blob pendant trois à cinq jours.

Problèmes connus liés à Event Grid

  • Si l’authentification locale est désactivée sur l’espace de noms Event Hubs qui contient l’Event Hub utilisé pour le streaming des notifications, effectuez les étapes suivantes pour vous assurer que les données circulent correctement du stockage vers l’Event Hub à l’aide d’identités managées :

    1. Attribuez une identité managée affectée par le système à la rubrique système Event Grid du compte de stockage. Pour plus d’informations, consultez Activer une identité managée pour les rubriques système.
    2. Accordez les autorisations d’expéditeur d’identité managée en lui attribuant le rôle Expéditeur de données Azure Event Hubs sur l’Event Hub. Pour plus d’informations, consultez Ajouter une identité à des rôles Azure sur des destinations.
    3. Assurez-vous que l’abonnement Event Grid utilise une identité managée pour la remise d’événements. Pour plus d’informations, consultez Créer des abonnements à des événements qui utilisent une identité.

    De plus, configurez la connexion de données Event Grid pour utiliser l’authentification par identité managée afin qu’Azure Data Explorer puisse recevoir des notifications de l’Event Hub.

  • Quand vous utilisez Azure Data Explorer pour exporter les fichiers utilisés pour l’ingestion Event Grid, notez que :

    • Les notifications Event Grid ne sont pas déclenchées si la chaîne de connexion fournie à la commande d’exportation ou à une table externe est une chaîne de connexion au format ADLS Gen2 (par exemple, abfss://filesystem@accountname.dfs.core.windows.net), mais que le compte de stockage n’est pas activé pour l’espace de noms hiérarchique.
    • Si le compte n’est pas activé pour l’espace de noms hiérarchique, la chaîne de connexion doit utiliser le format de stockage Blob (par exemple, https://accountname.blob.core.windows.net). L’exportation fonctionne comme prévu même si vous utilisez la chaîne de connexion ADLS Gen2, mais les notifications ne seront pas déclenchées et l’ingestion Event Grid ne fonctionnera pas.

Contenu connexe