Mappage des conventions sémantiques OpenTelemetry vers les spans d'entrée de service

Cette traduction n'est pas à jour. Pour consulter la dernière version en anglais, cliquez ici

Présentation

Datadog utilise les spans d’entrée de service dans toute la plateforme pour des fonctionnalités comme les métriques de trace et l’APM Trace Explorer. Cette convention est propre à Datadog, mais peut être mappée à partir de l’attribut SpanKind dans OpenTelemetry en suivant le guide d’activation ci-dessous.

Prérequis

  • OTel Collector Contrib v0.100.0 ou version ultérieure
  • Datadog Agent v7.53.0 ou version ultérieure

Configuration

Activez l’option de configuration en fonction de votre chemin d’ingestion :

    La nouvelle logique d’identification des spans d’entrée de service peut être activée en définissant l’option de configuration traces::compute_top_level_by_span_kind sur true dans le Datadog exporter et le Datadog connector. Cette option de configuration doit être activée à la fois dans l’exporter et dans le connector si les deux composants sont utilisés.

    La nouvelle logique d’identification des spans d’entrée de service peut être activée en ajoutant "enable_otlp_compute_top_level_by_span_kind" à apm_config.features dans la configuration du Datadog Agent.

    Conventions prises en charge

    Les métriques de trace sont générées pour les spans d’entrée de service et les spans mesurés. Ces conventions de span sont propres à Datadog, les spans OpenTelemetry sont donc identifiés avec le mappage suivant :

    Convention OpenTelemetryConvention Datadog
    Span racineSpan d’entrée de service
    Span serveur (span.kind: server)Span d’entrée de service
    Span consommateur (span.kind: consumer)Span d’entrée de service
    Span client (span.kind: client)Span mesuré
    Span producteur (span.kind: producer)Span mesuré
    Span interne (span.kind: internal)Aucune métrique de trace générée

    Migration

    Cette nouvelle logique d’identification des spans d’entrée de service peut augmenter le nombre de spans générant des métriques de trace, ce qui peut affecter les monitors existants basés sur ces métriques de trace. Les utilisateurs qui n’ont que des spans internes verront une diminution des métriques de trace.

    Si vous avez des monitors existants basés sur des métriques de trace, vous pouvez les mettre à jour après la mise à niveau, car ce changement introduit plus de cohérence dans les métriques de trace. Si vous n’avez que des spans internes, mettez à jour votre instrumentation conformément au tableau ci-dessus pour recevoir des métriques de trace et des spans d’entrée de service.

    SpanKind est généralement défini lors de la création d’un span, mais peut également être mis à jour en utilisant le transform processor dans l’OpenTelemetry Collector pour contrôler le mappage ci-dessus. Par exemple, si des métriques de trace sont souhaitées pour un span interne, la configuration suivante transforme un span interne avec http.path: "/health" en un span client :

      transform:
    trace_statements:
      - context: span
        statements:
          - set(kind.string, "Client") where kind.string == "Internal" and attributes["http.path"] == "/health"

    Pour aller plus loin

    Documentation, liens et articles supplémentaires utiles:

    Métriques de trace OpenTelemetryDOCUMENTATION more more