> ## Documentation Index > Fetch the complete documentation index at: https://www.qovery.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Datadog > Datadog Agent (metrics, logs, optional APM) on Kubernetes via the official Datadog Helm chart Qovery creates it as a Helm release on the environment's own cluster, as a [Blueprint](https://www.qovery.com/docs/configuration/blueprints.md) service in one of your environments. | | | | - | - | | Catalog name | `helm-datadog` | | Category | Observability | | Provider | HELM | | Engine | helm | | Major versions (latest release) | `7` (3.0.4) | | Source | [HELM/datadog/7](https://github.com/Qovery/service-catalog/tree/HELM/datadog/7/3.0.4/HELM/datadog/7) | > [!TIP] > > **New to this?** You don't need to know Kubernetes or Helm. Qovery installs Datadog on your cluster with Helm and runs it for you: you fill in a form, or paste the prompt below into your coding agent. The values it publishes, listed under Outputs, reach your other services as environment variables. Qovery tells you when a newer version of the Blueprint is available. Check the requirements in the Reference section before you start, and try it first in a development environment. ## Create it > [tab] Console > > 1. Open the environment, then **New service** › **Blueprint**. > 2. Find **Datadog** in the catalog and pick the major version. > 3. Fill in the variables. Required ones are marked; the others use their defaults. > 4. Create the service, and deploy it now or later. > [tab] CLI and API > > List the catalog to get the latest tag, then create the service from it. `qovery api` signs the requests with your CLI session. > > ```bash theme={null} > ORG_ID="REPLACE_WITH_ORGANIZATION_ID" > ENV_ID="REPLACE_WITH_ENVIRONMENT_ID" > > qovery api "organization/$ORG_ID/blueprint/catalog" | jq '.. | objects | select(.name? == "helm-datadog")' > > cat > blueprint.json <<'EOF' > { > "name": "helm-datadog", > "tag": "HELM/datadog/7/3.0.4", > "icon": "app://qovery-console/datadog", > "variables": [ > { > "name": "datadog_api_key", > "value": "REPLACE_WITH_DATADOG_API_KEY", > "is_secret": true > }, > { > "name": "datadog_site", > "value": "REPLACE_WITH_DATADOG_SITE" > } > ] > } > EOF > BLUEPRINT_ID=$(qovery api "environment/$ENV_ID/blueprint" --method POST --input - < blueprint.json | jq -r .id) > rm blueprint.json # it can hold secret values > qovery api "blueprint/$BLUEPRINT_ID/deploy" --method POST > qovery api "blueprint/$BLUEPRINT_ID" # status of the latest deployment > ``` > > Replace each `REPLACE_WITH_` value. Add optional variables to `variables` the same way. > [tab] Coding agent > > Paste this into Claude Code, Cursor, Codex or another coding agent with the [Qovery agent skills](https://www.qovery.com/docs/getting-started/quickstart/agent-skills.md) installed (`curl -fsSL https://skill.qovery.com/install.sh | bash`). > > ```text Prompt wrap theme={null} > Add the Qovery Blueprint Datadog (helm-datadog) to one of my Qovery environments and deploy it. Ask me for datadog_api_key and datadog_site. > Ask me before deploying to a production environment. > Docs: https://www.qovery.com/docs/configuration/blueprints/helm-datadog.md > ``` You don't add any file to your repository. Qovery creates the Blueprint from the Console or the API. ## Variables and outputs Generated from `qbm.yml` at `HELM/datadog/7/3.0.4`, the manifest the Console form is built from. > [accordion] All 7 variables > > | Name | Type | Required | Default | Secret | Description | > | - | - | - | - | - | - | > | `datadog_api_key` | string | Yes | | Yes | From Organization Settings → API Keys | > | `datadog_site` | string | Yes | `datadoghq.com` | | Datadog site your account belongs to | > | `cluster_name` | string | | | | Leave empty to use the Qovery cluster name, lowercased and hyphenated. Else lowercase letters, digits, - and \_, dot-separated, alphanumeric at both ends. | > | `enable_logs` | string | | `true` | | Collect container logs from all pods | > | `enable_apm` | string | | `false` | | Enable the APM trace-agent port for application tracing | > | `agent_memory` | string | | `512Mi` | | Request and limit of the node agent container, as a Kubernetes quantity | > | `cluster_agent_memory` | string | | `512Mi` | | Request and limit of the cluster agent container, as a Kubernetes quantity | Outputs become environment variables that other services in the environment can use. By default Qovery also creates an alias for each output, prefixed with the Blueprint's name; see [Aliases Qovery creates for outputs](https://www.qovery.com/docs/configuration/environment-variables.md#aliases-qovery-creates-for-outputs) for the naming rules and the cases where no alias is created. > [accordion] All 1 outputs > > | Name | Secret | Description | > | - | - | - | > | `datadog_cluster_agent_service` | | In-cluster Datadog cluster-agent service name | ## Reference From the Blueprint's [README](https://github.com/Qovery/service-catalog/blob/HELM/datadog/7/3.0.4/HELM/datadog/7/README.md). Deploys the [Datadog Agent](https://docs.datadoghq.com/agent/kubernetes/) on Kubernetes via the official `datadog/datadog` Helm chart (`3.240.0`, Agent v7) — a per-node metrics/logs DaemonSet plus the Datadog cluster agent. ### Credentials A **Datadog API key** supplied as the sensitive `datadog_api_key` variable, plus the `datadog_site` matching your account's region. Data appears in your Datadog account (no in-cluster endpoint to connect to). ### Variables #### Required Variables | Name | Type | Sensitive | Description | | - | - | - | - | | `datadog_api_key` | string | yes | Datadog API key (Organization Settings → API Keys) | | `datadog_site` | string | | Datadog site (`datadoghq.com`, `datadoghq.eu`, `us3/us5/ap1`, gov). Default suggestion: `datadoghq.com`. | #### Optional Variables | Name | Type | Default | Description | | - | - | - | - | | `cluster_name` | string | Qovery cluster name | Cluster name tag applied to all Datadog telemetry. Leave empty to use the Qovery cluster's own name, lowercased and hyphenated. Otherwise: lowercase letters, digits, hyphens and underscores, optionally dot-separated, starting and ending alphanumeric (e.g. prod-eu) | | `enable_logs` | string | `true` | Collect container logs from all pods (`true`/`false`) | | `enable_apm` | string | `false` | Enable the APM trace-agent port (`true`/`false`) | | `agent_memory` | string | `512Mi` | Memory request/limit for the node agent container | | `cluster_agent_memory` | string | `512Mi` | Memory request/limit for the cluster agent container | ### Outputs | Name | Description | | - | - | | `datadog_cluster_agent_service` | In-cluster Datadog cluster-agent service name | ### Notes * `cluster_name` is optional and defaults to the **actual Qovery cluster name**, taken from the `qovery_cluster_name` variable the engine injects into every blueprint and passed through Tera's `slugify`. `1.x` defaulted it to the placeholder `qovery-cluster`, so installs that never touched the field tagged all telemetry with a name matching no real cluster. Slugifying is required because Qovery cluster names are unconstrained while the chart validates this value, so a name carrying uppercase or spaces is lowercased and hyphenated. Set the variable explicitly to use a different tag; an explicit value is passed through unchanged and must satisfy Datadog's own rule, which the `pattern` and `maxLength` mirror: at most 80 characters of lowercase letters, digits, hyphens and underscores, optionally dot-separated, starting and ending with an alphanumeric. * The Datadog Operator is explicitly disabled (`datadog.operator.enabled: false`). Chart `3.240.0` enables it by default, which adds 7 cluster-scoped CRDs; because CRDs are singular per cluster, the first environment to install would own them and every later Datadog install on that cluster would fail with a Helm ownership error. The agent is deployed directly by this chart, so the Operator was unused. `1.x` shipped it. * The Cluster Agent's admission controller is disabled (`clusterAgent.admissionController.enabled: false`). Its Service is named `-cluster-agent-admission-controller`, and since Qovery release names are `helm-z-`, a service name longer than 13 characters pushes it past Kubernetes' 63-character limit and the deploy fails. It injects APM/DogStatsD config only into pods labelled `admission.datadoghq.com/enabled=true`, which Qovery services do not carry, so nothing is lost — configure tracers as described below. `1.x` shipped it enabled. * **Service name length.** With the admission controller gone the longest suffix the chart appends is `-kpi-telemetry-configmap` (24 characters), so a Qovery service name above \~24 characters will still breach the 63-character limit on a resource name. Keep the service name short. * Deploys cluster-wide resources (DaemonSet, ClusterRole/Binding, cluster agent) — `allowClusterWideResources: true`. * Resources are set explicitly for the node agent (`agent_memory`) and the cluster agent (`cluster_agent_memory`); tune `agent_memory` for high-cardinality nodes. * APM: with `enable_apm=true`, point tracers at the agent on the node (or the `datadog.apm` socket) per Datadog's APM setup docs. * Chart pinned to `3.240.0`. This is the official Datadog chart (not Bitnami). ## Related topics - [Datadog Integration](https://www.qovery.com/docs/configuration/integrations/observability/datadog.md) - [Configuration Overview](https://www.qovery.com/docs/configuration/overview.md) - [Kubecost](https://www.qovery.com/docs/configuration/integrations/observability/kubecost.md) - [Qovery Observe](https://www.qovery.com/docs/configuration/integrations/observability/qovery-observe.md) - [Blueprints](https://www.qovery.com/docs/configuration/blueprints.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.