Proxy Request Metrics in Dynatrace Are Almost Double Compared to Apigee

[achoud22]

We are observing a significant discrepancy in proxy request metrics across different monitoring tools. Specifically:

• Dynatrace shows almost double the request count compared to Apigee for the same time window.
• All tools are configured to monitor the same proxy endpoints.
• Time ranges and environments have been verified to match.

Has anyone encountered similar differences?
Could this be due to:

• Retries or internal hops being counted by Dynatrace?
• Differences in metric aggregation or sampling?
• Instrumentation at multiple layers (e.g., process vs service)?

Dynatrace metric values-

Apigee metric values -

[JeanBlanc]

Hi @achoud22,

This kind of difference can happen, but it really depends on which Apigee metrics Dynatrace is ingesting and how they are defined.

Dynatrace does not measure Apigee traffic directly at the proxy runtime level. It collects aggregated metrics via APIs (Apigee Analytics API or GCP Monitoring), so the values are not always strictly equivalent to what you see in the Apigee UI.

A few points worth checking before drawing conclusions:

• Are both tools showing the same metric definition (e.g. proxy requests vs messages processed)?

• Which Dynatrace integration is used (Apigee extension - https://www.dynatrace.com/hub/detail/apigee vs GCP Monitoring)?

• Does the difference still exist over a longer time window (15–60 minutes)?

• Are there retry or fault policies enabled in the proxies that could affect counts?

Without aligning the metric source and definition, a 1:1 comparison between Dynatrace and Apigee request counts can be misleading.

If you can share the exact Dynatrace metric name and the Apigee metric you’re comparing against, it will be easier to confirm whether the numbers should match or not.