Présentation

Les métriques d’évaluation des indicateurs de fonctionnalité vous permettent de mesurer la fréquence à laquelle chaque variante d’un indicateur de fonctionnalité est renvoyée par votre application côté serveur. Utilisez ces métriques pour suivre l’adoption des indicateurs de fonctionnalité au fil du temps, vérifier que les règles de ciblage fonctionnent comme prévu et représenter graphiquement les données d’évaluation des indicateurs de fonctionnalité sur des dashboards.

Prérequis

Avant de configurer les métriques d’évaluation des indicateurs de fonctionnalité, confirmez les points suivants :

• Les indicateurs de fonctionnalité côté serveur sont déjà configurés.
• Pour les déploiements basés sur l’Agent, Datadog Agent 7.32.0 ou une version ultérieure est en cours d’exécution et peut recevoir des métriques OTLP.
• Pour les déploiements sans serveur sans Agent, votre plateforme dispose d’un chemin de télémétrie sans serveur pris en charge configuré.
• Pour les environnements sans serveur Java, Node.js et Python, consultez Envoyer la télémétrie des indicateurs de fonctionnalité.
• Pour les configurations basées sur l’Agent qui utilisent l’ancien chemin d’activation, DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true est défini sur votre application.
• Votre traceur côté serveur respecte la version minimale pour la prise en charge des métriques d’évaluation des indicateurs de fonctionnalité :

La livraison de configuration Agentless et cette métrique utilisent des chemins indépendants. Un SDK sans agent peut émettre la métrique lorsque vous configurez le chemin OTLP requis via une configuration de télémétrie prise en charge, basée sur un Agent ou sans serveur.

Étape 1 : Configurez un récepteur OTLP

Les métriques d’évaluation des indicateurs de fonctionnalité sont émises via OpenTelemetry (OTLP). Pour les déploiements basés sur un agent, activez le récepteur OTLP du Datadog Agent, qui est désactivé par défaut. Pour les instructions de configuration, consultez Ingestion OTLP par le Datadog Agent. Pour les déploiements serverless sans Agent, utilisez le chemin OTLP ou les métriques personnalisées pris en charge par votre configuration de Serverless Monitoring.

Vous devez uniquement activer le protocole utilisé par votre application (gRPC sur le port 4317 ou HTTP sur le port 4318).

Étape 2 : Configurez votre application

Pour les combinaisons de traceur et de mode de livraison prises en charge, à l’exception de Java, définissez la variable d’environnement suivante en plus de la configuration des indicateurs de fonctionnalité côté serveur standard 1. Pour Java, DD_METRICS_OTEL_ENABLED n’a aucun effet ; consultez plutôt la section Java : Ajoutez les dépendances du SDK OpenTelemetry.

# Enable flag evaluation metrics
DD_METRICS_OTEL_ENABLED=true

Java : Ajoutez les dépendances du SDK OpenTelemetry

Le fournisseur Java enregistre feature_flag.evaluations via le SDK OpenTelemetry et l’exporte via OTLP, les dépendances opentelemetry-sdk-metrics et opentelemetry-exporter-otlp doivent donc figurer dans le classpath de votre application. Ajoutez-les avec vos dépendances d’indicateurs de fonctionnalité Java. Importez le BOM OpenTelemetry afin que l’API et le SDK OpenTelemetry restent sur la même version :

dependencies {
    implementation platform('io.opentelemetry:opentelemetry-bom:1.47.0')
    implementation 'io.opentelemetry:opentelemetry-sdk-metrics'
    implementation 'io.opentelemetry:opentelemetry-exporter-otlp'
}

dependencies {
    implementation(platform("io.opentelemetry:opentelemetry-bom:1.47.0"))
    implementation("io.opentelemetry:opentelemetry-sdk-metrics")
    implementation("io.opentelemetry:opentelemetry-exporter-otlp")
}

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.opentelemetry</groupId>
            <artifactId>opentelemetry-bom</artifactId>
            <version>1.47.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
<dependencies>
    <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-sdk-metrics</artifactId>
    </dependency>
    <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-exporter-otlp</artifactId>
    </dependency>
</dependencies>

Sur le traceur Java, le fournisseur démarre automatiquement son exportateur de métriques OTLP lorsque le SDK OpenTelemetry est dans le classpath. Si les dépendances sont manquantes, aucune métrique n’est émise et le traceur journalise OpenTelemetry SDK is not on the classpath.

Ruby : Ajoutez les gems de métriques OpenTelemetry

Pour les applications Ruby, ajoutez les gems du SDK de métriques OpenTelemetry et de l’exportateur de métriques OTLP à votre bundle d’application :

gem "opentelemetry-metrics-sdk", ">= 0.8"
gem "opentelemetry-exporter-otlp-metrics", ">= 0.4"

Installez les gems avec bundle install. Ces gems fournissent le fournisseur de mesure OpenTelemetry et l’exportateur de métriques OTLP. Le traceur Ruby les utilise lorsque DD_METRICS_OTEL_ENABLED=true est défini. Si les gems sont manquants, le traceur Ruby n’émet pas de métriques feature_flag.evaluations et journalise Failed to load OpenTelemetry metrics gems.

Configuration du endpoint

DD_TRACE_AGENT_URL et l’écouteur serverless-init standard sur le port 8126 ne configurent pas l’endpoint de métrique OTLP. Configurez l’endpoint OTLP séparément, comme décrit dans la section suivante. Pour les déploiements serverless sans Agent, suivez la configuration de Serverless Monitoring pour votre plateforme avant de configurer cette métrique.

Par défaut, la plupart des traceurs envoient les métriques OTLP à l’Agent à DD_AGENT_HOST sur le port 4318 (HTTP). Si votre application définit déjà DD_AGENT_HOST pour atteindre l’Agent, aucune configuration d’endpoint n’est requise.

Définissez explicitement un endpoint OTLP dans l’un des cas suivants :

• L’Agent n’est pas accessible à DD_AGENT_HOST sur le port OTLP par défaut (par exemple, un Agent distant ou un port non par défaut).
• Vous utilisez le traceur Java. Son exportateur de métriques d’évaluation des indicateurs de fonctionnalité prend uniquement en charge OTLP/HTTP (gRPC n’est pas pris en charge) sur le port 4318. Le traceur Java ne dérive pas l’endpoint de DD_AGENT_HOST et utilise http://localhost:4318 par défaut. Définissez OTEL_EXPORTER_OTLP_ENDPOINT sur l’endpoint HTTP de l’Agent lorsque l’Agent n’est pas sur localhost.
• Vous utilisez le traceur Python. Le traceur Python utilise gRPC par défaut sur le port 4317, et non HTTP. Activez le récepteur OTLP gRPC sur l’Agent, ou remplacez le protocole pour utiliser HTTP à la place :

OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4318
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

Pour définir l’endpoint, utilisez la variable OpenTelemetry standard :

# Point OTLP data at the Datadog Agent (HTTP, port 4318)
OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4318

# Or use gRPC (port 4317). For most tracers, the default protocol is http/protobuf,
# so set the protocol explicitly when switching to gRPC:
# OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4317
# OTEL_EXPORTER_OTLP_PROTOCOL=grpc

Remplacez <AGENT_HOST> par le nom de host ou l’adresse IP de votre Datadog Agent.

Exemple Docker Compose :

services:
  datadog-agent:
    environment:
      - DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT=0.0.0.0:4317
      - DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT=0.0.0.0:4318
      - HOST_PROC=/proc  # If running Agent v7.61.0+ in Docker

  app-go:
    environment:
      - DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true
      - DD_METRICS_OTEL_ENABLED=true
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://datadog-agent:4318
    depends_on:
      datadog-agent:
        condition: service_healthy

Étape 3 : Vérifiez que les métriques circulent

Après le déploiement, confirmez que les métriques atteignent Datadog :

1. Accédez à Metrics Explorer et recherchez feature_flag.evaluations.
2. Si la métrique n’apparaît pas quelques minutes après que votre application a évalué les indicateurs de fonctionnalité, vérifiez :
   • Le récepteur OTLP de l’Agent est activé et le port correct est exposé.
   • OTEL_EXPORTER_OTLP_ENDPOINT pointe vers l’Agent, et non vers un collecteur distinct.
   • Votre application évalue activement les indicateurs de fonctionnalité avec un SDK serveur au moment de l’exécution (le chemin du code est en cours d’exécution).

Étape 4 : Activez la rétention des métriques

Par défaut, feature_flag.evaluations ne conserve qu’une heure de données. Pour conserver un historique plus long :

1. Accédez à Metrics Summary et recherchez feature_flag.evaluations.
2. Sélectionnez la métrique et activez Historical Metrics.

Il s’agit d’un paramètre optionnel qui n’est pas activé automatiquement pour les métriques OTLP.

Représentez graphiquement les évaluations des indicateurs de fonctionnalité sur un dashboard

Utilisez la requête suivante pour représenter graphiquement les évaluations des indicateurs de fonctionnalité par clé d’indicateur de fonctionnalité et par variante sur un dashboard :

sum:feature_flag.evaluations{*} by {feature_flag.key,feature_flag.result.variant}

La métrique feature_flag.evaluations est un compteur avec les tags suivants :

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Feature Flags côté serveurDOCUMENTATION Graphiques des Feature FlagsDOCUMENTATION MétriquesDOCUMENTATION DashboardsDOCUMENTATION