Services déduits

Documentation > APM > Observabilité des services > Services déduits

Présentation

Datadog découvre automatiquement les dépendances d’un service instrumenté, telles que les bases de données, les files d’attente ou les API tierces, même si cette dépendance n’a pas été directement instrumentée. En analysant les requêtes sortantes de vos services instrumentés, Datadog déduit la présence de ces dépendances et collecte les métriques de performance associées.

Carte des dépendances de la page de service

Explorez les services déduits dans le Catalogue en filtrant les entrées par type d’entité, comme base de données, file d’attente ou API tierce. Chaque page de service est adaptée au type de service que vous étudiez. Par exemple, les pages de service de base de données affichent des informations spécifiques aux bases de données et incluent des données de surveillance de base de données si vous utilisez Database Monitoring.

Configurer les services déduits

À partir de la version 7.60.0 du Datadog Agent, aucune configuration manuelle n’est nécessaire pour voir les services déduits. Les configurations requises — apm_config.compute_stats_by_span_kind et apm_config.peer_tags_aggregation — sont activées par défaut.

Pour les versions 7.55.1 à 7.59.1 du Datadog Agent, ajoutez ce qui suit à votre fichier de configuration datadog.yaml :

datadog.yaml

apm_config:
  compute_stats_by_span_kind: true
  peer_tags_aggregation: true

Vous pouvez aussi définir ces variables d’environnement dans la configuration de votre Datadog Agent :

DD_APM_COMPUTE_STATS_BY_SPAN_KIND=true 
DD_APM_PEER_TAGS_AGGREGATION=true

Si vous utilisez Helm, incluez ces variables d’environnement dans votre values.yaml fichier.

Pour les versions 7.50.3 à 7.54.1 du Datadog Agent, ajoutez ce qui suit à votre fichier de configuration datadog.yaml :

datadog.yaml

apm_config:
  compute_stats_by_span_kind: true
  peer_tags_aggregation: true
  peer_tags: ["_dd.base_service","amqp.destination","amqp.exchange","amqp.queue","aws.queue.name","aws.s3.bucket","bucketname","cassandra.keyspace","db.cassandra.contact.points","db.couchbase.seed.nodes","db.hostname","db.instance","db.name","db.namespace","db.system","grpc.host","hostname","http.host","http.server_name","messaging.destination","messaging.destination.name","messaging.kafka.bootstrap.servers","messaging.rabbitmq.exchange","messaging.system","mongodb.db","msmq.queue.path","net.peer.name","network.destination.name","peer.hostname","peer.service","queuename","rpc.service","rpc.system","server.address","streamname","tablename","topicname"]

Vous pouvez aussi définir ces variables d’environnement dans la configuration de votre Datadog Agent :

DD_APM_COMPUTE_STATS_BY_SPAN_KIND=true 
DD_APM_PEER_TAGS_AGGREGATION=true
DD_APM_PEER_TAGS='["_dd.base_service","amqp.destination","amqp.exchange","amqp.queue","aws.queue.name","aws.s3.bucket","bucketname","cassandra.keyspace","db.cassandra.contact.points","db.couchbase.seed.nodes","db.hostname","db.instance","db.name","db.namespace","db.system","grpc.host","hostname","http.host","http.server_name","messaging.destination","messaging.destination.name","messaging.kafka.bootstrap.servers","messaging.rabbitmq.exchange","messaging.system","mongodb.db","msmq.queue.path","net.peer.name","network.destination.name","peer.hostname","peer.service","queuename","rpc.service","rpc.system","server.address","streamname","tablename","topicname"]'

Si vous utilisez Helm, incluez ces variables d’environnement dans votre values.yaml fichier.

Pour le collecteur OpenTelemetry, la version minimale recommandée est opentelemetry-collector-contrib v0.95.0 ou ultérieure. Dans ce cas, mettez à jour cette configuration :

connectors:
  datadog/connector:
    traces:
      compute_stats_by_span_kind: true
      peer_tags_aggregation: true
      peer_tags: ["_dd.base_service","amqp.destination","amqp.exchange","amqp.queue","aws.queue.name","aws.s3.bucket","bucketname","db.cassandra.contact.points","db.couchbase.seed.nodes","db.hostname","db.instance","db.name","db.namespace","db.system","grpc.host","hostname","http.host","http.server_name","messaging.destination","messaging.destination.name","messaging.kafka.bootstrap.servers","messaging.rabbitmq.exchange","messaging.system","mongodb.db","msmq.queue.path","net.peer.name","network.destination.name","peer.hostname","peer.service","queuename","rpc.service","rpc.system","server.address","streamname","tablename","topicname"]

Si votre version de Collector est inférieure à v0.95.0, mettez à jour la configuration suivante de Collector :

exporters:
  datadog:
    traces:
      compute_stats_by_span_kind: true
      peer_tags_aggregation: true
      peer_tags: ["_dd.base_service","amqp.destination","amqp.exchange","amqp.queue","aws.queue.name","aws.s3.bucket","bucketname","db.cassandra.contact.points","db.couchbase.seed.nodes","db.hostname","db.instance","db.name","db.namespace","db.system","grpc.host","hostname","http.host","http.server_name","messaging.destination","messaging.destination.name","messaging.kafka.bootstrap.servers","messaging.rabbitmq.exchange","messaging.system","mongodb.db","msmq.queue.path","net.peer.name","network.destination.name","peer.hostname","peer.service","queuename","rpc.service","rpc.system","server.address","streamname","tablename","topicname"]   

Exemple : collector.yaml.

Nommage des entités déduites

Pour déterminer les noms et les types des dépendances de service déduites, Datadog utilise des attributs de span standard et les mappe aux attributs peer.*. Par exemple, les API externes déduites utilisent le schéma de nommage par défaut net.peer.name comme api.stripe.com, api.twilio.com et us6.api.mailchimp.com. Les bases de données déduites utilisent le schéma de nommage par défaut db.instance. Vous pouvez renommer les entités déduites en créant des règles de renommage.

Tags pairs

Tag pair	Attributs sources
`peer.aws.dynamodb.table`	`tablename`
`peer.aws.kinesis.stream`	`streamname`
`peer.aws.s3.bucket`	`bucketname`, `aws.s3.bucket`
`peer.aws.sqs.queue`	`queuename`
`peer.cassandra.contact.points`	`db.cassandra.contact.points`
`peer.couchbase.seed.nodes`	`db.couchbase.seed.nodes`
`peer.db.name`	`db.name`, `mongodb.db`, `db.instance`, `cassandra.keyspace`, `db.namespace`
`peer.db.system`	`db.system`
`peer.hostname`	`peer.hostname`, `hostname`, `net.peer.name`, `db.hostname`, `network.destination.name`, `grpc.host`, `http.host`, `server.address`, `http.server_name`
`peer.kafka.bootstrap.servers`	`messaging.kafka.bootstrap.servers`
`peer.messaging.destination`	`topicname`, `messaging.destination`, `messaging.destination.name`, `messaging.rabbitmq.exchange`, `amqp.destination`, `amqp.queue`, `amqp.exchange`, `msmq.queue.path`, `aws.queue.name`
`peer.messaging.system`	`messaging.system`
`peer.rpc.service`	`rpc.service`
`peer.rpc.system`	`rpc.system`
`peer.service`	`peer.service`

Remarque : Les valeurs d’attribut pair qui correspondent aux formats d’adresse IP sont modifiées et expurgées avec blocked-ip-address pour éviter le bruit inutile et le marquage de métriques avec des dimensions à haute cardinalité. Par conséquent, vous pouvez rencontrer certains services blocked-ip-address apparaissant comme des dépendances en aval de vos services instrumentés.

Priorité des tags pairs

Pour attribuer un nom aux entités inférées, Datadog utilise un ordre de priorité spécifique entre les tags pairs, notamment lorsque les entités sont définies par une combinaison de plusieurs tags.

Type d’entité	Ordre de priorité
Base de données	`peer.db.name` > `peer.aws.s3.bucket` (Pour AWS S3) / `peer.aws.dynamodb.table` (Pour AWS DynamoDB) / `peer.cassandra.contact.points` (Pour Cassandra) / `peer.couchbase.seed.nodes` (Pour Couchbase) > `peer.hostname` > `peer.db.system`
File d’attente	`peer.messaging.destination` > `peer.kafka.bootstrap.servers` (pour Kafka) / `peer.aws.sqs.queue` (pour AWS SQS) / `peer.aws.kinesis.stream` (pour AWS Kinesis) > `peer.messaging.system`
Service déduit	`peer.service` > `peer.rpc.service` > `peer.hostname`

Si le tag de priorité la plus élevée, tel que peer.db.name, n’est pas capturé dans le cadre de l’instrumentation, Datadog utilise le tag de deuxième priorité la plus élevée, comme peer.hostname, et continue dans cet ordre.

Remarque : Datadog ne définit jamais le peer.service pour les bases de données et les files d’attente déduites. peer.service est l’attribut pair de priorité la plus élevée. S’il est défini, il prévaut sur tous les autres attributs.

Migrer vers le nommage de service global par défaut

Avec les services déduits, les dépendances de service sont automatiquement détectées à partir des attributs de span existants. Par conséquent, il n’est pas nécessaire de modifier les noms de service (à l’aide du tag service) pour identifier ces dépendances.

Activez DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED pour vous assurer qu’aucune intégration Datadog ne définit des noms de service différents du nom de service global par défaut. Cela améliore également la manière dont les connexions de service à service et les services déduits sont représentés dans les visualisations Datadog, dans tous les langages SDK et intégrations pris en charge.

L'activation de cette option peut avoir un impact sur les métriques APM existantes, les métriques de span personnalisées, l'analyse des traces, les filtres de rétention, les analyses de données sensibles, les monitors, les dashboards ou les notebooks qui font référence aux anciens noms de service. Mettez à jour ces ressources pour utiliser le tag de service global par défaut (service:<DD_SERVICE>).

Pour savoir comment supprimer les remplacements de service et migrer vers les services inférés, consultez le guide sur les remplacements de service.