Differences in Apigee proxy traffic metrics between Dynatrace and Google Cloud Monitoring

[vchitti]

Hello Community,

I’m working with Apigee metrics in Dynatrace and I’ve noticed some differences compared to what I see in Google Cloud Monitoring. Specifically, I’m looking at the proxy traffic metric:

• In Dynatrace: cloud.gcp.apigee_googleapis_com.proxyv2.request_count

• In Google Cloud Monitoring: /proxy/request_count

When I query these metrics for the same proxy and environment, the numbers don’t always line up. In most cases, Dynatrace seems to report higher totals than Cloud Monitoring, and I’m trying to understand why.

My questions are:

• Are there differences in how Dynatrace ingests or aggregates Apigee metrics compared to Google Cloud Monitoring?

• Does Dynatrace includes every traced hop (eg: backend calls, retries, OAuth, ServiceCallout etc)

• Is there any guidance on how to reconcile request counts between Dynatrace and Google Cloud Monitoring so that dashboards and alerts are consistent?

Any insights or best practices from others who have compared these two would be really helpful.

Thanks in advance!

[JeanBlanc]

Hi @vchitti,

Good question. Based on Dynatrace documentation and how GCP metric ingestion works, the difference you’re seeing is possible, but it can’t be explained without looking at metric semantics and aggregation behavior.

A few important points to keep in mind:

• Metric origin

  • cloud.gcp.apigee_googleapis_com.proxyv2.request_count in Dynatrace is ingested from Google Cloud Monitoring, not calculated by Dynatrace itself.

  • Dynatrace relies on the values returned by the GCP Monitoring API and then applies its own time alignment and roll-up logic.

  • Google Cloud Monitoring UI may display the same metric using a different alignment period or aggregation function.

• Aggregation and alignment

  • Differences often come from alignment period (per-minute vs per-window) and whether the metric is treated as delta vs cumulative.

  • Even with the same metric name, querying with different alignment settings can lead to higher totals on one side.

• Internal hops / retries

  • Dynatrace does not trace Apigee internal hops (OAuth, ServiceCallout, backend retries, etc.) at the proxy runtime level.

  • If those are included, they would already be reflected in the source GCP metric, not added by Dynatrace.

  • So Dynatrace itself should not be counting “extra hops”, but the metric definition itself needs to be confirmed.

• Reconciliation guidance

  • To get consistent numbers, make sure:

    • You use the same alignment period and aggregation in Dynatrace as in Cloud Monitoring

    • You compare over longer time windows

    • You verify whether the metric is cumulative or delta in both tools

At this point, it’s safest to say the difference is most likely due to aggregation/alignment differences, not additional tracing done by Dynatrace.

If you can share:

• The alignment/rollup used in Dynatrace

• The exact aggregation settings in Cloud Monitoring

then it should be possible to confirm whether the numbers are expected to match or not.

FYI : @achoud22 talks about a similar issue : https://community.dynatrace.com/t5/Open-Q-A/Proxy-Request-Metrics-in-Dynatrace-Are-Almost-Double-Com...

Best regards,