Migrer de l’API Collecteur de données HTTP vers l’API Ingestion de journaux pour envoyer des données aux journaux Azure Monitor
L’API Ingestion des journaux Azure Monitor offre une plus grande puissance de traitement et une plus grande flexibilité dans l’ingestion de journaux et la gestion des tables que l’API Collecteur de données HTTP héritée. Cet article décrit les différences entre l’API Collecteur de données et l’API Ingestion de journaux, puis fournit des conseils et des bonnes pratiques pour la migration vers la nouvelle API Ingestion de journaux.
Notes
En tant que Microsoft MVP, Morten Waltorp Knudsen a contribué à cet article, puis a fourni des commentaires en retour sur les informations fournies dans cet article. Pour obtenir un exemple d’automatisation de l’installation et de l’utilisation continue de l’API Ingestion de journaux, veuillez consulter le module PowerShell AzLogDcrIngestPS de Morten Waltorp Knudsen à la disposition du public.
Avantages de l’API Ingestion de journaux
L’API Ingestion de journaux offre les avantages suivants par rapport à l’API Collecteur de données :
- Elle prend en charge les transformations, qui vous permettent de modifier les données avant qu’elles ne soient ingérées dans la table de destination, y compris le filtrage et la manipulation des données.
- Elle vous permet d’envoyer des données vers plusieurs destinations.
- Elle vous permet de gérer le schéma de table de destination, y compris les noms de colonnes, et de savoir si vous devez ajouter de nouvelles colonnes à la table de destination lorsque le schéma de données sources change.
Prérequis
La procédure de migration décrite dans cet article suppose que vous disposez des éléments suivants :
- Un espace de travail Log Analytics dans lequel vous avez au moins des droits de contributeur.
- Autorisations pour créer des règles de collecte de données dans l’espace de travail Log Analytics.
- Une application Microsoft Entra pour authentifier les appels d’API ou tout autre schéma d’authentification Resource Manager.
Autorisations requises
| Action | Autorisations requises |
|---|---|
| Créez un point de terminaison de collecte de données. | Microsoft.Insights/dataCollectionEndpoints/write autorisations fournies par le rôle intégré Contributeur de surveillance, par exemple. |
| Créez ou modifiez une règle de collecte de données. | Microsoft.Insights/DataCollectionRules/Write autorisations fournies par le rôle intégré Contributeur de surveillance, par exemple. |
| Convertissez une table qui utilise l’API collecteur de données en règles de collecte de données et l’API d’ingestion de journal. | Microsoft.OperationalInsights/workspaces/tables/migrate/action autorisations fournies par le rôle intégré contributeur Log Analytics, par exemple. |
| Créez des tables ou modifiez des schémas de table. | microsoft.operationalinsights/workspaces/tables/write autorisations fournies par le rôle intégré contributeur Log Analytics, par exemple. |
| Appelez l’API d’ingestion de journal. | Consultez Attribuer des autorisations à un DCR. |
Créer les ressources requises pour l’API Ingestion de journaux
L’API Ingestion de journaux vous oblige à créer deux nouveaux types de ressources, dont l’API collecteur de données HTTP n’a pas besoin :
- Points de terminaison de la collecte de données, à partir desquels les données que vous collectez sont ingérées dans le pipeline pour traitement.
- Règles de collecte de données, qui définissent les transformations de données et la table de destination d’ingestion des données.
Migrer des tables personnalisées existantes ou créer des tables
Si vous avez une table personnalisée existante à laquelle vous envoyez actuellement des données à l’aide de l’API Collecteur de données, vous pouvez :
Migrer la table pour continuer à ingérer des données dans la même table à l’aide de l’API Ingestion de journaux.
Conserver la table et les données existantes, puis configurer une nouvelle table dans laquelle vous ingérez des données à l’aide de l’API Ingestion de journaux. Vous pouvez alors supprimer l’ancienne table lorsque vous êtes prêt.
Nous vous recommandons cette option, en particulier si vous devez apporter des modifications à la table existante. Les modifications apportées aux types de données existants et les modifications de schémas multiples apportées aux tables personnalisées de l’API Collecteur de données existantes peuvent entraîner des erreurs.
Conseil
Pour identifier les tables qui utilisent l’API Collecteur de données, affichez les propriétés des tables. La propriété Type des tables qui utilisent l’API Collecteur de données est définie sur Table personnalisée (classique). Notez que les tables qui ingèrent des données à l’aide de l’agent Log Analytics hérité (MMA) ont également la propriété Type définie sur Table personnalisée (classique). Veillez à migrer de l’agent Log Analytics vers l’agent Azure Monitor avant de convertir des tables MMA. Sinon, vous cesserez d’ingérer des données dans les champs personnalisés de ces tables après la conversion de la table.
Ce tableau récapitule les éléments à prendre en compte pour chaque option :
| Migration de table | Implémentation côte à côte | |
|---|---|---|
| Attribution de noms aux tables et aux colonnes | Réutilisez le nom existant de la table. Options d’attribution de nom aux colonnes : - Utilisez de nouveaux noms de colonnes, puis définissez une transformation pour diriger les données entrantes vers la colonne nouvellement nommée. - Continuez à utiliser les anciens noms. |
Définissez librement le nouveau nom de table. Vous devez ajuster les intégrations, les tableaux de bord et les alertes avant de passer à la nouvelle table. |
| Procédure de migration | Migration de table unique. Vous ne pouvez pas restaurer une table migrée à sa version précédente. | Vous pouvez effectuer la migration progressivement, par table. |
| Postmigration | Vous pouvez continuer à ingérer des données à l’aide de l’API Collecteur de données HTTP avec des colonnes existantes, à l’exception des colonnes personnalisées. Ingérez des données dans de nouvelles colonnes à l’aide de l’API Ingestion des journaux uniquement. |
Les données de l’ancienne table sont disponibles jusqu’à la fin de la période de rétention. Lorsque vous configurez une nouvelle table ou apportez des modifications de schéma pour la première fois, l’apparition des modifications de données dans la table de destination peut prendre 10 à 15 minutes. |
Pour convertir une table qui utilise l’API Collecteur de données en règles de collecte de données et l’API Ingestion des journaux, émettez cet appel d’API sur la table :
POST https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{tableName}/migrate?api-version=2021-12-01-preview
Cet appel est idempotent et n’a donc aucun effet si la table a déjà été convertie.
L’appel d’API active toutes les fonctionnalités de journaux personnalisés basés sur DCR sur la table. L’API Collecteur de données continuera d’ingérer des données dans les colonnes existantes mais ne créera pas de nouvelles colonnes. Les champs personnalisés définis précédemment ne seront plus renseignés. Une manière de migrer une table existante autre que l’utilisation de règles de collecte de données, mais pas nécessairement l’API Ingestion de journaux, consiste à appliquer une transformation d’espace de travail à la table.
Important
- Les noms de colonnes doivent commencer par une lettre et peuvent comporter jusqu’à 45 caractères alphanumériques et traits de soulignement (
_). _ResourceId,id,_ResourceId,_SubscriptionId,TenantId,Type,UniqueIdetTitlesont des noms de colonnes réservés.- Les colonnes personnalisées que vous ajoutez à une table Azure doivent avoir le suffixe
_CF. - Si vous mettez à jour le schéma de table dans votre espace de travail Log Analytics, vous devez également mettre à jour la définition du flux d’entrée dans la règle de collecte de données pour ingérer des données dans des colonnes nouvelles ou modifiées.
Appeler l’API Ingestion de journaux
L’API Ingestion de journaux vous permet d’envoyer jusqu’à 1 Mo de données compressées ou décompressées par appel. Si vous devez envoyer plus de 1 Mo de données, vous pouvez envoyer plusieurs appels en parallèle. Il s’agit d’une modification par rapport à l’API Collecteur de données, qui vous permet d’envoyer jusqu’à 32 Mo de données par appel.
Si vous souhaitez en savoir plus sur l’appel de l’API Ingestion de journaux, veuillez consulter la rubrique Appel de l’API REST Ingestion de journaux.
Modifier les schémas de table et les règles de collecte de données en fonction des modifications apportées à l’objet de données sources
Alors que l’API Collecteur de données ajuste automatiquement le schéma de la table de destination lorsque le schéma de l’objet de données sources change, ce n’est pas le cas de l’API Ingestion de journaux. Cela vous permet de ne pas collecter de nouvelles données destinées à des colonnes que vous n’avez pas l’intention de créer.
Lorsque le schéma des données sources change, vous pouvez :
- Modifier les schémas de table de destination et les règles de collecte de données pour les aligner sur les modifications apportées au schéma de données sources.
- Définir une transformation dans la règle de collecte de données pour envoyer les nouvelles données dans des colonnes existantes de la table de destination.
- Laisser la table de destination et la règle de collecte de données inchangées. Dans ce cas, vous n’allez pas ingérer les nouvelles données.
Notes
Vous ne pouvez pas réutiliser un nom de colonne avec un type de données différent du type de données d’origine défini pour la colonne.
Étapes suivantes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour