Try it free

Manage GCP connections via gcloud CLI and dtctl

  • Latest Dynatrace
  • How-to guide

The commands on this page use the variables from Environment variables.

Update monitoring settings

To modify a monitoring configuration, export it as YAML, edit the file, and apply the changes.

  1. Get the configuration ID:

    dtctl get gcp monitoring
  2. Export to YAML:

    dtctl get gcp monitoring <configuration-id> -o yaml > config.yaml
  3. Edit config.yaml. Example structure:

    objectid: 0e184789-2f81-34ed-9358-c6b4e47f0def
    scope: integration-gcp
    value:
    enabled: true
    description: my-gcp-monitoring
    googlecloud:
    locationfiltering:
    - us-central1
    - us-east1
    - europe-west1
    projectfiltering: []
    folderfiltering: []
    featuresets:
    - compute_engine_essential
    - cloud_run_essential
    - cloud_sql_essential

    For the full list of configuration properties, see the monitoring configuration reference.

  4. Apply the updated configuration:

    dtctl apply -f config.yaml

Discover available options

List available GCP regions:

dtctl get gcp monitoring-locations

List available feature sets (services to monitor):

dtctl get gcp monitoring-feature-sets

Custom resources and metrics

Ingest metrics from Google Cloud resource types not covered by the default feature sets, either by enabling auto-discovery for them or by selecting specific individual metrics.

To customize resources, export your configuration to YAML, add the resources section under value.googlecloud, and apply. Example:

value:
googlecloud:
# ... existing configuration ...
resources:
# Auto-discovery: collect all available metrics for this resource type
- resourcetype: gcs_bucket
autodiscoveryenabled: true
# Specific metrics only
- resourcetype: pubsub_topic
autodiscoveryenabled: false
metrics:
- name: pubsub.googleapis.com/topic/send_request_count
metriclabels:
- response_class
type: CUSTOM
- name: pubsub.googleapis.com/topic/message_sizes
type: CUSTOM
# Auto-discovery with exclusions
- resourcetype: gce_instance
autodiscoveryenabled: true
autodiscoveryexcludemetrictype:
- compute.googleapis.com/instance/disk/*
FieldDescription
resourcetypeGoogle Cloud monitored resource type (for example, gcs_bucket, gce_instance)
autodiscoveryenabledtrue to collect all available metrics for this resource type; false to collect only the metrics listed under metrics
metricsList of specific metrics to collect (used when auto-discovery is off). Each entry has name (the full Cloud Monitoring metric type), an optional metriclabels list, and type (set CUSTOM for a metric you add manually)
autodiscoveryexcludemetrictypeMetric type prefixes to exclude when auto-discovery is on (for example, compute.googleapis.com/instance/disk/*)

Per-metric selection requires a dtctl version that models custom metrics. Older versions drop the metrics field on get and apply — verify with dtctl get gcp monitoring <name> -o yaml that the metrics entries are present before editing and re-applying.

Expand monitoring scope

To add projects, folders, or organizations to an existing connection, grant the required roles to your monitoring service account on each new scope. Use the same commands as in the initial setup, and repeat them for each new project, folder, or organization:

  • Project-level access
  • Folder-level access
  • Organization-level access

If your monitoring configuration filters projects or folders (projectfiltering, folderfiltering), add the new scope there too — see Update monitoring settings.

If you use the asset inventory feed, create a feed for the new scope too, so that topology updates arrive in near real time. See Enable or update asset inventory feed. Without a feed, Dynatrace picks up the new resources with the next hourly snapshot.

Enable log forwarding

Log forwarding requires deploying a Cloud Logging sink, Pub/Sub topic, and Dataflow streaming job in your Google Cloud project. Follow the Set up log forwarding steps from the initial setup guide.

After the infrastructure is deployed, update the monitoring configuration to enable log forwarding by setting the relevant property in config.yaml and applying via dtctl apply -f config.yaml.

Enable or update asset inventory feed

To deploy the asset inventory feed for the first time, follow the Set up the asset inventory feed steps from the initial setup guide.

To update an existing feed — add or remove tracked asset types — address the feed by the scope where you created it. Each command takes exactly one of --project, --folder, or --organization. If you created feeds in more than one scope, repeat the commands for each scope.

# Choose the scope of the feed you want to update (use exactly one)
SCOPE_FLAG="--project=${PROJECT_ID}" # project-scope feed
# SCOPE_FLAG="--folder=${FOLDER_ID}" # folder-scope feed
# SCOPE_FLAG="--organization=${ORG_ID}" # organization-scope feed
gcloud asset feeds update dt-asset-feed-${MCONFIG_ID} \
${SCOPE_FLAG} \
--add-asset-types="<asset-type>" # for example, a type from the Cloud Asset supported-types list

To remove an asset type:

gcloud asset feeds update dt-asset-feed-${MCONFIG_ID} \
${SCOPE_FLAG} \
--remove-asset-types="<asset-type>"

Verify the current feed configuration:

gcloud asset feeds describe dt-asset-feed-${MCONFIG_ID} ${SCOPE_FLAG}

Rotate Log Ingest token

If your Log Ingest token has expired or been revoked:

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

  2. Update the token in Secret Manager:

    echo -n "dt0c01.NEW_TOKEN_VALUE" | gcloud secrets versions add \
    dt-logs-api-token-${MCONFIG_ID} \
    --data-file=- \
    --project=${PROJECT_ID}
  3. Restart the Dataflow job so it picks up the new token. Drain the running job first. A drained job finishes the log entries already in the pipeline before it stops:

    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 launch the job again with the command from Set up log forwarding. While the job is stopped, log entries wait in the Pub/Sub subscription for up to 7 days and are forwarded when the new job is running.

Pause and resume monitoring

To pause monitoring without deleting the configuration, disable it:

dtctl disable gcp monitoring <configuration-id>

This disables the configuration and its credentials. To resume, enable it again:

dtctl enable gcp monitoring <configuration-id>

Pair dtctl disable with dtctl enable. If you disable with dtctl disable and then set value.enabled back to true in the YAML, the credentials stay disabled and monitoring doesn't resume.

Update the extension

The GCP monitoring extension (com.dynatrace.extension.da-gcp) is installed from the Dynatrace Hub. Monitoring configurations are version-pinned — installing a newer extension version does not automatically migrate existing configurations. You must explicitly update them.

1. Check the latest installed version

EXT="com.dynatrace.extension.da-gcp"
LATEST=$(dtctl get extension "$EXT" --no-agent -o json \
| jq -r '.[].version' | sort -V | tail -1)
echo "Latest installed: $LATEST"

2. Install a new version from Hub

If you haven't activated the extension yet, see Prerequisites.

# Install latest available
dtctl create extension --hub-extension "$EXT"
# Install a specific version
dtctl create extension --hub-extension "$EXT" --version 1.2.0

3. Migrate monitoring configurations to the new version

Migrate all monitoring configs

EXT="com.dynatrace.extension.da-gcp"
LATEST=$(dtctl get extension "$EXT" --no-agent -o json \
| jq -r '.[].version' | sort -V | tail -1)
dtctl get extension-configs "$EXT" --no-agent -o json | jq -c '.[]' | while read -r cfg; do
ID=$(echo "$cfg" | jq -r '.objectId')
CURRENT=$(echo "$cfg" | jq -r '.value.version')
if [ "$CURRENT" = "$LATEST" ]; then
echo "SKIP $ID (already $LATEST)"
continue
fi
echo "UPGRADE $ID: $CURRENT → $LATEST"
TMPFILE=$(mktemp /tmp/extcfg_XXXXXX.json)
echo "$cfg" | jq --arg v "$LATEST" '.value.version = $v' > "$TMPFILE"
dtctl apply extension-config "$EXT" -f "$TMPFILE"
rm "$TMPFILE"
done

Delete a connection

Delete the Dynatrace connection and its monitoring configuration in the Settings app. See Delete a connection.

Deleting the connection in Dynatrace doesn't remove anything in Google Cloud. You must also delete the Google Cloud resources that you created for the connection, for example the service account, IAM bindings, Pub/Sub topics and subscriptions, Dataflow job, asset feeds, log sinks, and Cloud Storage buckets. Deleting them is your responsibility. Delete the connection in Dynatrace first, so that Dynatrace doesn't try to authenticate against resources that no longer exist.

If you deployed with Terraform, run terraform destroy from the bundle directory. It removes the resources that Terraform created. Adapt the cleanup to your own changes: Terraform doesn't know about resources you added or changed yourself, such as log sinks, so remove those yourself.

Related tags
Infrastructure Observability