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

No results in CAS: Not sure if the correct analyzer is picked?

Christopher_Cha
Dynatrace Advisor
Dynatrace Advisor

Greetings,

I am doing a new DCRUM deployment for a customer, and we are trying to monitor one of their backend traffic.

By using CAS's Capture Packets I confirmed that we see the traffic between 10.5.8.31 (middleware) and 10.8.1.2 (backend server) which is listening from 6011 to 6933.

Naturally, I assumed that by using Generic (with transactions) analyser I would be able to see the traffic results in CAS, but all I see is only this:

Although we do see 10.5.8.31 hitting 10.88.1.2, but apart from 100% network performance, I see nothing else. I tried using TCP analyser but still same result. Am I using the wrong analyser?

Chris

6 REPLIES 6

wojciech_kurek
Inactive

Chris,

If the Generic TCP analyzer does not show operations it may mean that the traffic is unidirectional (i.e. only one side of the conversation is seen by the AMD). You could try creating a report showing client and server bytes individually to see whether the AMD sees both sides of the conversation for 10.5.8.31 or not.

Wojtek.

Hi Wojtek,

Thanks for the response. Based on the trace packet I see bidirectional traffic, i.e.

Node A 37327 -> Node B 6901

Node A 6901 -> Node B 37327

with the same amount of transmitted packets and bytes.

I also created a report to show the client bytes and server bytes for this 10.5.8.31 -> 10.88.1.2, and i see 6.84MB and 10.4MB respectively.

I'm wondering what else could have cause this issue?

matthew_eisengr
Inactive

Could it be that you aren't seeing the 3-way handshake and therefore not measuring the response time?

This could happen if the server is opening the connection once and then re-using it until the session times out.

Perhaps try persistent TCP sessions?

Thanks for the input! What you said is also what Support mentioned after looking into the trace file I uploaded - there was no SYN packet. Seems like the server is allowing very long session time-out because it has been couple of days and I still see the same thing.

Christopher_Cha
Dynatrace Advisor
Dynatrace Advisor

I was browsing through documentation and saw this:

"Optional: Select the Client port(s) check box for reversed-direction protocols.
This option is available only to protocols such as X-Window whose client-server meanings are reversed. If you are uncertain, leave this option cleared."

Maybe turning on this will help as I see the application protocol in the trace is of XWINDOWS... But I'll have to wait until next Wednesday to be onsite and try this out.

Christopher_Cha
Dynatrace Advisor
Dynatrace Advisor

So the final answer just came in. The way DCRUM recognize operation hits is through the traditional TCP handshake and so on. As quoted from development:

"The Generic with transactions analyzer counts operations as data direction changes - i.e. a sequence of data packets from the client followed by a sequence of data packets from the server.

In this particular case (10.5.8.31 / 10.8.1.2) only the server sends data, and the client just sends acknowledgements. There is no way to report operations for such traffic."

From the conversation with customer I gathered that the communication between the two servers is something like the following:

Server A Port 1111 -> Server B Port 2222 -> Server A Port 3333

And that's why there is no operation count...