Open Q&A
If there's no good subforum for your question - ask it here!
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

gauravpayghan
Visitor

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.

1 REPLY 1

sujit_k_singh
Leader

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.

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

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

Dynatrace Professional Certified

Featured Posts