|
| 1 | +--- |
| 2 | +title: Set Up Server-Side Flag Evaluation Metrics |
| 3 | +description: Configure the Datadog Agent and your application to emit and visualize flag evaluation metrics for server-side feature flags. |
| 4 | +further_reading: |
| 5 | +- link: "/feature_flags/server/" |
| 6 | + tag: "Documentation" |
| 7 | + text: "Server-Side Feature Flags" |
| 8 | +- link: "/feature_flags/concepts/flag_graphs/" |
| 9 | + tag: "Documentation" |
| 10 | + text: "Feature Flag Graphs" |
| 11 | +- link: "/metrics/" |
| 12 | + tag: "Documentation" |
| 13 | + text: "Metrics" |
| 14 | +- link: "/dashboards/" |
| 15 | + tag: "Documentation" |
| 16 | + text: "Dashboards" |
| 17 | +--- |
| 18 | + |
| 19 | +## Overview |
| 20 | + |
| 21 | +Flag evaluation metrics let you measure how often each variant of a feature flag is returned by your server-side application. Use these metrics to track flag adoption over time, verify targeting rules are working as expected, and graph flag evaluation data on dashboards. |
| 22 | + |
| 23 | +<div class="alert alert-warning">The <code>feature_flag.evaluations</code> metric is experimental and may change or be removed in a future release.</div> |
| 24 | + |
| 25 | +## Prerequisites |
| 26 | + |
| 27 | +Before setting up flag evaluation metrics, confirm the following: |
| 28 | + |
| 29 | +- [Server-side feature flags][1] are already configured. |
| 30 | +- Datadog Agent 7.32.0 or later is running. |
| 31 | +- `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true` is set on your application. |
| 32 | +- Your server-side tracer meets the minimum version for flag evaluation metrics support: |
| 33 | + |
| 34 | +| Language | Minimum tracer version | |
| 35 | +| -------- | ---------------------- | |
| 36 | +| .NET | 3.44.0 | |
| 37 | +| Go | 2.8.0 | |
| 38 | +| Java | 1.62.0 | |
| 39 | +| Node.js | 5.99.0 | |
| 40 | +| PHP | 1.21.1 | |
| 41 | +| Python | 4.7.0 | |
| 42 | +| Ruby | 2.32.0 | |
| 43 | + |
| 44 | +## Step 1: Enable the Agent OTLP receiver |
| 45 | + |
| 46 | +Flag evaluation metrics are emitted over OpenTelemetry (OTLP). The Datadog Agent includes an OTLP receiver that is off by default. For setup instructions, see [OTLP Ingestion by the Datadog Agent][2]. |
| 47 | + |
| 48 | +You only need to enable the protocol your application uses (gRPC on port 4317, or HTTP on port 4318). |
| 49 | + |
| 50 | +<div class="alert alert-info">If you are running Agent v7.61.0 or later in Docker, set <code>HOST_PROC=/proc</code> on the Agent container to work around a known issue with the OTLP pipeline.</div> |
| 51 | + |
| 52 | +## Step 2: Configure your application |
| 53 | + |
| 54 | +Set the following environment variable on your application, in addition to the standard [server-side feature flag configuration][1]: |
| 55 | + |
| 56 | +{{< code-block lang="bash" >}} |
| 57 | +# Enable flag evaluation metrics |
| 58 | +DD_METRICS_OTEL_ENABLED=true |
| 59 | +{{< /code-block >}} |
| 60 | + |
| 61 | +By default, most tracers send OTLP metrics to the Agent at `DD_AGENT_HOST` on port `4318` (HTTP). If your application already sets `DD_AGENT_HOST` to reach the Agent, no endpoint configuration is required. |
| 62 | + |
| 63 | +Set an OTLP endpoint explicitly in any of these cases: |
| 64 | + |
| 65 | +- The Agent is not reachable at `DD_AGENT_HOST` on the default OTLP port (for example, a remote Agent or a non-default port). |
| 66 | +- You use the **Java** tracer. The Java tracer does not derive the endpoint from `DD_AGENT_HOST`; it defaults to `localhost:4318`. Set the endpoint whenever the Agent is not on `localhost`. |
| 67 | +- You use the **Python** tracer. The Python tracer defaults to gRPC on port `4317`, not HTTP. Enable the gRPC OTLP receiver on the Agent, or override the protocol to use HTTP instead: |
| 68 | + |
| 69 | +{{< code-block lang="bash" >}} |
| 70 | +OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4318 |
| 71 | +OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf |
| 72 | +{{< /code-block >}} |
| 73 | + |
| 74 | +To set the endpoint, use the standard OpenTelemetry variable: |
| 75 | + |
| 76 | +{{< code-block lang="bash" >}} |
| 77 | +# Point OTLP data at the Datadog Agent (HTTP, port 4318) |
| 78 | +OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4318 |
| 79 | + |
| 80 | +# Or use gRPC (port 4317). For most tracers, the default protocol is http/protobuf, |
| 81 | +# so set the protocol explicitly when switching to gRPC: |
| 82 | +# OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4317 |
| 83 | +# OTEL_EXPORTER_OTLP_PROTOCOL=grpc |
| 84 | +{{< /code-block >}} |
| 85 | + |
| 86 | +Replace `<AGENT_HOST>` with the hostname or IP address of your Datadog Agent. |
| 87 | + |
| 88 | +Docker Compose example: |
| 89 | + |
| 90 | +{{< code-block lang="yaml" filename="docker-compose.yml" >}} |
| 91 | +services: |
| 92 | + datadog-agent: |
| 93 | + environment: |
| 94 | + - DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT=0.0.0.0:4317 |
| 95 | + - DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT=0.0.0.0:4318 |
| 96 | + - HOST_PROC=/proc # If running Agent v7.61.0+ in Docker |
| 97 | + |
| 98 | + app-go: |
| 99 | + environment: |
| 100 | + - DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true |
| 101 | + - DD_METRICS_OTEL_ENABLED=true |
| 102 | + - OTEL_EXPORTER_OTLP_ENDPOINT=http://datadog-agent:4318 |
| 103 | + depends_on: |
| 104 | + datadog-agent: |
| 105 | + condition: service_healthy |
| 106 | +{{< /code-block >}} |
| 107 | + |
| 108 | +## Step 3: Verify metrics are flowing |
| 109 | + |
| 110 | +After deploying, confirm metrics are reaching Datadog: |
| 111 | + |
| 112 | +1. Go to [Metrics Explorer][3] and search for `feature_flag.evaluations`. |
| 113 | +2. If the metric does not appear within a few minutes of your application evaluating flags, check: |
| 114 | + - The Agent OTLP receiver is enabled and the correct port is exposed. |
| 115 | + - `OTEL_EXPORTER_OTLP_ENDPOINT` points to the Agent, not a separate collector. |
| 116 | + - Your application is actively evaluating flags with a server SDK at runtime (the code path is being executed). |
| 117 | + |
| 118 | +## Step 4: Enable metric retention |
| 119 | + |
| 120 | +By default, `feature_flag.evaluations` retains only one hour of data. To retain a longer history: |
| 121 | + |
| 122 | +1. Go to [Metrics Summary][4] and search for `feature_flag.evaluations`. |
| 123 | +2. Select the metric and enable **Historical Metrics**. |
| 124 | + |
| 125 | +This is an opt-in setting and is not enabled automatically for OTLP metrics. |
| 126 | + |
| 127 | +## Graph flag evaluations on a dashboard |
| 128 | + |
| 129 | +Use the following query to graph flag evaluations by flag key and variant on a [dashboard][5]: |
| 130 | + |
| 131 | +{{< code-block lang="text" >}} |
| 132 | +sum:feature_flag.evaluations{*} by {feature_flag.key,feature_flag.result.variant} |
| 133 | +{{< /code-block >}} |
| 134 | + |
| 135 | +The `feature_flag.evaluations` metric is a counter with the following tags: |
| 136 | + |
| 137 | +| Tag | Description | |
| 138 | +| ------------------------------------ | -------------------------------------------------- | |
| 139 | +| `feature_flag.key` | The flag key being evaluated | |
| 140 | +| `feature_flag.result.variant` | The variant returned by the evaluation | |
| 141 | +| `feature_flag.result.reason` | The reason for the evaluation result | |
| 142 | +| `feature_flag.result.allocation_key` | The identifier for the evaluated targeting rules (emitted only when present) | |
| 143 | +| `error.type` | The error type (emitted only on error evaluations) | |
| 144 | + |
| 145 | +## Further reading |
| 146 | + |
| 147 | +{{< partial name="whats-next/whats-next.html" >}} |
| 148 | + |
| 149 | +[1]: /feature_flags/server/ |
| 150 | +[2]: /opentelemetry/setup/otlp_ingest_in_the_agent/ |
| 151 | +[3]: https://app.datadoghq.com/metric/explorer |
| 152 | +[4]: https://app.datadoghq.com/metric/summary |
| 153 | +[5]: /dashboards/ |
0 commit comments