Présentation

Mettez à jour la façon dont vos services apparaissent dans Datadog sans modifier la configuration du traceur ni redéployer le code. Les règles de remappage de service vous permettent de renommer, fusionner ou diviser des services, ou de créer de nouveaux services en vous basant sur des tags d’infrastructure depuis l’interface utilisateur Datadog Vous pouvez également créer des règles de remappage pour d’autres types d’entités, tels que les services déduits, les magasins de données et les files d’attente

Prérequis

Vous devez disposer de l’autorisation APM Service Remapping Write (apm_service_renaming_write) pour créer, modifier et supprimer des règles de remappage. Consultez Permissions pour plus de détails sur le contrôle d’accès basé sur les rôles de Datadog.

Exigences de version de traceur

Vous pouvez créer des règles de remappage de service uniquement pour les services instrumentés avec des versions de traceur prises en charge. Si un service transmet des données depuis une version de traceur plus ancienne, mettez à niveau le SDK avant de créer des règles de remappage pour ce service.

Remarque : cela s’applique uniquement aux services instrumentés. Il n’y a aucune exigence de version de traceur pour remapper les services déduits, les magasins de données ou les files d’attente.

Créer une règle de remappage de service

Étape 1 : Sélectionnez l’action de remappage et les entités à cibler

1. Dans Datadog, accédez à APM > Catalog > Manage > Service Remapping. Cliquez sur Add Service Rule pour remapper les services instrumentés. Pour remapper les services déduits, les magasins de données ou les files d’attente, sélectionnez l’onglet Inferred Entity Rules et cliquez sur Add Inferred Entity Rule.

   Alternativement, accédez à APM > Catalog et cliquez sur un service pour ouvrir le panneau latéral du service. À partir de là, cliquez sur Service Page > Service Remapping.

2. Choisissez une action de remappage à effectuer pour votre nouvelle règle de remappage de service.

   • Sélectionnez Remap services pour diviser une entité unique, renommer une entité, fusionner plusieurs entités ensemble ou renommer plusieurs entités.
   • Sélectionnez Correlate telemetry pour identifier un service basé sur un tag d’infrastructure.

3. Utilisez la barre de recherche pour sélectionner les entités que vous souhaitez remapper.

   • Vous pouvez sélectionner une ou plusieurs entités, mais elles doivent toutes être du même type (service, service déduit, magasin de données ou file d’attente). Sélectionnez les services en fonction de leur tag service ou peer.service, et non par leurs métadonnées de nom d’affichage.
   • Au fur et à mesure que vous sélectionnez des entités, une requête de span est créée en arrière-plan. Pour modifier la requête, sélectionnez Build Advanced Query.
   • Si vous corrélez un service avec des balises d’infrastructure, vous ne pouvez sélectionner que un seul service. Choisissez le ou les tags d’infrastructure sur lesquels corréler la télémétrie. Toute la télémétrie possédant le ou les mêmes tags d’infrastructure que le service choisi sera remappée vers un nom de service unifié

Étape 2 : Spécifiez le nouveau nom d’entité

Dans la zone de texte, saisissez un nom unique pour l’entité (ou les entités) sélectionnée(s). Alternativement, utilisez des valeurs de tag avec la syntaxe {{tagName}} pour remapper en fonction des tags d’une entité. Au fur et à mesure que vous tapez, un aperçu du ou des nouveaux noms de service apparaît.

1. Si les valeurs de tag suivent un modèle, appliquez une expression régulière pour extraire uniquement la partie que vous souhaitez dans le nom. Remarque : L’aperçu n’est pas une liste exhaustive. Si vous remappez un service basé sur un tag avec plusieurs valeurs, seules les valeurs avec le plus grand nombre de spans apparaissent dans l’aperçu.

Étape 3 : Nommez votre règle de remappage de service et vérifiez-la

1. Optionnellement, saisissez un nom descriptif pour la règle de remappage afin de pouvoir l’identifier ultérieurement.
2. Vérifiez et enregistrez votre règle de remappage. Après avoir enregistré votre règle, il peut s’écouler environ une minute avant qu’elle ne prenne effet.

Comportement des règles de remappage

Les règles de remappage de service fonctionnent en remplaçant le tag service pour remapper les services, ou le tag peer.service pour remapper les services déduits, les magasins de données et les files d’attente Les services sont remappés lors de l’ingestion, et toute configuration préexistante spécifiant un nom de service ne change pas lorsqu’une règle de remappage de service est créée Les règles de remappage de service prévalent sur toutes les autres configurations de nom de service

Les règles de remappage de service sont appliquées sur APM, Logs, Metrics, USM, DSM, DJM, DBM, Profiling, NPM, Live Processes, Live Containers, Kubernetes et Events

• Données historiques : Les modifications apportées par les règles de remappage de service affectent uniquement la télémétrie ingérée pendant qu’une règle est active, et les données passées ne sont pas mises à jour rétroactivement La suppression ou la modification d’une règle de remappage de service empêche son application aux nouvelles données, mais ne rétablit pas les noms sur les données précédemment ingérées
• Ordre des règles : Les règles de remappage de service sont appliquées dans l’ordre Les règles de remappage de service situées en haut de la liste sont appliquées en premier Un service n’est remappé que par la première règle de remappage de service qui le capture (plusieurs règles ne sont pas appliquées au même service)
• Expressions régulières : Les expressions régulières peuvent être utilisées pour définir de nouveaux noms de service, mais les quantificateurs gourmands ne sont pas autorisés à l’intérieur du groupe de capture.
• Remappeur de service de logs : Les règles de remappage de service s’appliquent avant les pipelines de logs Si le remappeur de service de logs et les règles de remappage de service sont tous deux appliqués à un service, les règles de remappage de service ont la priorité
• Dashboards et monitors : Les requêtes existantes qui font référence à d’anciens noms de service ne sont pas automatiquement mises à jour. Examinez et mettez-les à jour manuellement. Intégration et remplacements personnalisés : Si les remplacements d’intégration ou les remplacements personnalisés entrent dans le champ d’application d’une règle de remappage de service, ils sont également remappés Supprimer les remplacements d’intégration pour une expérience APM optimale.
• Hiérarchie de nommage des services : Les noms de service sont déterminés par la hiérarchie suivante, de la priorité la plus élevée à la plus basse :
  1. Règles de remappage de service
  2. Service défini dans le code (tracer.Start(WithService(xx)))
  3. Service défini dans la propriété système (-Ddd.service={})
  4. Service défini dans la variable d’environnement (DD_SERVICE)
  5. Service défini dans le fichier de configuration (application_monitoring.yaml)

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Connectez l’ensemble de vos données de service avec Service RemappingBLOG