RUM V2 enabled and more informations

[Axel]

Hello community,

i want to enable RUM V2 in my environment, but there are few informations in documentation about it (maybe because it's an early adopter). In screen below there is a switch On/Off:

So, i have some questions:

1) There is a best practice to enable it? Or just switch On?

2) There is a detailed documentation about it?

3) There is a Process Group Override section, so i can select a specific process group when i enable RUM V2 or i must enable it for whole environment?

4) If i enable RUM V2, i must restart what? Processes, or whole VM?

Anyone have some information about it?
Thanks so much

[ChadTurner · Accepted solution]

1. You can go ahead and enable it if you are using java web/app servers for RUM.
2. Documentation is internal and nothing is publicly available. Most of the changes are architectural to solve certain quirks that the older version had and you won't really see any noticeable impact after enabling it
3. Yes you can enable it at the process group level
4. You would have to restart the process

[Axel]

Thank you Chad for your answer

[zietho · Accepted solution]

Dear @Chad T.,

Dear @Axel V.

I have to add to / refute parts of Chads statement!

v2 (very bad choice for the name) was maybe initially planned to "improve" or supersede the existing version. However, since v2 is technically different and tries to tackle different cases it should be seen as an alternative approach not an improved version! Hence, if everything works find now and you don't have any class cast exceptions (that's what v2 its build for) then I strongly recommend to stick with the existing version and not enable v2.

Heads up here: we will "remove" v2 from the UI in the foreseeable future and only make it available for our support teams to enable it / switch between the approaches if needed. v2 will be an "alternative approach" and therefore a troubleshooting "feature" only. To correctly call it by the name!

Pls. let me know if anything is unclear

regards

Thomas

Product Manager RUM web

[Axel]

Thank you so much Thomas, i appreciate it!

[Axel · Accepted solution]

Dear @Thomas Z.,

i want to explain my answer. I have an application that run in Webmethods Application server. This Webmethods is officially supported, but RUM injection doesn't work. I opened a ticket to Dynatrace support and they told me that RUM is not supported because this application doesn't use Java Servlet (processes instrumentation is OK). Also, they told me to try ith RUM V2, but there are few chances that it works.

So, do you know if RUM V2 might work?

Thank you and best regards

[zietho]

Anytime!

If I were you, and since "This Webmethods is officially supported" I would push Support to properly troubleshoot this case! If its not because of class cast exception than they have to properly follow it up with development and they have to check whether and how we can fix this. In my humble opinion as simple as that!

And please feel free to mention me in the ticket then I can also follow the ticket!

thanks

Thomas

[Axel]

Thank you @Thomas Z.! Support told me that Webmethods are supported for OneAgent instrumentation, but RUM is not supported. This is ad extract from support answer:

"First of all there is no official support for RUM for WebMethods Integration Server 0 in other words Dynatrace OneAgent is not able to inject JS library into its HTML pages because these are not Web request services but web services. The documentation only says that OneAngent is able to monitor "Java internals" of this product but not injecting RUM portion.
RUM is supported only for "Java servlet-based web applications" and we don't inject RUM into webMethods, as they use something different than servlets and marked as webService which means XML/JSON. Anyway we had once a customer who swiched Java Monitoring to V2 and for WebMethods and it worked well."

"if we don't use Servlets than there are small chances RUM V2 will help, sorry ... "

So, i don't know if open a new support ticket or try RUM V2...

[zietho]

Dear @Axel V.,

shortly got in touch with the dev for the Java injection.

Yes we don't support auto injection for Webmethods.

BUT.

what you can do in this case is the following:

• have an agent on the server capturing the server-side metrics
• have an application for automatic injection and
  • create an injection exclusion rule to never inject automatically
  • insert manually.
  • make sure the beacons are sent via an Active Gate

This way you should be able to monitor that setup full stack!

regards

Thomas

Hope that helps. Support should know about this and help you set it up correctly!

[Axel]

Hello @Thomas Z. and thank you so much!

So, i must try to enable manual injection, right?

Application settings -> Injection -> "Manual insertion" tab

This is correct path for solution? If not, can you tell me the correct path in settings?

Thanks for your usefull help,

Best regards

Axel

[zietho]

exactly! And don't forget to also add an exclusion rule to not inject automatically for the domain/the whole web site

[Axel]

Perfect, thank you Thomas, i'll update thread if i'll have news.

Best regards

[henk_stobbe]

Hello,

Today we had an issue  with an IBM tool: 

java.lang.ClassCastException: com.dynatrace.agent.introspection.uem.impl.CacheHookingRequestWrapper

Support advised to turn on: Java Real user monitoring v2 [Opt-In]

This fixed the issue. So my question is,

Does turning this on, turn off the old stuff (-;?

And is your previous (excellent) explanation  now obsolete?

KR Henk

[zietho · Accepted solution]

Yes, as far as I remember this is an either-or choice between two different ways to inject.

[henk_stobbe]

Cool thanks for your reply. Is it a big problem for you to find out a little more info about the difference? Or is this what should be done by way of a ticket?

KR Henk

[zietho · Accepted solution]

Both approaches instrument the Java Servlet API, but in different ways.

The servlet API provides wrappers for request and response objects. In V1, the approach is that we send our own wrappers on the journey, which then take care of things like JS agent injection. However, this can lead to ClassCastExceptions because the customer app expects a different type (i.e., not our wrapper).

That's why V2 has been build which doesn't use wrappers, and the ClassCastException no longer occurs because of it. 

[henk_stobbe]

Great reply! Thanks again!

[Carlossap]

Hey Thomas,
Have there been any updates on the naming for this feature or its removal (support only)?
I got feedback from a team that it would be good to mark it as an alternative/experimental rather than "opt-in".

Kind regards,

Carlos A
ACE Consultant