For agent traffic a load balancer is not required for Managed.
However some customers want to put a load balancer for the web UI.
Are there any requirements for the LB on that end?
Probing url (e.g.: /login)
Stickiness: source and destination IP / HTTP cookie / HTTP header / SSL Id
Thanks for your input!
Solved! Go to Solution.
Hey Kris, we are now working in development to include NginX to serve ui pages, keep session stickiness and load balance. This will be available ~ version 134 or 136.
Handling LB by customer may be challenging to have up-to-date configuration when nodes are being added or removed, certificates management etc.
More details: @Krzysztof S.
if customer wants to setup his own load balancer / reverse proxy, for sure he needs to configure it with sticky session support, as there is no session persistence (yet) on Dynatrace Managed side. As Radoslaw mentioned, there are plans to release LB out of the box in first quarter of 2018.
Regarding the configuration details - for sticky sessions we'd recommend cookie-based approach as most reliable.
For health checks, /rest/health is the best option.
All the paths must be forwarded without modifications.
Customer would need to also take care of domain and SSL certificate configuration for the LB.
Currently testing with that configuration:
|Type in HTTP Cookie:||jsessionid|
|Probing return code::||200 http|
|Request method (for HTTP only):||get|
regarding the cookie name - no special requirements other than avoiding collision with any name already used by Dynatrace. We do not use jsessionid so it is ok from that perspective, perhaps a bit misleading as this is used by default by Java application servers.
The cookie should be also marked as secure so that it is only transferred using HTTPS.
Customer wants to use something like https://customerdomain.com/dynatrace in their LB configuration. Is that something we can do? The login page shows up fine but user cannot login as the rb_xxxx.js file gets a 403 as it is requested from https://customerdomain.com and not from within /dynatrace. And the environments also get served from the domain directly and not /dynatrace.
In the CMC I put https://customerdomain.com/dynatrace in the Web UI URL but that does not help.
Thanks for your inputs!
Created an RFE to support this: https://answers.dynatrace.com/spaces/483/dynatrace-product-ideas/idea/192584/rfe-change-context-root-of-dynatrace-web-ui-and-ap.html
It is quite important for a rather large customer.
I'm currently using a WebGUI loadbalacing with the stickyness based on the Dynatrace cookie apmsessionid, main time that's working fine but some time is failing saying your are not authenticate in the middle of a session. In that case, in the browse development mode I can see that's coming from JSON file download which are not using any cookie so the stickiness doesn't work anymore.