Didacticiel : Remplacer des champs personnalisés dans l’espace de travail Log Analytics par des colonnes personnalisées basées sur KQL
Les champs personnalisés sont une fonctionnalité d’Azure Monitor qui vous permet d’extraire dans une colonne distincte les données d’une autre colonne de texte de la même table. La création de champs personnalisés sera désactivée à compter du 31 mars 2023. La fonctionnalité des champs personnalisés sera déconseillée et les champs personnalisés existants cesseront de fonctionner le 31 mars 2026.
L’utilisation de transformations au moment de l’ingestion basées sur DCR présente plusieurs avantages pour obtenir le même résultat :
- Vous pouvez appliquer un ensemble complet de fonctions de chaîne pour mettre en forme vos colonnes personnalisées.
- Vous pouvez appliquer plusieurs opérations aux mêmes données. Par exemple, extrayez une partie d’une valeur dans une colonne distincte et supprimez la colonne d’origine.
- Vous pouvez utiliser des transformations au moment de l’ingestion dans vos modèles ARM pour déployer des colonnes personnalisées à grande échelle.
Avec l’introduction des règles de collecte de données (DCR), les transformations basées sur KQL sont la méthode standard de personnalisation des tables qui remplace les champs personnalisés hérités.
Dans ce tutoriel, vous allez apprendre à :
- Rechercher les champs personnalisés qui nécessitent un remplacement
- Comprendre le contenu des champs personnalisés
- Configurer la transformation au moment de l’ingestion pour qu’elle remplace les champs personnalisés dans la table
Prérequis
- Espace de travail Log Analytics avec une table contenant des champs personnalisés
- Privilège de compte suffisant pour créer et modifier des règles de collecte de données (DCR)
Rechercher les champs personnalisés pour le remplacement
Commencez par localiser les champs personnalisés à remplacer. Si vous connaissez déjà les champs personnalisés que vous envisagez de remplacer, passez à l’étape suivante.
Accédez à l’espace de travail Log Analytics où se trouve la table avec des champs personnalisés.
Dans le menu latéral, sélectionnez Tables. Sélectionnez Gérer la table dans le menu contextuel de la table.
Notez si des règles de collecte de données (DCR) sont associées à une table donnée.
- Si des règles de collecte de données sont présentes dans la section correspondante, cela signifie que tous les champs personnalisés préexistants ont été soit déjà implémentés dans ces DCR, soit abandonnés lors de la création de ces DCR. Dans l’étape suivante de ce didacticiel, vous allez examiner le contenu des champs personnalisés et déterminer si d’autres mises à jour des DCR sont nécessaires.
- Si aucune règle de collecte de données n’est associée à la table, toutes les colonnes de la table donnée dont le nom se termine par « _CF » sont des champs personnalisés susceptibles d’être remplacés.
Fermez la boîte de dialogue des propriétés du tableau et sélectionnez Modifier le schéma dans le menu contextuel du tableau. Faites défiler jusqu’au bas de la page où les colonnes personnalisées sont répertoriées. Ces colonnes se terminent par _CF.
Notez les noms de ces colonnes, car vous devrez déterminer leur contenu à l’étape suivante.
Comprendre le contenu des champs personnalisés
Étant donné qu’il n’existe aucun moyen d’examiner directement la définition de champ personnalisé, vous devez interroger la table pour déterminer la formule de champ personnalisé.
Sélectionnez Journaux dans le menu latéral et exécutez une requête pour obtenir un exemple de données à partir de la table.
Recherchez les colonnes notées à l’étape précédente et examinez leur contenu.
- Si la colonne n’est pas vide et que des DCR sont associées à la table, la logique de champ personnalisé a déjà été implémentée avec la transformation. Aucune action n'est requise
- Si la colonne est vide (ou n’apparaît pas dans les résultats de la requête) et que des DCR sont associées à la table, la logique de champ personnalisé n’a pas été implémentée avec la DCR. Ajoutez une transformation au flux de données dans la DCR existante.
- Si la colonne n’est pas vide et qu’aucune DCR n’est associée à la table, la logique de champ personnalisé doit être implémentée en tant que transformation dans la DCR de l’espace de travail.
Examinez le contenu du champ personnalisé et déterminez la logique de calcul. Les champs personnalisés calculent généralement les sous-chaînes d’autres colonnes dans la même table. Déterminez la colonne d’où proviennent les données et la partie de la chaîne qu’elles extraient.
Création de transformation
Vous êtes maintenant prêt à créer l’extrait de code KQL requis et à l’ajouter à une DCR. Cette logique est appliquée à chaque enregistrement à mesure qu’il est ingéré dans l’espace de travail.
Modifiez la requête de la table à l’aide de KQL pour qu’elle réplique la logique de champ personnalisé. Si vous devez remplacer plusieurs champs personnalisés, vous pouvez combiner leur logique de calcul en une seule instruction.
- Utilisez l’opérateur parse pour une recherche basée sur des modèles d’une sous-chaîne au sein d’une chaîne.
- Utilisez la fonction extract() pour la recherche de sous-chaîne basée sur regex.
- Les fonctions de chaîne comme split(), substring() et bien d’autres peuvent également être utiles.
Déterminez où votre nouvelle définition KQL de la colonne personnalisée doit être placée.
- Pour les journaux collectés à l’aide d’Agent Azure Monitor (AMA),modifiez la DCR qui collecte les données pour la table, en ajoutant une transformation. Pour voir un exemple, consultez Exemples. La requête de transformation est définie dans l’élément
transformKql. - Pour les journaux de ressources collectés avec les paramètres de diagnostic, ajoutez la transformation à la DCR par défaut de l’espace de travail. La table doit prendre en charge les transformations.
- Pour les journaux collectés à l’aide d’Agent Azure Monitor (AMA),modifiez la DCR qui collecte les données pour la table, en ajoutant une transformation. Pour voir un exemple, consultez Exemples. La requête de transformation est définie dans l’élément
Forum Aux Questions
Comment faire migrer des champs personnalisés pour un journal texte collecté avec l’agent Log Analytics (MMA) hérité ?
Pensez à migrer vers l’agent Azure Monitor (AMA). L’agent Log Analytics ne sera bientôt plus pris en charge. Vous devriez migrer vers l’agent Azure Monitor (AMA). Les journaux de texte collectés avec AMA utilisent une logique d’analyse des journaux définie sous la forme de transformations KQL dès le début. Les champs personnalisés ne sont pas obligatoires et ne sont pas pris en charge dans les journaux texte collectés par l’agent Azure Monitor.
La migration de champs personnalisés vers KQL est-elle obligatoire ?
Non, vous devez migrer vos champs personnalisés uniquement si vous souhaitez que vos colonnes personnalisées continuent d’être remplies. Si vous ne migrez pas vos champs personnalisés, les colonnes correspondantes cesseront d’être remplies une fois la prise en charge des champs personnalisés terminée. Les données qui ont déjà été traitées et stockées dans la table ne sont pas affectées et restent utilisables.
Vais-je perdre mes données existantes dans les colonnes correspondantes si je ne migre pas mes champs personnalisés à temps ?
Non, les champs personnalisés sont calculés au moment de l’ingestion des données. La suppression de la définition de champ ou le fait de ne pas les migrer à temps n’affecte pas les données précédemment ingérées.