DX Application Performance Management

 View Only
Expand all | Collapse all
  • 1.  Backend Path

    Posted Aug 24, 2016 07:30 PM

    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):


    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/0E105E4541BA5426CCC598D493187E51/email|GET:Average Response Time (ms)
    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/0E105E4541BA5426CCC598D493187E51/telephone|GET:Average Response Time (ms)
    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/0E882CD089D8779F278666B90C5DAEDA/idcards/wellpointisg|GET:Average Response Time (ms)
    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/1F74E9616D13F14E8A8223825CD897AF/address|GET:Average Response Time (ms)
    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/1F74E9616D13F14E8A8223825CD897AF/benefits/1FZ5-20160101-20161231-MED/summary|GET:Average Response Time (ms)
    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/1F74E9616D13F14E8A8223825CD897AF/claims|GET:Average Response Time (ms)
    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/1F74E9616D13F14E8A8223825CD897AF/coverage-period|GET:Average Response Time (ms)
    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/1F74E9616D13F14E8A8223825CD897AF/idcards|GET:Average Response Time (ms)
    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/2B0F0E6242A41E44059B5D763025A14B/benefits/1G67-20150501-20151231-MED/servicelimits|GET:Average Response Time (ms)
    WebServices|Client|https_//uat.api.mycompany.com/v1/cp/members/2B0F0E6242A41E44059B5D763025A14B/benefits/1G67-20150501-20151231-MED/summary|GET:Average Response Time (ms)



    I have created a backend path statements:





    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:





    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.

  • 2.  Re: Backend Path
    Best Answer

    Broadcom Employee
    Posted Aug 25, 2016 10:59 AM

    Hi Steve:

    Converting to a question to get a wider response



    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

  • 3.  Re: Backend Path

    Broadcom Employee
    Posted Aug 26, 2016 12:35 PM

    Hiko_Davis  Guenter_Grossberger any thoughts on this?

  • 4.  Re: Backend Path

    Broadcom Employee
    Posted Aug 26, 2016 01:07 PM

    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 

  • 5.  Re: Backend Path

    Broadcom Employee
    Posted Aug 26, 2016 01:12 PM

    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


    Hal German

  • 6.  Re: Backend Path

    Posted Aug 31, 2016 07:55 AM

    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.





  • 7.  Re: Backend Path

    Broadcom Employee
    Posted Aug 31, 2016 08:04 AM

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

    Hal German

  • 8.  Re: Backend Path

    Posted Aug 31, 2016 04:45 PM

    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:




    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).


  • 9.  Re: Backend Path

    Posted Sep 01, 2016 05:11 AM

    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.





  • 10.  Re: Backend Path

    Posted Sep 01, 2016 11:48 AM

    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.

  • 11.  Re: Backend Path

    Posted Sep 06, 2016 06:59 PM

    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).

  • 12.  Re: Backend Path

    Posted Sep 08, 2016 04:45 PM

    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

  • 13.  Re: Backend Path

    Broadcom Employee
    Posted Sep 11, 2016 12:48 PM

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