In my role as a Dynatrace Consultant I’ve had the opportunity to visit customers repeatedly over extended periods of time. This has allowed me to contribute to different approaches to solving problems, and to observe how well the solutions fit the unique needs of each customer.
It helps if you’ve seen certain use cases before; however, there are always cases when you come across a customer whose requirements initially sound similar to other customers’ requirements but, once you arrive on site, you find it’s bit more challenging than described. Monitoring the availability and performance of Citrix environments tends to belong in this category.
Whether using Citrix due to security or serviceability reasons, for example: allowing remote access to an application – or several — which would otherwise require installation of a fat client on end-user machines, or for scalability reasons such as still having no choice but to keep using that legacy application that was designed a decade ago, before the company had grown to expand to far-away regions, and which was never designed to handle any more network latency than that between the 3rd floor and the server room in the basement. Or, for any other of the many reasons which may lead you to decide in favor of using Citrix to publish your application, monitoring your end-users’ Citrix experience is always a bit of a challenge, and in many cases, an afterthought.
The ICA protocol used for publishing applications in Citrix is designed to provide visual information independently of the application being published and to transport mouse clicks and keyboard events (in addition to other channels e.g. for printing and file transfer) which makes it inherently transaction-unaware (unlike other protocols like HTTP, SAP, MS Exchange and many others). A mouse click can start a transaction in an application, but it can also change a window’s appearance, place the cursor somewhere or turn over a virtual playing card. This lack of a fixed semantic for mouse clicks or keyboard entries makes it next to impossible to establish a clear relationship between a user action and an expected response on the application side.
Re-introducing Transactions into ICA
When monitoring application performance, you usually want the exact opposite: you want to know what transactions users executed, and whether they were successful and how long they took. That’s not possible by just looking at the ICA protocol, because it can’t offer that kind of transaction semantic.
If your company offers hosting applications for customers, and you’re using Citrix to publish these applications, then that poses a problem the moment you also have to agree to an SLA. How can you prove that users are able to execute transactions on the system when there are no transactions present in the protocol? Even if you’re not a hosting provider, you probably have the same concerns as you deliver applications to your internal users.
Since you have to prove you’re within your SLA in such an arrangement, you may already have some kind of synthetic (active) monitoring in place in which dedicated machines (“agents” in our parlance, “robots” in that of many customers) run scripted transactions around the clock on your system to see whether it’s still available, and to measure how quickly it responds, and to send out an alert in case it doesn’t. You need synthetic monitoring in place if you want to prove you’re within your SLA, because looking at log files or monitoring user traffic will not tell you about the system’s availability at times when there are no users on the system (there may be one the next second, though). The same synthetic monitoring system also allows you to incorporate transaction visibility into your Citrix monitoring because the Synthetic Agents (the machines running the scripted transactions) know which actions they’re executing, and you can assign meaning to their actions. If one of their actions fail, you will know whether it’s the login step that failed or whichever other step in your application it was – the Agents assign the transactions.
Where is the Problem?
The next challenge when monitoring applications using Citrix is determining whether a problem is a Citrix problem, or whether it’s a problem with the application itself. Synthetic monitoring offers a simple a solution to this: monitor the application from inside the data center (without Citrix) and also from outside the data center (with Citrix).
This approach should help you to quickly isolate the location of a problem. Since running automated scripts in a Citrix environment can be challenging due to changing image quality (Citrix can dynamically adjust graphics quality according to current network conditions, which are subject to change even in the most stable environments), using dual perspectives also helps to improve script reliability. For agents running inside the data center, you can take full advantage of screen object recognition capabilities and design comprehensive tests that exercise a broad set of application functions. Remote agents using the Citrix ICA channel can run simpler scripts, testing for external fundamentals such as connectivity and network quality. This reduces the chances of distracting script-related errors. A very basic check is enough to determine whether your Citrix environment is up and running, more detailed checks may be required to find out whether every component of your application still behaves as it should.
Citrix end-user experience visibility
A synthetic monitoring approach to Citrix availability and performance visibility has significant benefits, including SLA measurement, early warning of problems, and reliable baseline data. Many companies choose to incorporate real-user monitoring for their Citrix-delivered applications as well; in fact, synthetic and real user monitoring are quite complementary. Dynatrace offers the industry’s most comprehensive set of end-user experience monitoring solutions for a broad range of application environments. Our multi-faceted visibility into Citrix environments gives us a unique set of capabilities; learn more by reading some of our Citrix blogs, by browsing the Citrix content on our website, or by viewing our Citrix Ready solution content.