cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

3rd Party Monitoring using AppMon

jacob_gannon
Guide

Hello,

Is someone able to provide me with a detailed description of AppMons capability to monitor transactions which leave a monitored environment, over to a 3rd party, and then return to the monitored environment? So this would be where the transaction goes from Web > App > 3rd party > App > Web, where the Web and App tiers are being monitored using AppMon.

Scenario 1

Transaction leaves the monitored App tier with the same session ID as the response from the 3rd party.

Scenario 2

Transaction leaves the monitored App tier with session ID X and the response header returns with session ID Y, but there is logic to distinguish how X and Y map together.

Scenario 3

Transaction leaves the monitored App tier with session ID X and the response header returns with session ID Z, there is no logic to map between X and Z.

In all scenarios, I'd like to understand:

- Can AppMon report against response times and errors etc. as is the case for DB connections between a monitored App tier and a backend DB?

- Can AppMon understand any of the 3rd party's architecture, or is it all just seen as the 3rd partys front-end (I suspect this is the case.)

Thanks,

Jacob

8 REPLIES 8

dean_camenzuli
Dynatrace Participant
Dynatrace Participant

Hi Jacob,

While waiting for someone to give a comprehensive response, this may be of use to you.

https://community.dynatrace.com/community/display/...

Hi Dean,

Thanks for your response. My question is more around specifically if a monitored application is firing off web requests to a 3rd party, and less about 3rd party content within a web page, which I think is the subject of the link you have provided. Still some usful info though!

Jacob

Jon_Griffiths
Dynatrace Organizer
Dynatrace Organizer

Hi Jacob,

In short, AppMon does not use the session IDs and as such they have very little impact. AppMon adds its own x-dynatrace header (for HTTP) to maintain the PurePath.

Basically what happens is that when the application tier fires off a request to an unmonitored host, whether that be a 3rd party or internal, it will capture the time it takes to send the request and receive a response. This will include things such as the HTTP status code or SQL return values and as such also understands the failures that are taking place.

AppMon will not be able to see any requests past the first hop. For example it will see web -> App -> Third Party, it will not see web -> App -> Third Party -> other 3rd party. However with the second one the response time will include the other hop as the third party will not respond until it is complete.

For scenarios where the third party responds to the request and then starts another job to later reply to the same app tier. As such the response not being reliant on the following job. As these end up being 2 separate transactions (i.e. 2 separate end-to-end stacktraces), this would also end up being two PurePaths, which could then potentially be associated by some form of ID with a business transaction.

Hi Jon,

Does this mean that AppMon depends on the returning header containing its own x-dynatrace parameter, in order to show the time taken for response/HTTP status codes/SQL return values etc?

Do you have an example which you can share, where 2 separate transactions have been captured and successfully associated within a business transaction? I'm curious to understand the limitations around the form of ID used to do this association.

Thanks,

Jacob

Hi Jacob,

Sorry that probably wasn't clear. No the x-dynatrace header is to do continuations of transactions. i.e. to go from Web -> App. What this actually means is that if you did Web -> App -> 3rd party -> app in a single transaction (not a return) then if the 3rd party did keep the header it would be able to continue the transaction and the third party would be seen as "inter-tier" time (unless defined as observer tier) between the app and the other app (which could be the same or different).

SQL statements have no headers added at all and yet still get the return information.

In terms of creating a BT, you can use any data available to you to correlate this information. They will still be 2 separate PurePaths, but when drilled down from the ID (whether that be a session ID, some method argument or some HTTP parameter) you will get only the two relevant PurePaths. You just need to find something unique to correlate those transactions.

Hi Jon,

Okay I think I understand now. If we apply that to the scenarios I've described above -

Scenario 1

AppMon can map together two different PurePaths if there is something which uniquely identifies the two (such as a Session ID) via a BT.

Scenario 2

Even if the Session ID is different, there may be something else we can use within the BT config to map two separate PurePaths together.

Scenario 3

If theres no unique string passed to logically map two different PurePaths we are not able to combine the two together within a BT.

Can you confirm if my above thinking is correct?

Not entirely if I understand your scenarios properly.

Scenario 1:

Single PurePath from web to app to third party and return. No config needed

Scenario 2:

Single PurePath from web to app to third party and return. No config needed

Scenario 3:

Single PurePath from web to app to third party and return. No config needed

You only need to use a BT to combine two PurePaths when a monitored host SENDS a request to a non-monitored host, which then SENDS a request to a monitored host without passing the dynatrace header.

Transactional responses do not require BTs or added headers.

It is important to note that AppMon is tracking from the application level not the network level, meaning request/response combination and SSL decryption has already taken place.

Perfect! Thanks for explaining.