same endpoint

[fstekelenburg]

Hi,

I could use some clarification on the last remark on the 'Managed Deployment' scenario's page
https://www.dynatrace.com/support/help/setup-and-configuration/dynatrace-managed/basic-concepts/mana...

The last line:

Note: Agentless Real User Monitoring, mobile-app monitoring, and synthetic monitors all use the same endpoint to transmit monitoring data to Dynatrace.

I am not completely clear on what is meant by "endpoint", and if this applies for both external and internal use. From outside resources I read endpoint as the entry point for the managed environment, hence a cluster activegate in a DMZ.

[Radoslaw_Szulgo · Accepted solution]

You configure the endpoint in your Cluster Management Console (CMC) in Settings -> Public endpoints. This is the endpoint that in fact should hit your Cluster ActiveGates. The endpoint should be available publicly (for Public (M)RUM) and internally.

What is meant by the docs, is that all data from RUM, mobile and Synthetic firstly hit Cluster AG (via configured endpoint) and then Cluster AG redirects the traffic to you cluster - exactly as you see on the diagram.

Is that clear? What other questions I can help you with?

[fstekelenburg]

HI Radoslaw, it is now clear to me that indeed the entity to receive the data first, here being the Cluster AG), is meant as endpoint.

For external data the Cluster AG(s) are placed in the DMZ, and I understand the concept that the different data sources use that as the same endpoint.

You state that "the endpoint should be available publicly (for Public (M)RUM) and internally". Does this mean that for internal purposes (environments) this very same endpoint must be used, in the DMZ? Thus traffic internal also to DMZ? I assumed an internal Cluster AG and Enviroment AG if necessary could handle internal traffic.

[Radoslaw_Szulgo]

Take a look here: https://www.dynatrace.com/support/help/shortlink/managed-deployment-scenarios#scenario-2-pure-dynatr...

In case you have only internal (M)RUM the same endpoint is used as Cluster AG serve as what we call "beacon forwarders" - that's the AG capability to route monitoring data from Synthetic and (M)RUM. No other AG type should be configured to handle this. I agree that this may in your case route the traffic redundantly to DMZ back and forth. Currently you can:

1) Attach to the endpoint both publicly reachable IPs and internal ones. You then leave resolving proper AG address to DNS

2) Use Load Balancer in front and configure the endpoint to the Load Balancer. Then Load Balancer redirects traffic to either DMZ Cluster AG or internal Cluster AG based on the client IP or sth else

3) Use a separate cluster for internal RUM and separate for external RUM.

Hope this helps or inspires to find an optimal solution.

[fstekelenburg]

my reply ended up as answer above, sorry 🙂

[Radoslaw_Szulgo]

converted to comment 😉 yw.

[fstekelenburg]

thanx! my second update disappeared?

[Radoslaw_Szulgo]

haven't seen anything else

[fstekelenburg]

retried and updated. if you have a chance to look at it, and the first?

[fstekelenburg]

Hi @Radoslaw S.,

Both external and internal (M)RUM is the concept I am looking at.

Up forehand, is configuring internal websites with an adjusted agentless javascript tag (agentUri, reportUrl) in some situations a possible 4th solution? (Mainly thinking development and test, I try to avoid customizations as much as possible :)).

Sorry for all the questions, but I want to understand the concept through and through 😉

So as you explained and according the documentation, per cluster you can only define one
Cluster ActiveGate URL. And for all environments managed by this cluster, all the M(RUM) agents point to the same, this URL.
(The URL should be a FQDN with valid certificate to allow secure (SSL/443) communication.)

In the most basic situation that means when external and internal (M)RUM is used, the internal agents will try to contact the URL on the public/outside IP address, according DNS [1].
Unless in internal DNS the URL DNS name resolves to the internal IP (of the CAG(s)). Then the internal address is used - if configured on the CAGs. [2] Which may have some security implications.

I visualized it as follows, is this correct?:

[fstekelenburg]

Is it so that (additional) internal Cluster AG's do not necessarily need to be technically in the DMZ, if the endpoint's DNS address internally resolves to such local address? Same principal, but DNS determines where data gets send to (as depicted below). Is this correct?

[Radoslaw_Szulgo]

IMHO looks good, should work.

[fstekelenburg]

But what I also was thinking @Radoslaw S., is that (one of) the Cluster ActiveGates may not necessarily need to be in the DMZ, but can reside in the internal zone somewhere.
The internal DNS points to the IP of this CAG endpoint. Technically then not being the same endpoint as the external traffic. Would that work?

[vinnu_arige_moe]

hi quick question how routing works on public end point url

If a user from my enterprise hits public end point url https://xxx/dynatracemanaged.com/ to access APM web ui how does the routing works

Option 1: does user request go to cluster internally and resolve the url ?

Option 2: does user request go to dynatrace.com and resolve the url and come back to managed cluster ?

Can you explain how it works ?

thanks

Vinnu