Citrix End User Experience Monitoring Rules
Horizon End User Experience Monitoring Rules
Configuring EUE Monitoring Rules
Reviewing and Tuning Monitoring Rule Settings
Step 2 - Monitor your Environment
Notification Options - Who Gets Alerts?
Overview
Goliath provides options for monitoring your Citrix and Horizon user's end user experiences when using published applications, published desktops and virtual desktops (VDI). Monitoring end user experience is crucial for ensuring user satisfaction, optimizing business performance, and proactively resolving issues before they impact operations.
Goliath provides these options using Monitoring Rules provided out-of-the-box with built-in thresholds based on industry best practices to ensure optimal end user experiences. Any time a user's session exceeds any of the defined thresholds, an alert is generated. How often and when the alert happens and who receives those alerts are all configurable options that should be considered based on your environment. This guide provides best practices for configuring these monitors and associated alerts.
Goliath's End User Experience Monitoring Rules for Citrix and Horizon
- Citrix XenApp - Session & Server Performance
- Citrix XenDesktop - VDI Session & VDI Availability
- VMware Horizon View - Session & Server Performance
EUE Monitoring Rules Defined
Each EUE Monitoring rule includes multiple thresholds that determine when an alert is generated. Some metrics also include a duration option to help determine if an actual issue exists versus a single isolated instance, for example, Network Latency spiking for a couple seconds which would be unnoticeable versus a sustained increase in Network Latency over a 10 minute period.
Review the sections below for more detail on each metric as well as associated options.
Citrix End User Experience Monitoring Rules
The Citrix End User Experience Monitoring Rules include two separate rules, one for published apps and desktops and one for VDI.
The following tables describe the EUE metrics monitored, the out of the box defined thresholds, and durations for each rule type. Any metrics that does not have values defined below indicates these are not included out of the box as they typically vary by environment.
Figure: Citrix XenApp - Session & Server Performance monitoring rule
Table - Citrix XenApp End User Experience Metrics
| Metric | Threshold Value | Duration | Notes |
| ICA Latency | 400 ms | 5 min | |
| ICA Round Trip Time | 400 ms | 5 min | |
| Network Latency | 250 ms | 5 min | |
| Connection Speed | 9 Mbps | 5 min | Connection speed alerts when metric falls BELOW value |
| Server Load | Defines how busy a XA server is from 0 - 10000 | ||
| Logon Duration | Define the time in seconds to alert on. Citrix. Typically, users begin to notice an issue after 45-60 seconds. | ||
| Active Users | Define number of users on the XA server to alert on | ||
| Active Sessions | Define number of sessions on the XA server to alert on |
Figure: Citrix XenDesktop - VDI Session & VDI Availability monitoring rule
Table - Citrix XenDesktop End User Experience Metrics
| Metric | Threshold Value | Duration | Notes |
| ICA Latency | 400 ms | 5 min | |
| ICA Round Trip Time | 400 ms | 5 min | |
| Network Latency | 250 ms | 5 min | |
| Connection Speed | 9 Mbps | 5 min | Connection speed alerts when metric falls BELOW value |
| Unregistered VDI | |||
| Logon Duration | Define the time in seconds to alert on. Typically, users begin to notice an issue after 45-60 seconds. | ||
| Active Users | Define number of users on the XA server to alert on | ||
| Active Sessions | Define number of sessions on the XA server to alert on |
Horizon End User Experience Monitoring Rules
The VMware Horizon end user experience monitoring rule monitors the EUE metrics described in the table below. Any metrics that does not have values defined below indicates these are not included out of the box as they typically vary by environment.
Figure: VMware Horizon View - Session & Server Performance monitoring rule
Table - Horizon End User Experience Metrics
| Metric | Threshold Value | Duration | Notes |
| Round Trip Time | 400 ms | 5 min | |
| FPS | |||
| Network Latency | 250 ms | 5 min | |
| Logon Duration | Define the time in seconds to alert on. Typically, users begin to notice an issue after 45-60 seconds. |
Configuring EUE Monitoring Rules
Each customer environment is different, but in most cases, the thresholds included here, based on industry best practices, will indicate when your users are having issues that impact their experience.
Before configuring rules, as part of your initial implementation, you will need to configure your server groups to easily select which devices you will monitor for your end user sessions. Refer to the following articles for additional details:
Additional information on initial implementation for Citrix Virtual Apps and Desktops and VMware Horizon:
- Citrix Virtual Apps and Desktops Monitoring Configuration Guide
- VMware Horizon Monitoring Configuration Guide
Reviewing and Tuning Monitoring Rule Settings
When you first configure your EUE rules, it is recommended that you use the default thresholds and durations defined here. Also, leave the notifications options as is without including any email addresses configured, until you've tuned your configuration. The following sections describe the steps you will take to initially configure and tune your EUE monitoring rules.
Step 1 - Configure Rules
You'll configure your monitoring rules by selecting the devices on which Citrix or Horizon sessions are being served. For example, you can select all XenApp machines to capture alerts from your published app or desktop session users.
Figure: Device selection in Monitoring Rule dialog
Step 2 - Monitor your Environment
After configuring and saving the rule, allow it to run in your environment for about a week. Next you'll review the results and begin tuning your configuration.
Segmenting Monitoring Rules
Depending on the size of your environment, you may want to segment monitoring to focus only on certain areas within the environment. For example, in larger companies you may have teams dispersed across the country with dedicated resources. Sales in New York and Development in Boston. In this case, you can create a rule and select only the Citrix servers that serve those end users in New York. Then create an additional rule and select the second group of servers that provide sessions to your Boston end users.
Step 3 - Review Alert Results
After the initial period of time where your rule runs, about a week, you will use the available reports and dashboards in Goliath to review how your environment is performing.
During this tuning period you have options for viewing the generated alerts. Use the Dashboard - Alerts page as well as Alert Analysis reports to understand how many and of which type of alerts are being generated.
Figure: Dashboard - Alerts
The Alerts dashboard shows all alerts that were generated by Goliath. You can search and filter the alerts here to quickly see recent alerts during your tuning period to better understand how often alerts are created based on the initial settings.
Figure: Alert Analysis Report
The alert analysis report can be configured to display all EUE monitoring rules that alerted over the initial tuning period. Here you can determine which and how many of each type of alert was generated, then make adjustments based on your individual environment expectations. Alert totals are displayed at the top of the report and each individual alert instance are both included in the report.
The total indicates how many of each alert type would have been emailed to you or your alerting system as well. This is important to note as you do not want to have values set that can create alert fatigue. Review the number and frequency of alerts here and make adjustments as necessary.
(For more information about creating reports in Goliath see: Creating a Report.)
If you encounter many alerts that are being generated from a single user (user info is included in the "Reason" column of the alert report), you can contact that user and verify if they are having issues. From here you will have options based on their response. If they are encountering issues you know the configuration is adequate. If they are not, you will need to adjust the thresholds or durations to better capture.
Scheduling Reports
The Alert Analysis report can be scheduled to review periodically, daily, weekly, during your tuning period to understand the overall alerts being generated. You can also use this on an ongoing basis to review alerts generated and understand where there are issues happening in your environment.
Note: Goliath reports can be exported to CSV to do any additional analysis as needed. You can export the report from the Reports page in the product or you can automatically generate a CSV file each time the report is run using the options in the Report wizard.
Step 4 - Tune and Review
After reviewing your alert results, make adjustments as needed to ensure you're capturing effective alerts that accurately represent end user experience issues. This involves looking at the current thresholds and making the adjustments within the monitoring rule.
Adjusting Alert Thresholds
After the initial tuning period of a couple weeks, you may determine the thresholds are set either too low or too high for your environment, or that the durations are not right. You can edit the rule and quickly change any of the options to better fit your environment.
For example, some companies with many offshore workers may experience higher latency. Increasing the default to 400 ms or 500 ms can reduce alerts from those areas where this is acceptable based on your guidelines.
There may also be cases where one metric may be less important or you may have less control over the systems that impact that metric, like Network Latency. Some larger companies have big, distributed teams that may not always have clear lines of communication. In these cases, you can always remove the threshold value in the monitor dialog, editing the monitoring rule dialog and deleting the threshold for Network Latency, then saving the rule, for example, will ensure no alert was ever generated for Network Latency, as seen in the example figure below:\.
Figure: Citrix XenApp EUE Monitoring with Network Latency monitor disabled
Adjusting Alert Frequency
In addition to thresholds, during and after the tuning period you will also want to adjust when and how often alerts are generated per EUE monitor. For example, you may only need to be alerted once time when Connection speed drops below the threshold, after which time you can investigate the issue without the need to create an alert storm in the case of a sustained outage.
To ensure you are receiving alerts from your End User Experience monitors, but also ensure you're not creating alert fatigue where you may receive too many alerts, use the Schedule tab within each monitoring rule dialog.
Figure: Schedule tab
Set the Minimum Notification Interval to only generate a new alert for the same condition after the defined time frame expires. For example, with Alert every time unselected, and a minimum interval of 10 minutes, if an ICA Latency threshold is exceeded for a user session, an alert will be generated, but no additional alerts will be generated until 10 minutes has passed since the initial alert, ensuring you are not overloaded with the same alert for an issue you are already investigating.
You will want to let the rules work again for another week and repeat the review and tuning step once again. When you are satisfied with the configuration of your monitoring rule and the number of alerts that are being generated, you will next want to set up notifications to ensure the right people are alerted and can begin troubleshooting issues.
Notification Options - Who Gets Alerts?
Defining who receives alerts and how they are generated is accomplished using the Notifications tab within each Monitoring rule dialog.
Figure: Notifications tab
For the majority of notifications, customers select the Email Notification checkbox to enable emails to be sent to all addresses included in the Email Address field. Use Email Groups to quickly send emails to multiple users based on the machines / sessions being monitored.
If you need to integrate your notifications with other tools like ServiceNow, refer to the following documents sections of the knowledge base:
Enhanced EUE Monitoring
Goliath is continually making updates to improve customer's experience with our products. One of the exciting new updates on the current product roadmap is Enhanced EUE Monitoring.
This new monitoring rule type gives you the option to alert not when a just single instance of a metric threshold is exceeded in a session, but instead, alert when a when a threshold is exceeded for a defined number of instances, within a selected group, over a set timeframe. For example: When 50 instances of ICA RTT exceed 450ms, within the Goliath Sales Active Directory organizational unit, over a 1-hour timeframe, generate an alert.
Figure: Enhanced EUE Monitoring Rule
In addition to aggregate-based rules, you can also alert when select users encounter end user experience issues. For example, when Doctor Smith’s logon duration exceeds 60 seconds, or Doctor Jones’ ICA Latency exceeds 450ms for 5 minutes, generate an alert.
We're looking forward to getting this new rule type out to our customers and we are eager to hear your feedback.
Feedback
Goliath is always interested in hearing your feedback about current and planned features and enhancements. Email: support@goliathtechnologies.com