Dedicated container in Kubernetes for Dynatrace RUM

[gmichels]

Hello everyone,

I'd like to have a dedicated container running nginx in Kubernetes, specific for serving the JavaScript agent files and receiving the beacon data from the browser POSTs. I would go into the Dynatrace application advanced settings in the UI and manually set the JavaScript library location and beacon path to match the network location of this container:

Keep in mind I wouldn't have any application or HTML being served off that nginx container, it is purely for Dynatrace RUM. OneAgent is running via the Dynatrace Operator as a daemon set on all nodes.

Does anyone know how to achieve this?

Thanks

[Julius_Loman · Accepted solution]

I'm not sure what do you want to achieve.

• Do you have your application server or web server, that serves the application monitored by oneagent or not?
• Do you need to have agentless monitoring (you are injecting the JavaScript manually)?
• Are you on Dynatrace SaaS or Dynatrace Managed?

Your decision with serving the JavaScript via a dedicated webserver just for this purpose does not make sense to me. Normally, the RUM JS is injected on the webserver/application monitored by oneagent that serves the web applicaion itself. If you for any reason cannot install the oneagent there, you can do agentless monitoring. In that case, the JavaScript must be inserted into your web application manually and it is typically downloaded from the Dynatrace CDN if you have SaaS or via Cluster ActiveGate (if you are on Managed).

Can you be more specific on your use case?

[gmichels]

Hello Július,

Thanks for your reply.

• I do have all my applications monitored by OneAgent
• I don't want to do agentless monitoring, I am relying on OneAgent to inject the snippet on the HTML
• I am on SaaS

Reason I want to do a dedicated webserver is because for the applications developed in .NET Core deployed in Kubernetes, the automatic injection/reporting doesn't work as expected due to differences in the context root of the application and how it's actually exposed externally due to firewall rules.

For example, I have a service that is exposed externally under https://www.example.com/v1/app however the context root of the service is simply /, and the URI stem part of it (/v1/app) is only known to the ingress definition, and the service itself has no idea about it. So the automatic injection of the JS agent in the HTML works, however it points to https://www.example.com/ruxitagentjs to load the JS agent and https://www.example.com/rb_xxxx for the beacons, which result in 404s because neither are available under that URI path.

I can fix this by going into the advanced settings of the web application in Dynatrace and forcing the JavaScript library and beacon paths to a URI path of a service which is also instrumented with OneAgent and will result in proper 200s, however this means I am overloading this single service with all RUM tasks.

My idea is to have a dedicated container just for the purpose of serving the RUM assets and endpoints, so I am not overloading any other business services.

Let me know if I need to expand in any of these topics.

Thank you

[Enrico_F]

Try simply omitting the host name and only providing "/v1/app/" as the custom location for the JS tag and beacon.

[gmichels]

Hello Enrico,

Problem with this approach is I am then overloading the .NET Core service under /v1/app with the RUM tasks for all services in the web application (there are 20+), and the intent is to not overload any.

Thanks

[Julius_Loman]

Ok, now with a broader context I understand the requirement.

First, you don't have to worry about overloading the application server with serving the JavaScript and listening for beacons. The RUM JS is just a static file and the beacon is just forwarded further to Dynatrace servers and there is no processing at the OneAgent.
So proper way would be to adjust those paths in the advanced section of the application.
Those values can be relative only.

I can image spinning a dedicated web server for serving the RUM JS and processing the beacons, however, the mapping has to be done by you. So basically defining ingress rules at your cluster for the /ruxitagentjs* and rb_* to point to your dedicated web server. This technically should work, but it needs this additional configuration of your ingress in K8S. Anyway, I'd recommend the first approach as it is less error-prone (no ingress rules required).

[gmichels]

Thing is there is substantial impact if I direct all RUM requests to a single service. We serve around 10k actions/min in our website during peak, and the impact on the service I tried is about 5% CPU usage increase in each node that is part of the service pool, as now everything RUM related is hitting it. The performance team asked for a way to have this in a dedicated service, not interfering with a real business service.

So back to the original question, is there a way to have a dedicated webserver for RUM JS and beacon processing, without any business applications running in it? What needs to be done in this webserver, do I need to statically add the JS file and whatnot? I will make sure the ingress definition will handle the external traffic appropriately.

[Julius_Loman]

OK, but in your case, I don't think you have a single instance of the web server, so the load for the beacons should be spread equally.

Based on how things work, you can easily set up just a plain nginx or apache and have it monitored by oneagent. The context of /ruxitagent* and rb_* will be automatically added. You only need to set up the ingress rules on the K8s so the traffic to those two URL paths will be directed to the dedicated web servers.

Oneagent on the webserver has to be connected to the same Dynatrace tenant as the monitored application. RUM JS or the beacon endpoint can be anywhere, but they have to report to the same tenant.

So basically there is nothing to do in Dynatrace, you only have to setup your routing within k8s.

[gmichels]

The CPU increase is 5% when using 4 instances (5% on each instance), which is pretty high.

I will try the "plain nginx" approach with the appropriate ingress routing rules and report back if it worked.

Thanks for the pointers.

[gmichels]

To close the loop here, I can confirm deploying a simple nginx webserver with the appropriate ingress path, and setting that path in the application advanced RUM properties works fine for serving the JS agent and receiving the beacons.

Thanks everyone for the help.

[Julius_Loman]

Happy to hear you resolved this.