The Omnissa Horizon monitoring rule allows one to monitor VMware Horizon Protocol, Session & User Thresholds using our Goliath Intelligent Agent to alert on specified conditions in real-time.

By default, when the Horizon API is enabled, a monitoring rule named Omnissa Horizon - Session & Server Performance will be created out of the box in which you can modify and enable for alerting.

Create a New Monitoring Rule

1. To create a new monitoring condition, navigate to the Management - Monitors page and click the New button.
2. Select a Group to store the rule - this is for visual purposes on the Monitors page. Pick a group that meets your needs.
3. From the Type option select Omnissa Horizon Session.
4. Name the Monitoring Rule via the Rule Name field, as well as define the description and the severity.
5. Next, select the Devices to include in the rule. Only Horizon servers that support the sessions you want to monitor should be selected.
   1. Please note, a machine can only be applied to one VMware Horizon View monitoring rule type at a time. If there is no checkbox option, hover over the bell icon to get the name of the monitoring rule that the machine is currently applied to
6. In the Options tab, define condition(s) to be monitored.
   1. Note, only fields with values will be monitored. If you do not wish to monitor a particular metric do not enter a value in the field.
   2. The monitoring rule will trigger on a per metric basis.
   3. RTT and Duration: Define the threshold for RTT and the duration value that needs to be exceeded in order to alert.
   4. FPS and Duration: Define the threshold for FPS and the duration value that needs to be exceeded in order to alert.
   5. Network Latency and Duration: Define the threshold for Network Latency and the duration value that needs to be exceeded in order to alert.
   6. Logon Duration: Define the length of the logon threshold needed in order to alert.
7. Next, use the Schedule tab to define how frequently the rule will alert. This can be done by adjusting the following fields: Required Options (one of the below must be selected):

• Alert Every Time: Defines whether an alert is generated every time the conditions are on the previous tab are met.
  • When checked, an alert is generated every time the specified condition is met.
  • When unchecked, the alert is only generated if the alert conditions are met, and the Minimal Notification Interval, see below, is exceeded since the last alert for this type.
• Minimal Notification Interval: Defines the minimum amount of time that must elapse between events for the specified condition before another alert will be generated.
  • For example, if the interval is 15 minutes and the condition is being met every 3 mins, you will receive 1 alert every 15 minutes instead of being alerted at each occurrence.
    • However, each alert occurrence is considered unique based on the details. For example, an Event Log alert is considered the same based on being the same Event Type and ID, from the same server/workstation.
  • The Alert Every Time checkbox must be unchecked in order to use this option.
  • For ServerWatch IP Services, this also defines the minimum elapsed time since a service is first detected as down or failed before an alert is generated.

Additional Options: 

• Maximum Notification Interval: Defines the maximum number of times you want to be notified during a continuous failure situation.
  • The default value of '0' means infinite; no maximum is defined so you will continue to be notified according to your Alert Every Time and Minimal Notification Interval settings.
  • A non-zero value means that after you have been notified the number of times defined in the Maximum Alert Notifications, and according to your Alert Every Time and Minimal Notification Interval settings, you will not be notified again.
    • For example, if "5" is selected, the event will alert for the first 5 events and all additional events will be ignored.
• Notify On Restore: Defines whether a 'Restore' alert is generated if you have previously been alerted due to a failure.
  • For example, if CPU has been 90%, and then dropped below the alert threshold, the notify on restore email will inform you that the condition has returned to a normal state.
  • There is always a Notify on Restore for a ServerWatch type alerts.
• Service Check Frequency, Every: Defines the frequency with which the service specified for this Monitoring Rule is checked. It is no recommended to do this check any fewer then 3 mins. 
• Alert 1^st Time After X Failures: Define a value 1 or greater that defines how many successive failures should occur before the 1^st alert notification 'Action' is executed.
  • The Alert Every Time and Minimum Notification Interval settings do no become applicable until after this threshold setting is exceeded.
  • The default value for this setting is blank which means not applicable. When not applicable, the Alert Every Time and Minimum Notification Interval settings are active immediately and the 1^st alert does not occur until the Minimum Notification Interval threshold is equaled or exceeded if it is active.

Additional Configuration

For additional configuration options please see the following articles:

• Enabling Notifications:
  • Configure Email and Text Alert Notifications
  • Configure SNMP Alert Notifications
  • Configure Syslog Alert Notifications
• Configure Custom Remediation