Web services were developed using the spring framework v 3.1. This version is not in the web service sensor pack and as a result calls to the service are showing up as web requests. What I would like to do until support gets this fixed is to define a business transaction using the URI and add a method measure (filter) for the entry point of the web service in question. The method measure is used to identify the service. I'm hoping to get the URI response time as the time the service ran.
Does anyone have any ideas on how I could accomplish this?
Answer by Jim M. ·
Hi Richard,
I just want to verify you have the fix in place for the spring framework that was suggested in this thread. We had to modify the out of the box sensor pack to get the services to show up. Unfortunately you lose the sensor pack fix on just about every patch and release Dynatrace shoves out the door. It would be nice if Dynatrace put the fix in the sensor pack going forward so Spring 3 is supported out of the box.
Let me know if you have modified the sensor pack.
Thanks,
Jim
Hi Jim, I have added the org.springframework.web.servlet.DispatcherServlet class (All Methods) to the out of the box "Java Webservice" Sensor pack and did a hot sensor placement on the relevant application servers but still only see everything being grouped under either execute/invoke as per screenshot below.
Does the dynatrace server require a restart as well for the changes to the sensor pack to register?
The below webservice call is actually for an operation named QueryEntities but showing up as execute method.
The purepath shows the dynamic class come up as the following but I would like this handle named QueryEntities to be displayed in the Namespace and Method out of the box Java Webservices dashboard.
Thanks for your help with this!
Richard
hi Richard,
it's actually not so easy as just adding arbitrary classes/methods to OOTB sensors and have them working automagically.
there's specific checks to prohibit incorrect instrumentation and breaking the application as a consequence.
there's however a workaround/fix, which I provided to Jim via a support ticket, as I did not want this workaround to be on the public forum here.
if you create a support ticket and let me know the number I can also post the workaround there.
the better solution in the long-term would be of course to officially support Spring (not only Spring WS), but we did not really get enough requests for that yet.
if you feel like it, you can of course also create an RFE to raise the awareness.
HTH,
Christian
Thanks for the response Christian your help to get this working would be greatly appreciated as we currently have a big requirement for splitting out webservices based on the method/operation invoked on them for the purpose of tracking SLA's against the specific operations and a big portion of our systems are making use of Springframework 3+.
I have raised a support ticket SUPDT-9349
Thanks for looking into this for us Christian
Kind Regards
Richard
Answer by Richard M. ·
Hi All,
Sorry I know this is an old thread but seemed like the most relevant place to be asking this question.
We are having an issue where the webservice invoked by springframework 3 is correctly being detected however the namespace and method is giving either invoke or execute however there are multiple different dynamic classes generated upon invoking/executing the webservice which we are unable to create measure for splitting by the actual operation being performed on the webservices as the contexualised operation name is part of the dynamic classes.
For example we have a webservice named /webservice1/web-service.wsdl and this wsdl will be generated dynamically upon invocation of the wsdl presenting the client multipe methods that can be invoked on this webservice however dynatrace has no visibility of these different classes and methods.
Is there a way to get these different dynamic operations into dynatrace so we can split specific calls based on these dynamically created classes?
Thanks in advance!
Richard
Answer by Rob V. ·
My pleasure Jim. Christian's solution is the better one for you, though the BT would have worked too. I always prefer updating the sensor packs if that is a viable option.
Please do yourself a favor and make a note about the change that you made to our internal Sensor Pack. I do not want you to lose that functionality in an upgrade!!
Answer by Jim M. ·
Hi Rob,
I am fuzzy on the splitting part. I've developed BTs around URI pattern matches but nothing with methods. The services we are working with just went live so this is an issue that I needed to address ASAP.
I appreciate your help. I went down the BT path because it looked as the web service path was blotto. (My support case) Luckily Christian stepped in otherwise I would have had to implement the BT.Your solution looks like it is a viable work around. It's nice to know there are multiple paths to a solution.
Thanks again,
Jim
Answer by Rob V. ·
Hi Jim,
I had the impression that you wanted to treat the services separately which is why I first made the "separate BT" suggestion. But I offered the "split" solution in case you wanted to keep BT creation to a minimum.
If you did the split solution, you would have one BT. When you executed the BT, you would see separate lines in the resulting BT dashlet for each handleXXX method. This would look similar to the "Web Services by Method" built in BT.
If you went with the one-BT-per (filter) method, you would have (naturally) one BT per handleXXX method.
Plusses and Minuses: the split method is simpler in that you only need to define one BT, and you will get results for any handleXXX method. However, all of those results are what we call "dynamic measures" meaning they don't have any configuability on their own. So, for example, you could set a response time threshold of 2 seconds for the BT, meaning that this threshold would apply to each handleXXX method. You could not set handleSearch to have a threshold of 2 seconds for alerting, handleSomethingElse to have a threshold of 3 seconds.
The filter method (one BT per handleXXX method) means that you will be creating a separate BT for each desired method. This will make it a little more "obvious" in the dT GUI, since you will see "handleSearch" as a BT, "handleSomethingElse" as a BT, and so on (as opposed to "handleXXX webservices by handler" as a single BT). Good news is that you could set up different thresholds for each one individually. Also, you will get just what you want. with the Split method you will get one line in the BT output for any handleXXX method. If you had 20 but only cared about 6 you'd still see all 20.
Either approach is fine - just depends on what you want to accomplish.
It sounds like you may be a little fuzzy on BTs, so let me know if this makes sense.
Rob
Answer by Jim M. ·
Chistian,
The fix worked perfectly. All out of the box dash boards work once configured and the services are now appearing as expected in the UI under web services. I like your response a lot better than what I saw in previous response to my case which was "it isn't supported". Our developers like you too since they want to keep current and the 3.x sring framework provides them with some functionality that makes their life easier.
Thank you so much.
Jim
Answer by Jim M. ·
Love all the suggestion and help. Let me speak about what I know so far. If you use just the method sensor you lose all overhead that weblogic uses to instantiate the service so you don't get a true picture of how long it took the service to run. That's why I'm trying to keep things at the top level URI call if possible.
Rob, I'm not sure I understand but I like the idea of one definition. Will I get differnt BT names based on the split? If I can't I'll define separare BT. There are currently 6 services. There will be more in the future. As an FYI I can attach a screen shot of the class explorer so you can get an idea of what weblogic is doing. Let me know if you want this.
To Christian's point - Support did have me modify the web services sensor pack and add a defintion to it to see if the web services would show up. I've attached the screen shot of the modified sensor pack definition. The call to the various services did not show up as web services and that's the whole point. That's when I went down the BT path so I can track the web service calls individually.
Thanks to all.
Answer by Christian S. ·
hi Jim,
there's a way you can have the 'new' API
org.springframework.web.servlet.DispatcherServlet.doService()
handled the same way by the Web Service Sensor as the 'old' API
org.springframework.ws.transport.http.MessageDispatcherServlet.doService()
i just talked to our support and sent them the instructions, they will post it on your case.
the reason, i'm not posting it on this public forum is, that you should not do changes like that without consulting guys with dynatrace internal knowledge.
best,
Christian
Answer by Rob V. ·
So to be clear: the time that you would have wanted from your screenshot above is the top line: 2180.74?
If this is the case, then I think this is straightforward. You would create a BT for each "handleXXX" that you have. The BT would have two "Filter" measures. One would be a WebRequest measure "count" with a threshold of 1 for the URI, and the other would be a Method measure on "invocation" with a threshold of 1 for the handleXXX method. If the above time is the one you are looking for (see your screenshot) then the default return values for the BT will be fine.
(NOTE: "sensors" are required for any method-based measures. There are many ways to organize and accomplish this. My recommendation: create a new sensor group called SpringWebServices (or something like that) and create a sensor in there for all of the handleXXX methods. Then make sure that sensor group is "placed" into the proper agent groups in your system profile. Then create the BTs as stated above.)
I'm worried I'm missing something with complication you add on the "SearchEndpoint$$Enhancer..." stuff. How is that relevant? Am I missing something?
Rob
Here is an alternative:
If you really are interested in that top-line number, and you are confident that anything that starts with "handle" will be one of your services, you could create a single BT that split on the method name.
In this case you would create one BT with a single filter, a WebRequest "count" on the URI with a threshold of 1. Then you could create a SPLIT Method measure on "method name" where the name starts with "handle". Or perhaps you could use a regex if there was some pattern that helped you really nail it down.
In this case that one BT would split across all the "handleXXX" methods for that one general URI.
Rob
Answer by Jim M. ·
Rob and/or Andreas,
As Rob mentioned, the URI is general. The SOAP message contains the service to run. There will be a "handleXXXXXX for each of the web services being invoked.
Would I do an invocation or a time for handlSearch method measure when I define it? I just want to use it as an identifier to separate the different service calls.
What I was hoping to get was time and count of the URI call when the call contains handleSearch in the Purepath. I assumed I would need a business transaction for each of the services in question. Do you think this is possible?
Weblogic is also doing some stuff around the class for the handleSearch method since it is an entrypoint. For example: com.cinfin.ecm.services.endpoint.SearchEndpoint$$EnhancerByCGLIB$$d8d31455 shows up in the purepath. The developers defined: com.cinfin.ecm.services.endpoint.SearchEndpoint
Would it be more efficent to use a regex on the class or a starts with? Please advise. Since this will be going in production I want as little overhead as possible.
Thanks,
Jim
JANUARY 15, 3:00 PM GMT / 10:00 AM ET