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

Article on Citrix monitoring

mark_gerards
Dynatrace Pro
Dynatrace Pro

Dear All,

This article I wrote to summarise my experience with Citrix monitoirng.

When it comes to Citrix, there are 2 parts to the monitoring. These two flavours complement each other, which will become evident from the below. Also, I noticed that the online documentation on the community doesn’t really match the pdf version, so download all docs here: https://community.compuwareapm.com/community/download/attachments/181637179/DCRUM-12.3.2-PDFIndex.zi... There is a specific one for Citrix in there. Almost all information in the PDF is present on the community, but it is somewhat more difficult to find.

ICA traffic analysis (what does the user do on the Citrix server itself)

This analysis is focused on commands that are executed on different Channels against different applications running on the Citrix server. E.g. Keyboard shortcuts or mouse clicks, but also audio etc. This part does not require the TCAM agent and in this case the Citrix is to be seen as a Server (application) Tier. We don’t get any metrics from the server in this case (CPU, Memory etc).
Remark: when you want to monitor the Citrix Server as a Server (application) Tier do not forget to remove the Network Tier called Citrix/WTS (presentation). Default this tier is present and all Citrix/WTS traffic captured is placed automatically under this tier.

Pre-requisites for Citrix traffic analysis monitoring to work optimally:

1)      Citrix/Terminal server decode required

2)      We need to see the traffic before the Citrix server on one AMD X using a sniffing interface


Session analysis (what does the user do via the Citrix or Windows Terminal server)

This part requires the TCAM agent. In essence, it’s nothing more than combining logins on the Citrix server with actions that are performed against other applications via the Citrix server. In this case the Citrix server is to be seen as a Client Tier as it acts as a Client on behalf of the real user. The benefit here is that we don’t need to enable any user recognition on the software services reached via Citrix, as we get the login and session from TCAM. As we have the TCAM here we also gather performance metrics (CPU, Memory, Disk I/O, Sessions) from the server.

NB: for the TCAM agent we do offer command line installation and configuration options in addition to the GUI. Companies like this a lot more as they usually don’t like to login to hundreds of servers to install and (re)configure the agent. J

More information can be found on https://community.compuwareapm.com/community/display/DCRUM123/Thin+Client+Analysis+Module

Pre-requisites for Citrix session analysis monitoring to work optimally:

1)      Citrix/Terminal server decode required

2)      We need to see the traffic before the Citrix server on one AMD X using a sniffing interface

3)      We need to see the traffic after the Citrix server on one AMD X using a sniffing interface

4)      TCAM needs to send its session and performance data with the correct IP assignment to one AMD X on the communication interface (default: UDP port 514)

5)      In case Citrix Secure Access Gateway or Network Address Translation (NAT) Appliance there are multiple ICA flows in front of the Citrix or Terminal server, the AMD should monitor only one flow before the Citrix or Terminal server. Therefore if there is a NAT/SAG choose one location to monitor. For example:

  1. Between the SAG/NAT and the Citrix Server or
  2. Before the SAG/NAT

Note: there are limitations in regards of NAT Resolution, for example Citrix XenApp 6.0 is not supported, Citrix Presentation Server 4.0 and XenApp 4.5, 5.0 require disabling session reliability feature for TCAM NAT resolution to work. https://community.compuwareapm.com/community/display/DCRUM123/TCAM+Administration+via+GUI

6)      The application used on the Citrix or Terminal server should run under the same user that logged in. In case the application used uses a service account, then the correlation will not be possible.

7)      The application used on the Citrix or Terminal server should open a communication to backend tiers for each end user transaction, because if it stays on the server itself, such as when using MS Word, Ms Excel then we cannot monitor this application, because it does not result in communication to backend tiers that the AMD can capture.
Note: this means application performance of application running solely on the Citrix or Terminal Server we cannot monitor and provide End User transactions. The same applies for Thick Client applications running on Citrix or Terminal server where one end user action result in numerous Database Queries. We can monitor the database queries and its performance, but we cannot provide the performance of the end user action itself, because it took place on the Citrix or Terminal server.

😎      In regards of configuration of the TCAM Agent sending data to the AMD’s

  1. Performance data should only be send to one AMD.    
  2. Session data can be send to multiple AMD’s that monitors either the frontend, backend or both frontend/backend traffic

 

Here is also a graphical explanation of the above:

 

Let me know if you have any further questions.

Kind regards,

Mark

 

4 REPLIES 4

ulf_thorn222
Inactive

Super good write up Mark!

For points 2&3 - does this need to be the same AMD for the user mapping to work?

mark_gerards
Dynatrace Pro
Dynatrace Pro

I never actually tested it, because often we have one AMD in a datacenter, therefore you monitor the frontend and the backend with the same AMD. However I would assume that we can use multiple AMD's for the user mapping to work. As long both AMD's receive the same user session data, because this mapping date contains the source ip, source port, dest ip, dest port and username. Which the AMD's uses to place the user name in the flow it monitored

I come to this conclusion, because in Thin Client Analysis Module#vtcam__section_131899110CA4414D9C388F63FDD39833 there is a note that warns when the correlation is not working. It does not state that it is required to capture both frontend and backend flow with the same AMD.

Never tested it though. So if someone else has experience please let us know.

Kind regards,

Mark

Is this not fully deprecated at this point, circa 2018? All traffic on our units is encrypted, so there is nothing readable by things like AMD, Cisco NBAR2, and such.


Edward, I've answered this question in another thread: https://answers.dynatrace.com/comments/208048/view.html. Perhaps Community could help you more direct if you shared your use case or challenges you are looking to address?

Cheers,

Kris