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

**URL:** <https://community.dynatrace.com/t/bidirectional-synthetic-monitoring-cloud-evni-onprem-and-correlated-alerting-best-practice/56691>\
**Category:** Open Q&A\
**Tags:** dql, anomaly-detection, problems, synthetic-monitoring\
**Created:** [August 11, 2026, 4:23pm UTC](https://community.dynatrace.com/t/bidirectional-synthetic-monitoring-cloud-evni-onprem-and-correlated-alerting-best-practice/56691 "2026-08-11T16:23:08Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![gauravpayghan](https://avatars.discourse-cdn.com/v4/letter/g/e19adc/32.png) [@gauravpayghan](https://community.dynatrace.com/u/gauravpayghan)\
**Post date:** [August 11, 2026, 4:23pm UTC](https://community.dynatrace.com/t/bidirectional-synthetic-monitoring-cloud-evni-onprem-and-correlated-alerting-best-practice/56691/1 "2026-08-11T16:23:08Z")

</div>

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

1. 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

2. Is DNS-only monitoring considered sufficient for availability validation, or should it only be a supporting signal?
3. For cloud-native applications where backend IPs change frequently, is hostname-based monitoring via HTTP/TCP the preferred approach?
4. 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.

---

<div class="post-metadata">

**Author:** ![sujit\_k\_singh](https://avatars.discourse-cdn.com/v4/letter/s/34f0e0/32.png) [@sujit\_k\_singh](https://community.dynatrace.com/u/sujit_k_singh)\
**Post date:** [September 10, 2026, 6:21am UTC](https://community.dynatrace.com/t/bidirectional-synthetic-monitoring-cloud-evni-onprem-and-correlated-alerting-best-practice/56691/2 "2026-09-10T06:21:17Z")

</div>

Hi&nbsp;[@gauravpayghan](https://community.dynatrace.com/user/103617)

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

1. From a Dynatrace architecture perspective, what is the recommended approach for validating cross-environment flow and availability?&nbsp;Combination of approaches specifically HTTP GET + TCP as minimum, with DNS as a supporting signal only.
2. Is DNS-only monitoring considered sufficient for availability validation, or should it only be a supporting signal?&nbsp;No. DNS-only is not sufficient for availability validation. It only confirms that a hostname resolves to an IP.&nbsp;DNS should be used only as a supplementary diagnostic signal, not as a primary availability check.
3. For cloud-native applications where backend IPs change frequently, is hostname-based monitoring via HTTP/TCP the preferred approach?&nbsp;Yes, hostname-based HTTP/TCP is the correct approach
4. What is the recommended correlation approach in Dynatrace?&nbsp;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