11 Aug 2026
05:23 PM
- last edited on
12 Aug 2026
07:25 AM
by
MaciejNeumann
We are designing bidirectional synthetic monitoring where:
We are evaluating the best monitoring approach:
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."
From a Dynatrace architecture perspective, what is the recommended approach for validating cross-environment flow and availability?
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:
What is the recommended correlation approach in Dynatrace?
Looking for best practices and real-world implementations.
10 Sep 2026 07:21 AM
I'm not sure if you're still seeking an answer; however, I'll share my thoughts in case it's still helpful.
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
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
Featured Posts