Cloud Monitoring metrics
- Latest Dynatrace
- Explanation
Dynatrace ingests metrics from Google Cloud Monitoring for any service that publishes to a Cloud Monitoring namespace. A recommended set of metrics is enabled by default when you create a connection; you can change the selection at any time.
Use cases
- Monitor any Google Cloud service that publishes metrics to Cloud Monitoring — across all projects accessible to your connection.
- Use curated metric collection sets to collect the most relevant metrics per service out of the box, or define custom metrics for services not yet on the supported list.
- Query metrics via DQL in
Notebooks — filter by project, location, label, or tag, and correlate with GCP topology entities. - View metrics in context with their corresponding GCP resource entity in
Clouds.
Ingest method
Dynatrace polls the Cloud Monitoring API to ingest metrics.
Polling schedule
Dynatrace polls Cloud Monitoring every 5 minutes. Each poll reads a 5-minute window and starts less than 1 minute after the window ends, so that Cloud Monitoring can finish aggregating the data.
A data point reaches Dynatrace after this time at the latest:
sampling interval + ingest delay + 5 minutes + less than 1 minute
Google Cloud documents the sampling interval and the ingest delay for each metric in its metrics list.
For example, a metric that Google Cloud samples every 60 seconds and makes visible up to 240 seconds later reaches Dynatrace in under 11 minutes (60 s + 240 s + 300 s + under 60 s). On average it is faster, because a data point waits only half a polling interval.
Dynatrace does not accept metrics with a timestamp older than one hour at ingest time. Backfilling historical metric data is not supported. See OpenPipeline limits for the full timestamp acceptance window by signal type.
Metric collection scope
Choose which projects Dynatrace reads metrics from:
| Setting | Dynatrace reads metrics from | Choose it when |
|---|---|---|
| All | Every project visible to the connection, one project at a time | You don't use metrics scopes, or you want every project covered |
| Scoping | Only the scoping projects: projects whose metrics scope contains 2 or more projects (the project itself plus at least one other). Each returns the metrics of all projects in its scope | You already use metrics scopes and want fewer Cloud Monitoring API calls |
When you select Scoping, Dynatrace detects which of your projects are scoping projects by querying each visible project. Dynatrace caches the results, so changes to your Google Cloud metrics scopes can take some time to appear. Keep your metrics scopes free of overlaps and cycles.
All mode┌──────────────────────────────────────────────┐│ Visible projects ││ Project A · Project B · Project C │└───────────────────────┬──────────────────────┘┌─────────────┴─────────────┐▼ ▼Topology MetricsA, B, C A, B, C(all visible) (all visible)Scoping mode┌──────────────────────────────────────────────┐│ Visible projects ││ Project A (non-scoping) ││ Project B (scoping → A, C in scope) ││ Project C (non-scoping) ││ Project D (non-scoping, not in any scope)│└───────────────────────┬──────────────────────┘┌─────────────┴─────────────┐▼ ▼Topology MetricsA, B, C, D A, B, C(all visible) (via Project B —D not in anyscoping project)
Metric collection scope only controls which projects metrics are collected from. GCP topology discovery is not affected—Dynatrace discovers resources from all projects the connection has access to, regardless of metric scope configuration.
Metric collection sets
A metric collection set is a group of metrics assigned to a Google Cloud service. Once assigned, all metrics in that set are scheduled for polling.
Metric collection set types
- Recommended
An opinionated, curated selection of the most important metrics for each Google Cloud service. The optimal starting point. Enabled by default when you create a connection.
- Recommended + Custom
All Recommended metrics plus additional service-specific metrics you specify. Use this when you need metrics beyond the recommended set without collecting everything.
- Auto-discovery
All available metrics for a service are discovered and collected automatically.
Auto-discovery has a high potential to generate elevated Cloud Monitoring API costs and high DPS consumption in Dynatrace. Use it only to explore what metrics are available, then switch to Recommended or Recommended + Custom once you've identified the metrics you need. The more metrics you collect, the more Cloud Monitoring API quota you need. See GCP performance and quotas.
For supported services, Dynatrace only ingests Cloud Monitoring metrics for resources that are already stored in GCP topology (Smartscape on Grail, Dynatrace's topology store). If a resource has not yet been discovered — or has been removed from topology — its metrics are not collected.
If label- or tag-based include filters are configured on the connection, a resource must match those filters before Dynatrace discovers it and begins collecting its metrics. Label changes propagate to topology within minutes. Tag changes can take up to one hour. During this window, metrics for affected resources are not collected.
Metrics ingested via Ingest any Google Cloud Monitor metrics are exempt from this restriction only for resource types not in the supported services list. For supported resource types (for example, gce_instance), the topology requirement still applies.
Recommended services
In Recommended mode, metric collection is enabled for a curated set of services by default. For the full list, see Supported GCP services. To update metric collection on an existing connection, see Manage GCP connections.
Advanced metric ingest
For services or metrics not yet in the supported services list, you can enable Ingest any Google Cloud Monitor metrics on a connection to ingest any Cloud Monitoring metric directly by specifying a monitored resource type, metric type, and metric labels.
Metrics ingested via Ingest any Google Cloud Monitor metrics are not linked to topology entities and are not enriched with Google Cloud labels or tags. They are not viewable in Clouds.
Access metric data in Dynatrace
Access metrics in context with topology via Clouds, or query them via DQL in Notebooks.
Query metric data via DQL
Metric key format
Dynatrace derives the metric key from the GCP monitored resource type and metric type:
cloud.gcp.<resource_type>.<metric_domain_dots_as_underscores>.<metric_path_slashes_as_dots>
For example, the GCP metric compute.googleapis.com/instance/cpu/utilization on resource type gce_instance becomes:
cloud.gcp.gce_instance.compute_googleapis_com.instance.cpu.utilization
Query Compute Engine CPU utilization by project
timeseries avg(cloud.gcp.gce_instance.compute_googleapis_com.instance.cpu.utilization),by: {gcp.project.id, gcp.location}
Filter metrics by Google Cloud label
With label enrichment enabled, label values are available as metric dimensions.
timeseries avg(cloud.gcp.gce_instance.compute_googleapis_com.instance.cpu.utilization),by: {gcp.project.id, gcp.labels.environment, dt.smartscape_source.id}
The dt.smartscape_source.id dimension links each metric series to its corresponding Smartscape on Grail entity, enabling correlation with topology data from smartscapeNodes.
Signals in context
Metrics from supported services carry these attributes:
| Attribute | Description |
|---|---|
gcp.project.id | ID of the Google Cloud project. |
gcp.location | Location of the resource that produced the metric. |
gcp.labels.<key> | Resource label. Present when label enrichment is configured. |
gcp.tags.<key> | Resource tag. Present when tag enrichment is configured. |
dt.smartscape_source.id | ID of the Dynatrace topology entity this metric belongs to (for example, GCP_LOGGING_GOOGLEAPIS_COM_LOGSINK-F56B6F091D01F3DD). |
dt.smartscape_source.type | Type of the linked entity (for example, GCP_LOGGING_GOOGLEAPIS_COM_LOGSINK). |
Example metric data point (Compute Engine instance):
{"metric.key": "cloud.gcp.gce_instance.compute_googleapis_com.instance.cpu.utilization","gcp.project.id": "my-project","gcp.location": "us-central1-a","gcp.labels.environment": "production","dt.smartscape_source.id": "GCP_COMPUTE_GOOGLEAPIS_COM_INSTANCE-A1B2C3D4E5F6G7H8","dt.smartscape_source.type": "GCP_COMPUTE_GOOGLEAPIS_COM_INSTANCE","value": 0.42,"unit": "Ratio","interval": "5m"}
Enrichment timing
Enrichment requires the resource to be already discovered with up-to-date label and tag data. Telemetry arriving before discovery or before the latest labels and tags are available is ingested without enrichment. Use OpenPipeline rules to set defaults for missing attributes or drop unenriched records.
Cost considerations
Dynatrace pricing
Ingested Cloud Monitoring metrics count toward your Dynatrace metrics consumption. See the Dynatrace rate card for current metric ingest rates.
GCP topology (entities and relationships) is ingested at no additional Dynatrace cost.
Google Cloud pricing
Metric collection can cause charges in your Google Cloud environment for Cloud Monitoring. For details and current rates, see Google Cloud Observability pricing.
What's next?
View your GCP metrics in context with topology in Clouds, or query and correlate metrics with topology data in Notebooks.