DX Application Performance Management

Has anyone worked with Backend Path as discussed in the https://docops.ca.com/ca-apm/10-2/en/implementing-agents/java-agent/configure-java-monitoring/configure-backend-path-groups

We are having issues with a new application that is using REST WS calls and our member ID is embedded in the URI so we are getting massive Backend and WebServices metric trees and I have Case Comment 00456321 - REST API WebService Metric Explosion open with Support (which has them completely stumped at the time)...

One of the suggestions was to use the Backend Path even though it would only fit the Backend and not the WebService Client tree. I think I have built the statements as described but am not seeing any difference even in the Backend or Called Backend trees.

Given the following backend tree (only a snippet of the full tree):

I have created a backend path statements:

ntroscope.agent.backendpathgroup.keys=members,default
introscope.agent.backendpathgroup.group.members.pathprefix=/v1/cp/members*
introscope.agent.backendpathgroup.group.members.format=members
introscope.agent.backendpathgroup.group.default.pathprefix=*
introscope.agent.backendpathgroup.group.default.format=Default

From this I would expect a Backend|member tree with the all the metrics accumulated in the normal 5 metrics types.

Also it says that you can use a wild card (*) but I was wondering if I can use multiple to pick up another groups for example with:

WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/2B0F0E6242A41E44059B5D763025A14B/benefits/1G67-20150501-20151231-MED/servicelimits|GET:Average Response Time (ms)

Can I put in a backend path:

introscope.agent.backendpathgroup.group.members.pathprefix=/v1/cp/members/*/benefits/*

introscope.agent.backendpathgroup.group.members.format=members-benefits

this would give me the best breakdown.

I have given up on Support coming up with something to limit the WebServices|Client trees until some future release but if I can at least get the Backend trees combined as above that will help our users to see what is happening but with the proliferation of metric trees they cannot really see since even metric groups won't work because of the number is separate trees.

Hi Steve:

Converting to a question to get a wider response

Thanks

Hal German

Update: Because a case is actively worked, I am going to marked as answered even though there is not a solution yet. Have asked Support to look at this and will expand audience. Will do what I can to get you additional insights

Hiko_Davis  Guenter_Grossberger any thoughts on this?

Backend Path Grouping is applicable on HTTP Backends only , not Webservices Backend.  But I can see the benefit of expanding the same for WS Backends as well . Please work with Nishant to add this as part of our backlog 

Hi Steve::

Based on Abhijit's note, this looks like an enhancement request for Backend Path group for Web Services.Please submit an idea. I promise that I will vote for it

Thanks

Hal German

Hi Steve,

I believe you have received a response on this, but in case you haven’t, please not that the backend path functionality currently only works for the HTTP client instrumentation, and not for the instrumentation coming from SOA Performance Management (SPM).

In case you’re wondering how to differentiate the 2:

HTTP Client instrumentation generates metrics that have this format: "Backends|WebService at _//_|Paths|"

Note the “Paths” node. Instrumentation coming from SPM does not have this.

I hope this helps and sorry for the confusion, we do have plans to consolidate this in the future.

Regs,

Florian.

Thank you Florian for your invaluable contributions. I am asking for someone to write this as a Knowledge Doc.

Hal German

Thanx....that is what is puzzling me....if these are REST why are they showing up as SPM and WebServices|Client anyway. I was given the follow URL for an example of how these are called in the code:

https://membersecure.test1.va.mycomany.com/member/secure/api/securemessage/member/A0bTBaDJ8HpNNPWVGhpa2tJKZ0B75Isx-RUsOWoq6UT2Qx4Xbg3kGon6ATh4U8vz/messages?folder=unread 

So to me these should be HTTP Backends....not WebServices and not under the WebService|Client tree either.

And my Backends show as:

Backends|WebService at https_//api.mycopmpany.com/v1/cp/members/0A2B961572639E0533CB2BD18E26ADF4/claims

SO, shouldn't my backendpath statement work?

As stated, I have given up on the WebServices|Client tree but based on the documentation I should be able to consolidate the backends....

Maybe the real question is why these are showing up handled by SPM and not HTTP Backend (REST).

Hi Steve,

As I explained previously, the backend path grouping feature only works for metrics that appear under the “Paths” node, and come from HTTP client instrumentation.

The reason you’re seeing this instrumentation under WebServices is probably because you’re using JAX RS and SPM actually some of the classes, and we have coded the tracers so that SPM tracers take precedence over HTTP Client tracers.

What you can try is disable SPM (remove the webservices.pbd, appmap-soa.pbd and spm-correlation.pbd). I’m hopeful that this would turn off the WebServices node entirely, and would allow HTTP Client tracers to run instead of SPM tracers.

Regs,

Florian.

Thanx. I will try to remove SPM however, however, in this app they still call some legacy WS via SOAP. So in the long run what I need to do is figure out how to just disable JAX RS in SPM.

Well, I have found out that the Spring Field Pack springMonitoring.andreasreiss.201508301314-bin  interferes with the new REST monitoring for Spring HTTP and sends it through the SOA Monitoring path instead of the newer REST Spring HTTP processing. I even tried to go back to the original SpringWS monitoring field pack that I have been using for years (ever since SPM came out and has not supported SpringWS Framework) and this has the same issue of handling the Spring HTTP as SOA. I have not tried the Soap WebServices_Addon SOAP WebServices Addon but figure that would do the same.

So I have removed the spring.pbl from the directives and now I get my backendpath to work:

The only problem is if an application uses SpringWS and Spring HTTP then you can only monitor one of them. It will be nice if SPM ever gets SpringWS supported (originally promised for 9.8 which became 10.0 but this feature has yet to be delivered).

Looking at the spring-toggles.pbd that is part of the springMonitoring.andreasreiss.201508301314 package are two parameters at the very bottom of the pbd:

# Support for Rest Web Service calls (discovery and correlation)
TurnOn: RestServiceTracing
TurnOn: ClientHttpRequestTracing

We found that commenting these out (turning them off) that we are still processing Spring HTTP via the standard APM 10 REST monitoring but are still seeing SPRING Web Services stack handled by SPM and show up in the standard location - WebService|Client,

this is the way or sprig-toggles.pbd looks now:

# Support for Rest Web Service calls (discovery and correlation)
#TurnOn: RestServiceTracing
#TurnOn: ClientHttpRequestTracing

Thanks for sharing Steve. Good to hear that persistence paid off!!!