topic Re: Differences in Apigee proxy traffic metrics between Dynatrace and Google Cloud Monitoring in Extensions

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

vchitti — Fri, 12 Dec 2025 07:29:38 GMT

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!

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

JeanBlanc — Fri, 12 Dec 2025 14:09:21 GMT

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-Compared-to/td-p/291356

Best regards,

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

vchitti — Mon, 15 Dec 2025 12:02:03 GMT

Thank you for your reply. @achoud22 is our team member you can ignore and will close that ticket. sorry for the duplicate post.

Please find below queries used to get the metrics.

1. We are using same environment, proxy, time window (1 hr duration)

2. Query :

timeseries {

totalTraffic = sum(cloud.gcp.apigee_googleapis_com.proxyv2.request_count, scalar: true)},

filter: { matchesValue(env, "api-platform-production")

AND

matchesValue(proxy_name, "inspire-customer-voice-customer-voice-apigee") },

by: {cloud.gcp.apigee_googleapis_com.proxyv2.request_count},

from:-1h

The above query gives total count as 337 approx

Cloud Monitoring Api Metrics: 183 approx

Grafana: Count is 182 approx

sum(count_over_time({job="apigeelog", cluster="services", environment=~"$ENV", proxy_name=~"$API"}

|~ "$search"

[$__range]))

So, the cloud api metrics and grafana nearly equal. Its the DQL returning higher number.

Let me know if you need more information.

Thanks

Vam