From Manual Clicks to Code: Managing Dynatrace Extension Configurations at Scale

[dczupryn-dt]

The Problem Nobody Talks About 

Every our Dynatrace tenant is a snowflake.

When the Demoability team operates six Dynatrace environments — from playground-dev on the sprint ring to the customer-facing live tenant — each one carries a different set of active Extensions 2.0 monitoring configurations. One tenant monitors IBM MQ and Oracle SQL. Another runs three SNMP auto-discovery scanners across WAN and datacenter segments. A third tracks Salesforce event streams. Some extensions need nothing more than an AG group name; others require OAuth tokens, API keys, database passwords, and private RSA keys stored safely in AWS Secrets Manager.
Managing this by hand in the Dynatrace UI works — until it doesn't. A configuration drifts silently. A credential rotates and the extension stops collecting. Someone enables a feature set in one environment and forgets to replicate it to the others. There is no audit trail, no review process, no rollback.
The answer was obvious: manage it as code. The harder question was how.

Terraform Is the Right Tool — and a Daunting One 

The dynatrace-oss/dynatrace Terraform provider supports dynatrace_hub_extension_v2_config, which can declaratively manage monitoring configurations for every installed extension. In theory, this is clean. In practice, it surfaces a wall of complexity immediately.
The Dynatrace API replaces every stored credential in its GET responses with a 16-character hex placeholder. This means every terraform plan shows a perpetual diff on password fields — unless you engineer around it with ignore_changes and a dual-hash fingerprint that can distinguish real credential changes from API noise. Then there is version management: each extension has an active installed version per tenant, and version mismatches between state and the API cause silent re-pushes. Six environments × 20+ extension types × per-environment variation in feature sets, AG groups, device IP lists, and secret keys is not a configuration problem. It is a code generation problem.

Where AI Becomes the Force Multiplier

Rather than manually inspecting each tenant's Dynatrace Hub and transcribing configs by hand, the team uses an AI agent equipped with a purpose-built dt-export skill. The skill knows how to locate the provider binary in the Terragrunt cache, set the required environment variables, and invoke the provider's built-in export CLI against a live tenant:

# Export all hub extension v2 configs from the tenant
export DYNATRACE_ENV_URL="https://{environmentid}.apps.dynatrace.com"
export DYNATRACE_CLIENT_ID="dt0s02...."
export DYNATRACE_CLIENT_SECRET="..."
export DYNATRACE_TOKEN_URL="https://{environmentid}.apps.dynatrace.com needs onboarding.
Export all existing extension configs, map them to deployment variables, 
create environments/xyz/terragrunt.hcl, and update SECRETS.md with the required secret keys.

The export produces raw .tf files reflecting exactly what is deployed. The agent then reads these files, maps the field structure to the repo's module interface, and outputs ready-to-commit terragrunt.hcl configuration blocks — with credentials extracted into AWS Secrets Manager key references rather than plain values.

Example prompts that capture the full workflow:

"Export the current extension monitoring configurations from the live3gen environment. Find any configs for SNMP auto-discovery that are not yet in Terraform state and add them to environments/live3gen/terragrunt.hcl following the existing patterns."

Or

"A new Dynatrace environment https://{environmentid}.apps.dynatrace.com needs onboarding. Export all existing extension configs, map them to deployment variables, create environments/xyz/terragrunt.hcl, and update SECRETS.md with the required secret keys."

The dynatrace-extensions skill provides the agent with the full module interface, variable schema, and credential-scrubbing rules — so it produces code that passes terragrunt validate on the first attempt rather than requiring manual correction.

The Outcome

What previously required hours of UI inspection, manual JSON transcription, and trial-and-error Terraform authoring now takes minutes.

Features:

• New environments are onboarded with a single prompt.
• Existing configs are versioned, reviewed, and deployed through a pull request.
• Six tenants, fully reconciled, with terragrunt plan returning valid information what will be changes or not.