My customer has two applications with PurePaths not being correlated end-to-end.
1) A Java tier having an internal MQ and Jetty/Camel to communicate with a second Java tier
2) A .NET application pool connected to ElasticSearch using the ElasticSearch Plugin for .NET
- Can we achieve the end-to-end stitching by simply adding additional sensors?
- What would be the best method to determine if code change and use of the ADK are required?
- Do we have a method/process/step-by-step guide to solve those kind of stitching problems?
Solved! Go to Solution.
Are you seeing two separate purepaths that should be one, or is the purepath simply ending at the point it should make the "jump" to the next tier?
Also, has the customer provided the method/web request/MQ call that should be responsible for bridging the connection?
I am not aware of a step by step guide for stitching, though it typically depends on the technologies involved, depending on that, it could be possible that a certain method needs to be instrumented or even added to a sensor pack. Or alternatively, using the ADK, though I do not have much experience using it.
Thanks Cody. The PurePaths are broken and we are potentially missing a part, especially for the MQ one. I have CPU samplings showing the different calls but it looks like that even with added sensors I does not stitch PurePaths together. So I guess the ADK is the last resort.
A decision graph would be the best to simplify and unify the method.
I also received an answer from Flo,
achieve stitching out of the box you need the following:
systems with an agent on each end and no missing process in the middle. If
there is something in the middle it must keep messages/calls alone (no removal
of headers or message transformations). Typically it could be a proxy, load
balancer or ibm datapower.
The processes must communicate via a protocol we support. Http, soap over http,
jms and MQ. Why? Because our agent intercept the communication and tags it. The
same happens when receiving the call, we check if there is a tag.
even if we support the above protocols, it must be done with APIs we support
otherwise the tagging can't happen. for example, if the app uses a library we don't support, it doesn't work.
any other scenario we require the ADK.
No problem Nic,
Be sure to update if you can get this resolved.
A couple things you might want to consider before resorting to the ADK, if the methods are similar to those in an existing sensor pack, you might be able to edit the sensor pack, add the methods and achieve stitching, though it heavily depends on the method.
Also, as you said above, it depends on the technology used. What version are you on? I know that in 6.5, MQ to JMS stitching was introduced as an RFE because I worked with the customer who initially requested it. If you have any questions on these, just let me know.
" I know that in 6.5, MQ to JMS stitching was introduced as an RFE because I worked with the customer who initially requested it."
Does this functionality stitch when one instrumented service drops a message onto a queue then have another instrumented service pick that message up off that same queue? Currently we can see the get and put to MQ from each process but all the processing that happens to that message within each service is in a different purepath.