We are looking for the feasibility of DynaTrace One-Agent solution to monitor applications which are getting accessed via citrix XenApp server. I would like to know if DynaTrace one agent can monitor citrix based application. If yes/no, in any case what perfromance data/metrics we will get if deploy one agent
Hello @Meenakshi P.,
Dynatrace SAAS/One-Agent will only provide you OS level metrics (CPU/meomry/disk/logs etc) & process level resource consumption.
But for any Xenapp specific monitoring , there are below two options
1) NAM (formerly DCRUM) (as already mentioned by @rastislav d. above) : TCAM agents will provide you xenapp server level metrics and correlation between frontend/backend sessions decoded by ICA & ICA over SSL decodes , HTTP/HTTPS decodes for any web traffic on Netscalar.
old discussion for the same
And we also have Dynatrace -NAM unification that provides a single view of all data in your DYnatrace console
2) Dynatrace Enterprise Synthetic Monitoring OR ServiceTrace (https://www.servicetrace.de/servicetrace-robotic-s... )
Please check with further and look for what kind of citrix monitoring you need exactly and choose accordingly.
If you have NAM today, continue using it for Citrix monitoring. If you don't have NAM - plan for using OneAgent soon.
We are working on Dynatrace extension for Citrix monitoring, in a couple of months an EAP should start. This won't be a 100% NAM equivalent, but the basics of ICA latency, session count etc will be there. If you add deep infrastructure insight that comes standard with OneAgent, that brings a fresh perspective on Citrix monitoring, which is much needed in the light of changes that Citrix is implementing to its platform.
These changes would gradually make the NAM's life hard, especially the encryption that would prevent any app-level analysis of the network packets.
So going back to my first point: Use NAM if you have it and it works. It would for Citrix releases prior to 2018; it may or may not for newer ones (depends on your Citrix settings). Use AppFlow as a data source instead of AMD if possible; this works around the encryption challenge.
Hope this helps.