The following types of data are available through the Monitor Service API:
For a full description of the data objects, see http://blogs.citrix.com/2013/08/27/xendesktop-7-monitor-service-what-data-is-available/.
To use the Monitor Service OData API, you must be a XenApp or XenDesktop administrator. To call the API, you require read-only privileges; however, the data returned is determined by XenApp or XenDesktop administrator roles and permissions. For example, Delivery Group Administrators can call the Monitor Service API but the data they can obtain is controlled by Delivery Group access set up using Citrix Studio. For more information about XenApp or XenDesktop administrator roles and permissions, see Delegated Administration.
Querying the data
The Monitor Service API is a REST-based API that can be accessed using an OData consumer. OData consumers are applications that consume data exposed using the OData protocol. OData consumers vary in sophistication from simple web browsers to custom applications that can take advantage of all the features of the OData Protocol. For more information about OData consumers, see: http://www.odata.org/ecosystem#consumers.
Every part of the Monitor Service data model is accessible and can be filtered on the URL. OData provides a query language in the URL format you can use to retrieve entries from a service. For more information, see: http://msdn.microsoft.com/en-us/library/ff478141.aspx
The query is processed on the server side and can be filtered further using the OData protocol on the client side.
The data modeled falls into three categories: aggregate data (the summary tables), current state of objects (machines, sessions, etc), and log data, which is really historical events (connections, for example).
Aggregation of data values
The Monitor Service collects a variety of data, including user session usage, user logon performance details, session load balancing details, and connection and machine failure information. Data is aggregated differently depending on its category. Understanding the aggregation of data values presented using the OData Method APIs is critical to interpreting the data. For example:
Concurrent data evaluation
Sessions must be overlapping to be considered concurrent. However, when the time interval is 1 minute, all sessions in that minute (whether or not they overlap) are considered concurrent: the size of the interval is so small that the performance overhead involved in calculating the precision is not worth the value added. If the sessions occur in the same hour, but not in the same minute, they are not considered to overlap.
Correlation of summary tables with raw data
When attempting to correlate data across API calls or within the data model itself, it is important to understand the following concepts and limitations:
Data granularity and retention
Requested data that does not come from aggregated data comes from the raw Session and Connection information. This data tends to grow fast, and therefore has its own grooming setting. Grooming ensures that only relevant data is kept long term. This ensures better performance while maintaining the granularity required for reporting. For customers who are not licensed to use the Platinum edition, grooming begins at day 8 regardless of the default grooming retention. Platinum customers can change the grooming retention to their desired number of retention days, otherwise the default is used.
The following settings are used to control grooming:
|Setting name||Affected grooming||Default value (days)||Accessed using|
|GroomSessionsRetentionDays||Session and SessionDetail records||7 for non-Platinum users, 90 for Platinum||Cmdlet (set/get-monitorconfiguration)|
|GroomSummariesRetentionDays||DesktopGroupSummary, FailureLogSummary and LoadIndexSummary records. Aggregated data - daily granularity.||7 for non-Platinum users, 90 for Platinum||Cmdlet (set/get-monitorconfiguration)|
|GroomHourlyRetentionDays||Aggregated data - hourly granularity||32 days||Monitor.Configuration Database Table. See note below.|
|GroomMinuteRetentionDays||Aggregated data - minute granularity||3 days||Monitor.Configuration Database Table. See note below.|
|GroomFailuresRetentionDays||MachineFailureLog and ConnectionFailureLog records||7 for non-Platinum users, 90 for Platinum||Cmdlet (set/get-monitorconfiguration)|
|GroomLoadIndexesRetentionDays||LoadIndex records||7 for non-Platinum users, 90 for Platinum||Cmdlet (set/get-monitorconfiguration)|
|GroomDeletedRetentionDays||Machine, Catalog, DesktopGroup and Hypervisor entities that have a LifecycleState of 'Deleted'. This will also delete any related Session, SessionDetail, Summary, Failure or LoadIndex records.||7 for non-Platinum users, 90 for Platinum||Cmdlet (set/get-monitorconfiguration)|
|GroomMachineHotfixHistoryRetentionDays||Hotfixes applied to the VDA and Controller machines||90 for both non-Platinum and Platinum users||Cmdlet (set/get-monitorconfiguration)|
1000 delivery groups x 24 hours/day x 365 days/year x 2 years = 17,520,000 rows of data. The performance impact of such a large amount of data in the aggregation tables is significant. Given that the dashboard data is drawn from this table, the requirements on the database server may be large. Excessively large amounts of data may have a dramatic impact on performance.