Skip to content
Open
Show file tree
Hide file tree
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions content/en/feature_flags/concepts/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,4 +12,5 @@ Learn how Datadog Feature Flags work and how to configure flags, environments, t
{{< nextlink href="/feature_flags/concepts/traffic_splitting" >}}Traffic Splitting and Randomization{{< /nextlink >}}
{{< nextlink href="/feature_flags/concepts/distribution_channels" >}}Distribution Channels{{< /nextlink >}}
{{< nextlink href="/feature_flags/concepts/flag_history" >}}Flag History{{< /nextlink >}}
{{< nextlink href="/feature_flags/concepts/flag_graphs" >}}Feature Flag Graphs{{< /nextlink >}}
{{< /whatsnext >}}
72 changes: 72 additions & 0 deletions content/en/feature_flags/concepts/flag_graphs.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
---
title: Feature Flag Graphs
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

description: Understand the graphs on the feature flags list and details pages and how to use them to monitor your rollout.
further_reading:
- link: "/feature_flags/server/"
tag: "Documentation"
text: "Server-Side Feature Flags"
- link: "/feature_flags/client/"
tag: "Documentation"
text: "Client-Side Feature Flags"
- link: "/dashboards/"
tag: "Documentation"
text: "Dashboards"
---

## Overview

Datadog Feature Flags provides graphs at two levels: the flags list page gives a snapshot of all your flags at a glance, and the flag details page shows in-depth graphs for a single flag.

## Flags list page

The flags list page shows a summary row for each flag, including total evaluation count and mini graph that let you assess activity across your flag inventory without opening each flag individually.

{{< img src="feature_flags/flag_graphs/flags_list.png" alt="Feature flags list page showing evaluation counts and sparklines per flag" style="width:100%;" >}}
Comment thread
vjfridge marked this conversation as resolved.
Outdated

Each row shows:

- **Evaluation count**: total number of client and server evaluations in the past hour
- **Mini graph**: individual client and server evaluations in the past hour, grouped by variant
- **Variants**: the variant colors are the key for the mini graph

## Flag details page

The flag details page includes observability insights to help you quickly identify how a single flag is performing.

### Targeting rule evaluation counts

Shows the total client and server evaluations that fell through to each targeting rule in the given `Real-time metric overview` time range.

{{< img src="feature_flags/flag_graphs/targeting_rule_distribution.png" alt="Targeting rule evaluation count" style="width:100%;" >}}

Use this count to confirm that targeting rules are working as expected and to see how traffic is distributed across targeting rules in a given environment, including % of total traffic in the time range.

### Client + Server evaluations

{{< img src="feature_flags/flag_graphs/evaluations.png" alt="Client + Server evaluations graph split by variant" style="width:100%;" >}}

Client SDK evaluations have two views, each grouped by variant:

- **Unique**: count of unique users or entities that evaluated each variant (deduplicated by targeting key)
- **Total**: count of all evaluations by variant, including repeated evaluations of the same targeting key


Comment on lines +52 to +53
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming 2 blank lines was unintentional

Suggested change

Server SDK evaluations show count of all evaluations by variant. Requires flag evaluation metrics to be enabled. See [Set Up Server-Side Flag Evaluation Metrics][1].

### Errors and latency

{{< img src="feature_flags/flag_graphs/errors_latency.png" alt="Error and latency graphs" style="width:100%;" >}}

Error rate and latency graphs are available for client evaluations. Server evaluation support is coming soon.

## Export to a dashboard

{{< img src="feature_flags/flag_graphs/dashboard_export.png" alt="Export graph to a dashboard" style="width:100%;" >}}

Choose **Export to Dashboard** to add it to a Datadog dashboard. From there, you can slice and dice the data for further insights.

## Further reading

{{< partial name="whats-next/whats-next.html" >}}

[1]: /feature_flags/guide/server_flag_evaluation_metrics/
1 change: 1 addition & 0 deletions content/en/feature_flags/guide/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@ cascade:

{{< whatsnext desc="Feature Flags Guides:" >}}
{{< nextlink href="/getting_started/feature_flags" >}}Getting started with Feature Flags{{< /nextlink >}}
{{< nextlink href="/feature_flags/guide/server_flag_evaluation_metrics" >}}Set Up Server-Side Flag Evaluation Metrics{{< /nextlink >}}
{{< nextlink href="/feature_flags/guide/migrate_from_launchdarkly" >}}Migrate Your Feature Flags from LaunchDarkly{{< /nextlink >}}
{{< nextlink href="/feature_flags/guide/migrate_from_statsig" >}}Migrate Your Feature Flags from Statsig{{< /nextlink >}}
{{< /whatsnext >}}
146 changes: 146 additions & 0 deletions content/en/feature_flags/guide/server_flag_evaluation_metrics.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,146 @@
---
title: Set Up Server-Side Flag Evaluation Metrics
Copy link
Copy Markdown
Contributor Author

@vjfridge vjfridge Jun 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

description: Configure the Datadog Agent and your application to emit and visualize flag evaluation metrics for server-side feature flags.
further_reading:
- link: "/feature_flags/server/"
tag: "Documentation"
text: "Server-Side Feature Flags"
- link: "/feature_flags/concepts/flag_graphs/"
tag: "Documentation"
text: "Feature Flag Graphs"
- link: "/metrics/"
tag: "Documentation"
text: "Metrics"
- link: "/dashboards/"
tag: "Documentation"
text: "Dashboards"
---

## Overview

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.

<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>

## Prerequisites

Before setting up flag evaluation metrics:

- Server-side feature flags are already configured. See [Server-Side Feature Flags][1].
- Datadog Agent 7.55 or later is running.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs say

Since versions 6.32.0 and 7.32.0

OTLP Ingest in the Agent is a way to send telemetry data directly from applications instrumented with [OpenTelemetry SDKs][1] to Datadog Agent. Since versions 6.32.0 and 7.32.0, the Datadog Agent can ingest OTLP traces and [OTLP metrics][2] through gRPC or HTTP. Since versions 6.48.0 and 7.48.0, the Datadog Agent can ingest OTLP logs through gRPC or HTTP.

I don't see this number in ffe-dogfooding either, so this might be over-restrictive unless there's some other source for this

- `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true` is set on your application.
- Your server-side tracer meets the minimum version for flag evaluation metrics support:

| Language | Minimum tracer version |
|----------|----------------------|
| .NET | 3.44.0 |
| Go | 2.8.0 |
| Java | 1.62.0 |
| Node.js | 5.99.0 |
| Python | 4.7.0 |
| Ruby | 2.32.0 |
| C++ | Coming soon |
| PHP | Coming soon |
| Python Lambdas | Coming soon |
| Rust | Coming soon |

## Step 1: Enable the Agent OTLP receiver

Flag evaluation metrics are emitted over OpenTelemetry (OTLP). The Datadog Agent includes an OTLP receiver, but it is off by default. Enable it with the following environment variables on your Agent:

{{< code-block lang="bash" >}}
# gRPC endpoint (port 4317)
DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT=0.0.0.0:4317

# HTTP endpoint (port 4318)
DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT=0.0.0.0:4318
{{< /code-block >}}
Comment on lines +47 to +53
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of this is already covered in otlp_ingest_in_the_agent.md

2. For the Datadog Agent container, set the following endpoint environment variables and expose the corresponding port:
- For gRPC: Set `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT` to `0.0.0.0:4317` and expose port `4317`.

So I might be better to just link to that doc which I assume is the canonical one instead of duplicating it here


You only need to enable the protocol your application uses. Both gRPC and HTTP are shown for reference.

<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>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also covered here

1. Set the environment variable <code>HOST_PROC</code> to <code>/proc</code> in your Agent Docker container.<br>


## Step 2: Configure your application

Set the following environment variables on your application in addition to the standard [server-side feature flag configuration][1]:

{{< code-block lang="bash" >}}
# Enable flag evaluation metrics
DD_METRICS_OTEL_ENABLED=true

# Point OTLP metrics at the Datadog Agent
# HTTP endpoint (note the /v1/metrics path suffix):
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4318/v1/metrics

# Or use gRPC (no path suffix):
# OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4317
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OTEL_EXPORTER_OTLP_METRICS_ENDPOINT is valid, but the canonical docs seem to prefer OTEL_EXPORTER_OTLP_ENDPOINT, which I believe accomplishes the same

Set the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable in your application's environment:
For gRPC:
```shell
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317"
```
For HTTP:
```shell
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318"
```

I'm actually not sure which one to use. OTEL_EXPORTER_OTLP_METRICS_ENDPOINT is more granular and only applies to OTLP for metrics, while OTEL_EXPORTER_OTLP_ENDPOINT covers all OTLP

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also the default OTLP protocol is http/protobuf; pointing at :4317 without OTEL_EXPORTER_OTLP_PROTOCOL=grpc sends HTTP to the gRPC port and fails. So we also need to mention the protocol var for the gRPC option

{{< /code-block >}}

Replace `<AGENT_HOST>` with the hostname or IP address of your Datadog Agent. In a Docker Compose setup, this is typically the Agent container's service name.
Comment on lines +59 to +75
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In most cases, the endpoints don't need to be set. These variables were used in ffe-dogfooding mainly to control if the metrics were being sent to the agent vs. a special container for reporting the counts in http://localhost:8080/dashboard

Suggested change
## Step 2: Configure your application
Set the following environment variables on your application in addition to the standard [server-side feature flag configuration][1]:
{{< code-block lang="bash" >}}
# Enable flag evaluation metrics
DD_METRICS_OTEL_ENABLED=true
# Point OTLP metrics at the Datadog Agent
# HTTP endpoint (note the /v1/metrics path suffix):
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4318/v1/metrics
# Or use gRPC (no path suffix):
# OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4317
{{< /code-block >}}
Replace `<AGENT_HOST>` with the hostname or IP address of your Datadog Agent. In a Docker Compose setup, this is typically the Agent container's service name.
## Step 2: Configure your application
Set the following environment variable on your application, in addition to the
standard [server-side feature flag configuration][1]:
{{< code-block lang="bash" >}}
# Enable flag evaluation metrics
DD_METRICS_OTEL_ENABLED=true
{{< /code-block >}}
By default, most tracers send OTLP metrics to the Agent at `DD_AGENT_HOST` on port
`4318`. If your application already sets `DD_AGENT_HOST` to reach the Agent, no
endpoint configuration is required.
Set an OTLP endpoint explicitly in either of these cases:
- The Agent is not reachable at `DD_AGENT_HOST` on the default OTLP port (for example,
a remote Agent or a non-default port).
- 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`.
To set the endpoint, use the standard OpenTelemetry variable:
{{< code-block lang="bash" >}}
# Point OTLP data at the Datadog Agent (HTTP, port 4318)
OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4318
# Or use gRPC (port 4317). The default protocol is http/protobuf, so you must also
# set the protocol to grpc when using the gRPC port:
# OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4317
# OTEL_EXPORTER_OTLP_PROTOCOL=grpc
{{< /code-block >}}
Replace `<AGENT_HOST>` with the hostname or IP address of your Datadog Agent. In a
Docker Compose setup, this is typically the Agent container's service name. To set the
metrics endpoint independently of other OTLP signals, use
`OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` instead, and append the `/v1/metrics` path for HTTP.


## Docker Compose example

{{< code-block lang="yaml" filename="docker-compose.yml" >}}
services:
datadog-agent:
image: gcr.io/datadoghq/agent:latest
environment:
- DD_API_KEY=<YOUR_DATADOG_API_KEY>
- 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 # Required for Agent v7.61.0+ running in Docker
Comment on lines +83 to +85
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You only need one or the other, but this reads like both are required. We needed both in ffe-dogfooding because python defaults to gRPC and the rest of the SDKs use HTTP

2. For the Datadog Agent container, set the following endpoint environment variables and expose the corresponding port:
- For gRPC: Set `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT` to `0.0.0.0:4317` and expose port `4317`.
- For HTTP: Set `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT` to `0.0.0.0:4318` and expose port `4318`.

"# Required for Agent v7.61.0+ running in Docker" is a bit of an overstatement because it's one of a few workarounds for a known issue. I'd rephrase to "If running Agent v7.61.0+ in Docker"

Copy link
Copy Markdown
Contributor

@sameerank sameerank Jun 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And actually that distinction between python/gRPC vs the rest is probably worth mentioning somewhere

Maybe an additional bullet in the Step 2 rewrite?

  - The **Python** tracer defaults to the gRPC protocol (Agent OTLP port `4317`), whereas the other tracers default to HTTP (port `4318`). Make sure the Agent receiver port you enabled in Step 1 matches, or set `OTEL_EXPORTER_OTLP_PROTOCOL` and the endpoint explicitly.


app:
environment:
- DD_SERVICE=<YOUR_SERVICE_NAME>
- DD_ENV=<YOUR_ENVIRONMENT>
- DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true
- DD_METRICS_OTEL_ENABLED=true
- OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://datadog-agent:4318/v1/metrics
depends_on:
- datadog-agent
{{< /code-block >}}

## Step 3: Verify metrics are flowing

After deploying, confirm metrics are reaching Datadog:

1. Go to [Metrics Explorer][2] and search for `feature_flag.evaluations`.
2. If the metric does not appear within a few minutes of your application evaluating flags, check:
- The Agent OTLP receiver is enabled and the correct port is exposed.
- `OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` points to the Agent, not a separate collector.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might also update this depending on what you update in step 2 re: OTEL_EXPORTER_OTLP_ENDPOINT vs OTEL_EXPORTER_OTLP_METRICS_ENDPOINT

- Your application is actively evaluating flags at runtime (the code path is being executed).

## Step 4: Enable metric retention

By default, `feature_flag.evaluations` retains only one hour of data. To retain a longer history:

1. Go to [Metrics Summary][3] and search for `feature_flag.evaluations`.
2. Select the metric and enable **Historical Metrics**.

This is an opt-in setting and is not enabled automatically for OTLP metrics.

## Graph flag evaluations on a dashboard

Use the following query to graph flag evaluations by flag key and variant on a [dashboard][4]:

{{< code-block lang="text" >}}
sum:feature_flag.evaluations{*} by {feature_flag.key,feature_flag.result.variant}
{{< /code-block >}}

The `feature_flag.evaluations` metric is a counter with the following tags:

| Tag | Description |
|-----|-------------|
| `feature_flag.key` | The flag key being evaluated |
| `feature_flag.result.variant` | The variant returned by the evaluation |
| `feature_flag.result.reason` | The reason for the evaluation result |

## Further reading

{{< partial name="whats-next/whats-next.html" >}}

[1]: /feature_flags/server/
[2]: https://app.datadoghq.com/metric/explorer
[3]: https://app.datadoghq.com/metric/summary
[4]: /dashboards/
5 changes: 4 additions & 1 deletion content/en/feature_flags/server/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,9 @@ further_reading:
- link: "/remote_configuration/"
tag: "Documentation"
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

text: "Remote Configuration"
- link: "/feature_flags/guide/server_flag_evaluation_metrics/"
tag: "Guide"
text: "Set Up Server-Side Flag Evaluation Metrics"
---

## Overview
Expand Down Expand Up @@ -76,7 +79,7 @@ DD_METRICS_OTEL_ENABLED=true

<div class="alert alert-info">Remote Configuration must be available for server-side Feature Flags. It is enabled by default on Agent 7.47.0 and later. Only set SDK-level Remote Configuration variables (such as <code>DD_REMOTE_CONFIG_ENABLED=true</code>) if your tracer has Remote Configuration disabled and you need to override that setting.</div>

<div class="alert alert-info">Set <code>DD_METRICS_OTEL_ENABLED=true</code> to enable flag evaluation metrics. Without this, the SDK does not emit metrics for flag evaluations. When enabled, each evaluation records a <code>feature_flag.evaluations</code> counter metric tagged with the flag key, result variant, and evaluation reason.</div>
<div class="alert alert-info">Set <code>DD_METRICS_OTEL_ENABLED=true</code> to enable the experimental <code>feature_flag.evaluations</code> metric. Without this, the SDK does not emit metrics for flag evaluations. Additional Agent configuration is required. See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a> for the full setup guide.</div>

## Testing with in-memory providers

Expand Down
2 changes: 2 additions & 0 deletions content/en/feature_flags/server/dotnet.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,8 @@ DD_ENV=<YOUR_ENVIRONMENT>

<div class="alert alert-info">The <code>EXPERIMENTAL_</code> prefix is retained for backwards compatibility; the provider itself is stable.</div>

<div class="alert alert-warning">The <code>feature_flag.evaluations</code> metric emitted by <code>DD_METRICS_OTEL_ENABLED=true</code> is experimental and may change or be removed in a future release. Additional Agent configuration is required to emit this metric. See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a>.</div>

## Installation

Install the Datadog [.NET SDK][3] and [OpenFeature SDK][4] using NuGet:
Expand Down
2 changes: 2 additions & 0 deletions content/en/feature_flags/server/go.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,8 @@ DD_ENV=<YOUR_ENVIRONMENT>

<div class="alert alert-info">The <code>EXPERIMENTAL_</code> prefix is retained for backwards compatibility; the provider itself is stable.</div>

<div class="alert alert-warning">The <code>feature_flag.evaluations</code> metric emitted by <code>DD_METRICS_OTEL_ENABLED=true</code> is experimental and may change or be removed in a future release. Additional Agent configuration is required to emit this metric. See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a>.</div>

## Installation

Install the Datadog OpenFeature provider package:
Expand Down
2 changes: 2 additions & 0 deletions content/en/feature_flags/server/java.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,8 @@ further_reading:

<div class="alert alert-info">Enable Java Feature Flags by setting <code>DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true</code>. The <code>EXPERIMENTAL_</code> prefix is kept for backwards compatibility; the provider is stable. See the <a href="#configuration">Configuration section</a> for details.</div>

<div class="alert alert-warning">The <code>feature_flag.evaluations</code> metric emitted by <code>DD_METRICS_OTEL_ENABLED=true</code> is experimental and may change or be removed in a future release. Additional Agent configuration is required to emit this metric. See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a>.</div>

## Overview

This page describes how to instrument a Java application with the Datadog Feature Flags SDK. Datadog feature flags provide a unified way to remotely control feature availability in your app, experiment safely, and deliver new experiences with confidence.
Expand Down
2 changes: 2 additions & 0 deletions content/en/feature_flags/server/nodejs.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,8 @@ DD_METRICS_OTEL_ENABLED=true

<div class="alert alert-info">The <code>EXPERIMENTAL_</code> prefix is retained for backwards compatibility; the provider itself is stable.</div>

<div class="alert alert-warning">The <code>feature_flag.evaluations</code> metric emitted by <code>DD_METRICS_OTEL_ENABLED=true</code> is experimental and may change or be removed in a future release. Additional Agent configuration is required to emit this metric. See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a>.</div>

Or enable the provider in code:

```javascript
Expand Down
2 changes: 2 additions & 0 deletions content/en/feature_flags/server/python.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,8 @@ export DD_ENV=<YOUR_ENVIRONMENT>

<div class="alert alert-info">The <code>EXPERIMENTAL_</code> prefix is retained for backwards compatibility; the provider itself is stable.</div>

<div class="alert alert-warning">The <code>feature_flag.evaluations</code> metric emitted by <code>DD_METRICS_OTEL_ENABLED=true</code> is experimental and may change or be removed in a future release. Additional Agent configuration is required to emit this metric. See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a>.</div>

## Installation

Install the Datadog Python SDK and OpenFeature SDK:
Expand Down
2 changes: 2 additions & 0 deletions content/en/feature_flags/server/ruby.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,8 @@ DD_METRICS_OTEL_ENABLED=true

<div class="alert alert-info">The <code>EXPERIMENTAL_</code> prefix is retained for backwards compatibility; the provider itself is stable.</div>

<div class="alert alert-warning">The <code>feature_flag.evaluations</code> metric emitted by <code>DD_METRICS_OTEL_ENABLED=true</code> is experimental and may change or be removed in a future release. Additional Agent configuration is required to emit this metric. See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a>.</div>

Or enable the provider in code:

```ruby
Expand Down
3 changes: 3 additions & 0 deletions content/en/getting_started/feature_flags/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -368,6 +368,8 @@ Monitor the feature rollout from the feature flag details page, which provides r

{{< img src="getting_started/feature_flags/real-time-flag-metrics.png" alt="Real-time flag metrics panel" style="width:100%;" >}}

For server-side applications, you can also enable flag evaluation metrics to track how often each variant is returned and graph the data on dashboards. See [Set Up Server-Side Flag Evaluation Metrics][9].

## Further reading

{{< partial name="whats-next/whats-next.html" >}}
Expand All @@ -380,3 +382,4 @@ Monitor the feature rollout from the feature flag details page, which provides r
[6]: /feature_flags/concepts/distribution_channels/
[7]: /feature_flags/concepts/targeting_rules/
[8]: /feature_flags/concepts/traffic_splitting/
[9]: /feature_flags/guide/server_flag_evaluation_metrics/
Loading