Bidirectional Synthetic Monitoring (cloud evni ↔ OnPrem) and Correlated Alerting Best Practice

gauravpayghan — Wed, 12 Aug 2026 06:25:50 GMT

We are designing bidirectional synthetic monitoring where:

AWS environment monitors 2 endpoints hosted in OnPrem
OnPrem environment monitors 2 endpoints hosted in AWS

We are evaluating the best monitoring approach:

DNS Network Monitor
TCP Network Monitor
HTTP GET
HTTP POST (transaction validation)

One view is that DNS validation is sufficient since every HTTP/TCP request requires DNS resolution and some cloud-native workloads (e.g., Kubernetes/EKS) may have dynamic backend IPs. Another view is that DNS-only monitoring doesn't truly validate traffic flow, application reachability, or service availability. "We are goona use Private AG for the configuration - suggest best prectice(the requirements is like - to validate the flow from each DC to another DC hosted urls,api - major thing is to validate the flow is up and running) and also suggest if we configure the url-api for synthetic endpoint with get call then which code can be used so it can denote the network flow or traffic is not right like 504 only? do suggest."

Questions

From a Dynatrace architecture perspective, what is the recommended approach for validating cross-environment flow and availability?
- DNS
- TCP
- HTTP GET
- HTTP POST
- Combination of approaches
Is DNS-only monitoring considered sufficient for availability validation, or should it only be a supporting signal?
For cloud-native applications where backend IPs change frequently, is hostname-based monitoring via HTTP/TCP the preferred approach?
We want to create a single problem card only when:
- Multiple synthetic endpoints fail (4 endpoints across 2 environments)
- A related service simultaneously shows elevated failure/error rates

What is the recommended correlation approach in Dynatrace?

Davis AI
Metric Events / Anomaly Detection
DQL Events
Workflows
Combination of the above

Looking for best practices and real-world implementations.

Re: Bidirectional Synthetic Monitoring (cloud evni ↔ OnPrem) and Correlated Alerting Best Practice

sujit_k_singh — Thu, 10 Sep 2026 06:21:17 GMT

Hi @gauravpayghan

I'm not sure if you're still seeking an answer; however, I'll share my thoughts in case it's still helpful.

From a Dynatrace architecture perspective, what is the recommended approach for validating cross-environment flow and availability? Combination of approaches specifically HTTP GET + TCP as minimum, with DNS as a supporting signal only.
Is DNS-only monitoring considered sufficient for availability validation, or should it only be a supporting signal? No. DNS-only is not sufficient for availability validation. It only confirms that a hostname resolves to an IP. DNS should be used only as a supplementary diagnostic signal, not as a primary availability check.
For cloud-native applications where backend IPs change frequently, is hostname-based monitoring via HTTP/TCP the preferred approach? Yes, hostname-based HTTP/TCP is the correct approach
What is the recommended correlation approach in Dynatrace? Recommended: Combination of Davis AI + Metric Events + Workflows

Why not DQL Events as primary? DQL Events are better suited for log-based or custom telemetry signals not for synthetic + service correlation.

Thanks,

Sujit

topic Re: Bidirectional Synthetic Monitoring (cloud evni ↔ OnPrem) and Correlated Alerting Best Practice in Open Q&A

Bidirectional Synthetic Monitoring (cloud evni ↔ OnPrem) and Correlated Alerting Best Practice

Questions

Re: Bidirectional Synthetic Monitoring (cloud evni ↔ OnPrem) and Correlated Alerting Best Practice