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
Solved! Go to 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
Product Manager RUM web
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
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!
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...
Dear @Axel V.,
shortly got in touch with the dev for the Java injection.
Yes we don't support auto injection for Webmethods.
what you can do in this case is the following:
This way you should be able to monitor that setup full stack!
Hope that helps. Support should know about this and help you set it up correctly!
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,
Today we had an issue with an IBM tool:
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?
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.