Try it free

Manage GCP connections via Terraform

  • Latest Dynatrace
  • How-to guide
Terraform scope

Terraform manages the Google Cloud resources (service account, IAM bindings, Pub/Sub topics, Dataflow jobs, asset feeds) and the Dynatrace connection. If you leave mconfig_id empty, Terraform also creates and manages the monitoring configuration (metrics, filters, enrichment) from the mconfig_value variable. If you set mconfig_id to an existing configuration, Terraform enables it and keeps its settings, but doesn't manage them.

Update the Terraform bundle

Dynatrace publishes Terraform bundle updates to the dynatrace-gcp-deployment-template GitHub repository. Watch the repository for new releases. Updates may add support for new features, change IAM requirements, or fix issues. Each release indicates whether your terraform.tfvars needs to be adapted.

  1. Pull the new bundle files.

    Copy the updated Terraform files from the release into your working directory, replacing the managed scripts. Do not overwrite:

    • terraform.tfvars—your environment-specific variable values
    • Your Terraform state files
  2. Adapt tfvars if required.

    Check the release notes. If the release is marked as requiring tfvar changes, add or update the relevant variables in your terraform.tfvars.

  3. Preview and apply.

    terraform plan
    terraform apply

    Review the plan output before applying to confirm only expected infrastructure changes are included. If the plan shows resources that Terraform would destroy and recreate, for example the monitoring configuration, check the release notes. A release that renames resources requires you to move them in your state with terraform state mv before you apply. Otherwise Terraform replaces them.

Update monitoring settings

How you change Dynatrace-side monitoring settings (metrics, filters, enrichment rules) depends on how you onboarded:

  • Terraform created the monitoring configuration (mconfig_id is empty):

    Edit the mconfig_value variable in terraform.tfvars, then run terraform plan and terraform apply.

    Terraform is the source of truth. If you change the settings in Settings Settings or with dtctl, the next terraform apply overwrites those changes.

  • You set mconfig_id to an existing configuration:

    Terraform doesn't manage the settings. Use Settings Settings or dtctl.

Expand monitoring scope

To add projects, folders, or organizations to an existing connection:

  1. Edit terraform.tfvars and update the relevant list:

    • project_ids_for_monitoring—add or remove project IDs
    • folder_ids_for_monitoring—add or remove folder IDs
    • organization_ids_for_monitoring—add or remove organization IDs
  2. Run:

    terraform plan
    terraform apply

    Terraform grants the required IAM roles on the newly added scopes.

Enable log forwarding

  1. Edit terraform.tfvars and set:

    logs_enabled = true
  2. Export the Log Ingest token as the dynatrace_api_token variable.

    Create a platform token with the data-acquisition:logs:ingest scope if you don't have one.

    The token is never stored in terraform.tfvars:

    export TF_VAR_dynatrace_api_token="<your-ingest-token>"

    If the token is empty, terraform plan fails with an error.

  3. Run:

    terraform plan
    terraform apply

    Terraform deploys the Pub/Sub topics and subscriptions, Secret Manager secret, Cloud Storage buckets, and Dataflow streaming job. Terraform doesn't create log sinks.

  4. Create a log sink in each project whose logs you want to forward and point it at the Pub/Sub topic. No logs reach Dynatrace until you do.

terraform.tfvars is the source of truth for log forwarding. You don't need to change anything in Settings Settings.

Enable or update asset inventory feed

  1. Edit terraform.tfvars and set:

    asset_feed_enabled = true

    To add or remove asset types from the feed, update asset_feed_asset_types.

  2. Run:

    terraform plan
    terraform apply

    Terraform creates or updates the Cloud Asset feed, Pub/Sub topic, and subscription.

Rotate Log Ingest token

If your Log Ingest token has expired or been revoked:

  1. In Dynatrace, create a new platform token with the data-acquisition:logs:ingest scope.

  2. Update the token and restart the Dataflow job. The Log Ingest token is never stored in terraform.tfvars; it is passed through the sensitive dynatrace_api_token variable as an environment variable. The Dataflow job reads the token from Secret Manager only when it starts, so a new token takes effect only after you restart the job. A plain terraform apply writes the new secret version but doesn't restart the job. Choose one of the following:

    • Re-apply Terraform (recommended): re-export the token and re-apply, and tell Terraform to replace the Dataflow job. Terraform writes the new value to Secret Manager and replaces the job, which then starts with the new token.

      export TF_VAR_dynatrace_api_token="<your-new-ingest-token>"
      terraform apply -replace='module.logs[0].google_dataflow_flex_template_job.log_forwarder'
    • Update Secret Manager directly: update the secret value and drain the Dataflow job, then let Terraform start it again. A drained job finishes the log entries already in the pipeline before it stops.

      echo -n "dt0c01.NEW_TOKEN_VALUE" | gcloud secrets versions add \
      dt-logs-api-token-${MCONFIG_ID} \
      --data-file=- \
      --project=${PROJECT_ID}
      JOB_ID=$(gcloud dataflow jobs list \
      --region=${REGION} --project=${PROJECT_ID} \
      --status=active \
      --filter="name~${MCONFIG_ID}" \
      --format='value(id)' | head -1)
      gcloud dataflow jobs drain $JOB_ID --region=${REGION} --project=${PROJECT_ID}

      Wait until the job state is Drained, then re-apply Terraform to start the Dataflow job again with the updated token.

    While the job is stopped, log entries wait in the Pub/Sub subscription for up to 7 days and are forwarded when the job is running again.

Pause and resume monitoring

Pausing and resuming monitoring is a Dynatrace-side operation. Use Settings Settings to disable or enable a connection.

Terraform sets the monitoring configuration to enabled on every apply. If you pause monitoring in Settings Settings and later run terraform apply, Terraform enables the configuration again.

Update the extension

The GCP monitoring extension is not managed by Terraform. To update it, use Settings Settings or dtctl.

Delete a connection

Run terraform destroy from the bundle directory. Terraform removes the connection, the monitoring configuration, and the Google Cloud resources that it created, so this tears down the Dynatrace side and the Google Cloud side in one step:

terraform destroy

Terraform removes only what it created. Adapt the cleanup to your own changes. Terraform doesn't know about resources you added or changed yourself, such as log sinks. Remove those yourself, because a sink keeps writing to a topic that no longer exists.

Don't delete the connection manually in Settings Settings first. Terraform manages the connection, so removing it out of band leaves Terraform's state inconsistent and can orphan Pub/Sub topics, Dataflow jobs, and IAM bindings in your Google Cloud project. Always tear down with terraform destroy.

Related tags
Infrastructure Observability