I have following network flow:-
1) browser ->
2) F5 (company.com/myapp1) -> (not in my control)
3) Apache (reverse proxy) -> (not in my control)
4) istio gateway (prod.istio.company.com/group/webapp1) mesh -> (can control virtual hosts/routing/headers only)
5) kubenetes pods (istio mesh) -> (full control)
6) inside pods - nginx - serves static urls (full control over nginx)
URL remains same as original in the browser.
Step 4,5,6 is in kubernetes and may qualify for dynatrace instrumentation.
We host dynatrace (i.e. managed).
Created a Web application with full URL detection https://company.com/myapp1/
When I visit myapp1 from browser I see nothing injected in there.
Then went through Tips For Troubleshooting https://www.dynatrace.com/support/help/how-to-use-dynatrace/real-user-monitoring/setup-and-configura...
1) It says go to Settings > Monitoring > Monitoring overview but I don't see Settings
(is it a role issue ? rant: why don't you guys provide a disabled menu or provide a documentation warning).
2) Other steps are to check if this qualifies:
3) What can I do if an uninstrumented component rewrites parts of the URL? What can I do if an uninstrumented component rewrites parts of the URL?
I went through this and it says I need a header X-Forwarded-Host or Forwarded header with www.company.com ? Why does dynatrace need this information - which i going to be same as in the url detection rule or should it be "prod.istio.company.com/group/webapp1" ?
BIG QUESTION: How does Dynatrace actually inject the <script into my index.html ? Does it do network sniffing ? Or somehow figures out my kubernetes hosts and installs the OneAgent which does some magic lol?
Is it sufficient to add Forwarded header into the response at my Step 4) to say company.com for automatic injection?
Solved! Go to Solution.
Hi Community! This post shades light on really interesting pain journey. Would be great to catch attention someone's attention who has some helpful tips! 😃
1) Yes this is a permission topic. If you don't have the environment settings permissions you don't see it.
It turned out to be 2 things for me:-
1) nginx version downgrade
2) Setting `x-dynatrace-origin-url` to my app url configured in the detection settings.
3) Can't say if `X-Forwarded-Host` and `X-Forwarded-Path` request headers also helped but I have them.
Yup the sad part is that it is a magic and indeterministic IMO.
1) Yes if you run latest you might run into issues on managed
3) Yes, X-Forwarded-Host is one of the headers used by dynatrace to determine the original URL
I'd use the quote any "Any sufficiently advanced technology is indistinguishable from magic."
It's pretty easy, though can be quite baffling if one does not know how it works. It just looks at the HTML your web/app servers delivers and modifies it, if an application rule is present.