Automatic RUM Injection - Failing with 503 due to no html being served at the context-root of URL

[NickC123]

We have multiple applications that have no html served at the context-root of our URL, hence ruxitagentjs returning a 503 as it defaults to the context-root. 

I'm aware than I can specify a path under settings -> Injection -> Specify path for RUM monitoring code, however, this would pin the initial RUM request to a single microservice that serves that URL - essentially causing a single point of failure/a dependency on a microservice that wasn't intended to be used for this purpose.

Is it actually possible to implement automatic rum injection where no html is served at the context-root of a URL without specifying a path for the initial RUM request to occur from? 

Regards, 

Nick 

[MargitM]

On Java and IIS, the context root is used if available. On the other technologies, the root / is used and you need to configure this setting if you want a different path. If you want to avoid the dependency on the Microservice, you can have the RUM JavaScript delivered by the Dynatrace CDN (SaaS) or your CDN (Managed): Request the monitoring code from the Dynatrace CDN

[NickC123]

Hi Margit, 

Thanks for the response.

OneAgent is the only option we have as a code source; 

Regards, 

Nick

[MargitM]

This means that one or more old ActiveGates are connected, or they were connected until recently and the minActiveGateVersion hasn't been increased yet. As mentioned in the docs, the feature only becomes available automatically if all connected ActiveGates have been on version 1.310+ for at least 30 days. Support can check the current minActiveGateVersion on your tenant and advise on the next steps toward enabling the CDN feature.

[NickC123]

Margit, 

Thanks for the response. 

Assuming the RUM js was delivered by the CDN, would this essentially bypass the need to have html served at the context-root? 

Regards, 

Nick 

[MargitM]

To get rid of all RUM requests to the root / (or context root in case of Java and IIS), you'd also have to take care of the RUM beacon requests, which are also sent there unless you configure the path as described in Modify the beacon endpoint URL . But here, too, it is possible to let Dynatrace infrastructure handle the requests: Send beacons to Dynatrace SaaS infrastructure 

[NickC123]

Yes that was going to be my next question - we tried this during debugging and faced CSP violations but that's a different topic! This has been super helpful - thank you. 

With the above in mind, assuming that a context-root exists and the pods serving the html for the context-root fail/crash, does RUM fail entirely?  

Regards, 

Nick

[MargitM]

Would this be a scenario where you leave the default setting for the code source and the beacon endpoint and you deploy HTML on / to make the requests for the RUM JavaScript and the beacons succeed? If all of the pods crashed where the requests to / are rooted, then yes, RUM capturing would fail, since neither the monitoring code would be delivered nor the beacon requests would be handled. So you'll need to either ensure sufficient pod redundancy or configure code source and beacon endpoint.

[NickC123]

Very sorry, my scenario probably wasn't that clear. Setup as follows; 

Dynatrace application - automatic injection configured with defaults.

• Code source: default
• Beacon endpoint: default 

Infrastructure

• Pod A - serving: domain.com
• Pod B - serving: domain.com/somedomain
• Pod C - serving: domain.com/somedomain/testing

As I understand it, the code source/beacon endpoint would default to Pod A, unless specified otherwise.

So assuming 0 redundancy of Pod A - Pod A crashes - RUM is lost. 

Is that correct? 

Regards, 

Nick

[MargitM]

Hi Nick,

to get the full picture: Is there an ingress controller in front of the pods, maybe an Nginx? And which technologies are used in the microservices?

Regards,

Margit

[NickC123]

Margit, 

For sure - let's say in this instance it's nginx and an angular frontend!

Regards, 

Nick

[MargitM · Accepted solution]

Only server-side technologies are relevant.

If you have the Nginx as an ingress controller in front of the pods, then the RUM JavaScript requests and RUM beacons shouldn't actually reach the pods at all. They should be intercepted by the OneAgent on the Nginx before they can be proxied to the pods. Otherwise, this would be an issue that should be investigated.

If, on the other hand,

• there is no Nginx ingress controller in front of the pods but some other technology without OneAgent RUM support that roots the URLs to the pods
• each pod has an Nginx
• this Nginx is the only server-side technology used there (in particular, no Java behind the Nginx)

then each Nginx would inject the code source and beacon path /, and the requests would go to Pod A. If Pod A crashed, this would break RUM.

If we change the latter scenario to also contain Java behind the Nginx, then things are different. Assuming that the /somedomain and /somedomain/testing URLs are actually context roots for applications on the Java tier, they'd be injected as code source and beacon URL. In this case, assuming prefix based mapping of URLs to pods, the requests would be handled on Pod B and Pod C, not Pod A. And when those crash, then your application is down anyway.

Again assuming prefix based mapping of URLs to pods, you could achieve the same behavior in the Nginx only scenario by configuring a path segment as a relative URL in of the „Specify path for RUM monitoring code“ setting, for example „rum“ (not „/rum“, which would be root relative). Then the requests for the RUM JavaScript would have the URL paths  /somedomain/rum/ruxitagentjs_version_hash.js and /somedomain/testing/rum/ruxitagentjs_version_hash.js and would be handled on Pod B and Pod C. You can also configure "./" as the code source and beacon URL, which makes it possible to have a relative URL without an additional path segment in the URLs at all.

[NickC123]

Margit,

Thanks for this - it's all incredibly helpful. So, in this instance (and in our real-world app) scenario, each pod has an Nginx and nothing serving the context-root, hence the 503.

Is it possible/do you think it would be possible for the code source/beacon URL location to be inherited from the application-detection settings, rather than defaulting to context-root? The reason I ask is that the respective infrastructure would then handle any associated RUM requests, dependent on the URL that the user hits, in a distributed manner. Defaulting to the context-root also assumes a few things which may also then be taken care of;

1) that html is served from the context-root

2) that the infra is adequately resourced/resilient

3) that the infra is not ephemeral

This would essentially remove the dependency on a single service and the application team needing to ensure that service remains available for RUM purposes (something they’re not designed for).

I might be going down a rabbit hole here – so please correct me if I’m misunderstanding!!

Regards, 

Nick 

[MargitM]

---

@NickC123 wrote:

Is it possible/do you think it would be possible for the code source/beacon URL location to be inherited from the application-detection settings, rather than defaulting to context-root?

Do you mean that when you create an application detection rule like URL contains /somedomain/testing, this pattern would automatically be used for the code source/beacon URL?

We don’t provide such a feature. Implementing it in a meaningful way would be quite challenging, because:

• You can define multiple application detection rules for a single application, which makes it unclear which one should be used for the code source/beacon URL.
• Application detection rules support several different matchers. These match not just URL paths, but can match other parts of the URL as well.

This approach would also be very specific to your scenario and wouldn’t address common use cases for most customers. For now, the most reliable method is to configure the code source/beacon URL explicitly to ensure predictable behavior.

[NickC123]

So in the context of the 'contains' operator, I agree it would be tricky to pin it down to where the DT traffic 'should' run from – especially in the case of a vague rule.

But assume in my example, I use URL 'equals' domain.com/somedomain/testing as the application detection setting, would it not make more sense for the default to be that code source/beacon URL is served by Pod C, rather than Pod A?

Appreciate we could implement the workarounds (specify the path etc) here, but just trying to understand why the default logic works as it does? Is it simply because it can only use one location for the code source/beacon URL?

[MargitM]

Hi Nick,

the current defaults are designed to work well across the vast majority of customer environments—which they do. For other setups, we offer configuration options that are part of the standard setup process, not workarounds.

In this conversation, I’ve outlined two configuration options that should suit your environment. Our support team can help you implement one of them through your open ticket.

If you feel the available options don’t meet your requirements and have ideas for improvement, I’d recommend posting a product idea in the community. This allows product management to gauge broader demand.

Best regards,
Margit

[KiranSomanatti · Accepted solution]

Hello Nick,

Cross-posting Margit's findings of an easier solution in this scenario:

Both the JS code source and the beacon URL can be configured to ./ , which makes it possible to have a relative URL without an additional path segment in the URLs at all

[NickC123]

Kiran/Margit, 

For sure - appears to be working nicely in our applications that had previously displayed the issues mentioned above. Would definitely get this posted to the documentation pages for other customers to know about. 

Thanks for the help. 

Regards, 

Nick