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

Citrix monitoring

We are currently monitoring Citrix environment traffic between NetScaler and XenApp servers. We don't have the TCAM module installed yet and currently we don't have a measure point behind of the XenApp servers.


NetScaler is also acts as NAT device, so we don't see the real client IP's and it also look that the Client RTT measure is calculated from the traffic between NetScaler and the XenApp. Should we have the traffic before NetScaler or what is the "best practice" when monitoring Citrix.

8 REPLIES 8

jean_louis_lorm
Dynatrace Pro
Dynatrace Pro

Hello,

Yes, prefer this instrumentation (if you can't have TCAM and application monitoring )

You will have the good value for the client RTT and you don't need to turn Nat resolution on, you will have all the client IP adress.

But the best practice is with this instrumentation,

Regards,

JLL

Thank's for your reply and you verified my doubt that our measure point is in wrong spot.

Currently we don't have any other choice than take the traffic between Netscaler and the XenApp servers. We are going to install the TCAM and I hope that in some point we can get the traffic from the application servers itself.

Our current situation seems to be, that NetScaler "masks" quite scale of the client issues, so mostly see if there have been some errors in traffic what NetScaler and XenApp servers are having.

That is true in many ways Janne.

First you have Citrix playing tricks with the protocol:

http://apmblog.dynatrace.com/2015/08/13/citrix-session-reliability-does-it-cloud-your-network-insigh...

And then on top of that there are way to many settings in the Netscaler (http://support.citrix.com/article/CTX121149) that can cause unwanted effects unless you have a good measurment in place and closely pay attention to what the effects are of the configuration. Here's a tip of what you can do when you have the right data into your AMD from one of the more knowledegable network experts

http://apmblog.dynatrace.com/2015/10/08/network-app-performance-application-deceleration-controller-...

Another tip is to keep an eye on the APM blog 🙂

I suppose that we can't do like this, so we would take the traffic from front of the NetScaler and also from behind of the NetScaler? I'm just thinking wil we lose visibility to errors like Zero window events between the NetScaler and the XenApp farm if we take the traffic from front of the NetScaler?

mick_huynh
Inactive

What do the Application Servers represent? XenApp? or the Enterprise Apps such as HR, ERP, etc.?

That's an Enterprise App.

Babar_Qayyum
Leader

Dear @Jean-Louis L. and @Ulf T.

First time going to monitor the Citrix technology so we need expert advice and a guideline to get the real benefits for the respected team.

Initially we created two software service with the default global settings (one for the Web Interfaces Internal/External and one for the XenApp Servers stack) with the 'Citrix ICA' analyzer. Currently AppFlow is not configured and also TCAM isn't install on any XenApp server.

Software services without any requests breakdown, application performance and availability etc.. are without any metrics.

The Citrix dashboard has the below information without 'Availability' data.

Below are the FE serves for the internet (in red box) and local access where we can see that there is no request breakdown, availability (total) information and also only one unique user for the internet traffic which is a Citrix NetScaler and the same situation with the XenApp software service.

Is this the expected behaviour without AppFlow and TCAM or something wrong with the configuration?

Development # 1: I installed the NetScaler private key in all the AMDs but still getting the below message.

Development # 2: We can see the below metrics of the XenApp Servers except the performance after installed the TCAM.

Regards,

Babar

Babar,

This looks like an issue with the quality of traffic monitored with the ICA decode. Zero requests, zero availability means we either receive unidirectional traffic only or servers are sending RST to every client request. please investigate further what exactly does the AMD receive as a copy of the ICA severs traffic, perhaps with the smart packet capture and Wireshark to confirm for sure what you see on the wire plugged into the AMD.

Regarding AppFlow, it's good to have both decode-based monitoring and AppFlow feeds, but in reality having one of these would be just enough. Measurements provided by either of them are comparable, AppFlow is a great alternative to the ICA decode when RC5 encryption is in use. Decode-based monitoring provides visibility into all apps on the client link, including those that compete with the ICA traffic. AppFlow alone won't give this perspective.

Best regards