Product Documentation

Acceso a datos usando la API

Feb 14, 2017

Los siguientes tipos de datos están disponibles por medio de la API de Monitor Service:

  • Datos relacionados con fallos de conexión
  • Máquinas en un estado de error
  • Uso de las sesiones
  • Duración de los inicios de sesión
  • Datos de equilibrio de carga
  • Revisiones aplicadas a una máquina
  • Uso de aplicaciones alojadas

Para obtener una descripción completa de los objetos de datos, consulte http://blogs.citrix.com/2013/08/27/xendesktop-7-monitor-service-what-data-is-available/

Para usar la API de OData de Monitor Service, debe ser un administrador de XenApp o XenDesktop. Para llamar a la API necesita privilegios de solo lectura; sin embargo, los datos devueltos vienen determinados por los roles y los permisos de administrador de XenApp o XenDesktop. Por ejemplo, los administradores de grupos de entrega pueden llamar a la API de Monitor Service, pero los datos que pueden obtener están controlados por el acceso a grupos de entrega configurado con Citrix Studio. Para obtener más información sobre los roles y permisos de administrador de XenApp o XenDesktop, consulte Administración delegada.

Consulta de datos

La API de Monitor Service es una API basada en REST a la que se puede acceder con un consumidor de OData. Los consumidores de OData son aplicaciones que consumen datos expuestos mediante el protocolo OData. Los consumidores de OData varían en complejidad; desde los exploradores Web más simples hasta aplicaciones personalizadas que pueden beneficiarse de todas las funciones del protocolo OData. Para obtener más información acerca de los consumidores de OData, consulte http://www.odata.org/ecosystem#consumers.

Cada parte del modelo de datos de Monitor Service es accesible y se puede filtrar en la URL. OData ofrece un lenguaje de consulta en el formato de la URL que puede utilizar para recuperar las entradas de un servicio. Para obtener más información, consulte http://msdn.microsoft.com/en-us/biblioteca/ff478141.aspx.

La consulta se procesa en el lado del servidor y se puede filtrar más mediante el protocolo OData en el lado del cliente.

Los datos modelados son de tres categorías: datos agregados (las tablas de resumen), el estado actual de los objetos (máquinas, sesiones, etc.) y los datos de registros, que son eventos históricos (por ejemplo, conexiones).

Nota: Las enumeraciones no son compatibles con el protocolo OData; en su lugar, se utilizan enteros. Para determinar los valores devueltos por la API de Monitor Service OData, consulte http://support.citrix.com/help/monitorserviceapi/7.6/.

Agregación de los valores de datos

Monitor Service recopila una serie de datos, incluidos el uso de las sesiones de usuario, la información del rendimiento de los inicios de sesión de usuario, la información del equilibrio de carga de las sesiones y la información de fallos de conexión y de las máquinas. Los datos se agregan de forma diferente en función de la categoría. Para interpretar los datos, es fundamental comprender la agregación de los valores de los datos presentados mediante las API de Método de OData. Por ejemplo:

  • Las sesiones conectadas y los fallos de máquina se producen durante un período de tiempo, por lo que se exponen como máximos a lo largo de ese período de tiempo.
  • La duración del inicio de sesión es una medida de tiempo, por lo que se expone como el promedio de mediciones tomadas a lo largo de un período de tiempo.
  • Los recuentos de inicio de sesión y los fallos de conexión son el número de casos a lo largo de un período de tiempo, por lo que se exponen como sumas para un período de tiempo.

Evaluación de datos simultáneos

Las sesiones deben superponerse para considerarse simultáneas. No obstante, cuando el intervalo de tiempo es de 1 minuto, todas las sesiones en ese minuto (se superpongan o no) se consideran simultáneas; es decir, el tamaño del intervalo es tan pequeño que se considera que el esfuerzo de rendimiento que conlleva un cálculo más preciso no añade mucho valor. Si las sesiones se producen en la misma hora, pero no en el mismo minuto, no se consideran superpuestas.

Correlación de las tablas de resumen con los datos sin procesar

El modelo de datos representa las mediciones de dos maneras diferentes:
  • Las tablas de resumen representan vistas agregadas de las mediciones por minuto, por hora y por día.
  • Los datos sin procesar representan eventos individuales o de estado actual de seguimiento de una sesión, conexión, aplicación y otros ob4jetos.

Al intentar establecer una correlación entre las llamadas de la API o en el modelo de datos mismo, es importante comprender los conceptos y las limitaciones siguientes:

  • No hay datos de resumen para intervalos parciales. Los resúmenes de mediciones están diseñados para satisfacer las necesidades de tendencias históricas en períodos de tiempo prolongados. Estas mediciones se agregan en la tabla de resumen para intervalos completos. No habrá datos de resumen para un intervalo parcial al comienzo (en los datos más antiguos) de la recopilación de datos ni al final de la misma. Cuando se consultan los datos agregados de un día (Intervalo=1440), esto significa que los días incompletos al principio y los más recientes no tendrán datos. Aunque es posible que existan datos sin formato para esos intervalos parciales, estos datos no se resumirán. Para determinar el intervalo combinado más antiguo y más reciente para una granularidad de datos en particular, se puede usar la fecha de resumen (SummaryDate) máxima y mínima de una tabla de resumen. La columna SummaryDate representa el inicio del intervalo. El valor de la columna Granularity representa la duración del intervalo para los datos agregados.
  • Agregación por tiempo. Las mediciones se agregan en la tabla de resumen para intervalos completos, como se ha descrito antes. Se pueden usar para descubrir tendencias históricas, pero los eventos sin procesar pueden ser más actualizados en los datos de estado que lo que se resumió para el análisis de tendencias. En cualquier comparación basada en el tiempo entre datos de resumen y datos sin procesar, hay que tener en cuenta que no habrá datos de resumen para intervalos parciales que puedan ocurrir ni para el comienzo o el final del periodo de tiempo en cuestión.
  • Eventos latentes y perdidos. Las mediciones agregadas en tablas de resumen pueden ser ligeramente inexactas si hay eventos perdidos o latentes en el periodo de agregación. Aunque Monitor Service intenta mantener un alto nivel de precisión del estado actual, no vuelve atrás en el tiempo para recalcular la agregación en las tablas de resumen para eventos perdidos o latentes.
  • Alta disponibilidad de conexiones. Durante la alta disponibilidad de conexiones (HA), habrá huecos en los recuentos de conexiones actuales en los datos de resumen, pero las instancias de sesión seguirán ejecutándose en los datos sin procesar.
  • Períodos de retención de datos. Los datos de las tablas de resumen se conservan en una programación de limpieza distinta de la programación para datos de eventos sin procesar. Puede que falten datos porque se hayan limpiado las tablas de resumen y de datos sin procesar. Los períodos de retención también pueden diferir según las distintas granularidades de los datos de resumen. Una granularidad de datos menor (minutos) se limpia más rápidamente que una granularidad de datos mayor (días). Si faltan datos de una granularidad debido a una limpieza, puede que los que encuentre en una granularidad mayor. Puesto que las llamadas de API solo devuelven la granularidad solicitada, si no se reciben datos para una granularidad, eso no significa que los datos no existan en una granularidad mayor, para el mismo periodo de tiempo.
  • Zonas horarias. Las mediciones se guardan con marcas de hora UTC. Las tablas de resumen se agregan en límites de una hora de la zona horaria. Para las zonas horarias que no caen en límites de una hora, puede haber una discrepancia en cuanto a dónde se agregan los datos.

Granularidad y retención de datos

La granularidad de los datos agregados obtenida por Director es una función del intervalo de tiempo (T) solicitado. Las reglas son las siguientes:
  • 0 < T < = 1 hora, se utiliza granularidad de minutos
  • 0 < T <= 30 días, se utiliza granularidad de horas
  • T > 31 días, se utiliza granularidad de días

Los datos solicitados que no provienen de datos agregados provienen de la información sin procesar sobre sesiones y conexiones. Estos datos tienden a aumentar rápidamente y, por lo tanto, tienen su propia configuración de limpieza. La limpieza de la base de datos garantiza que solo se conserven los datos que sean relevantes a largo plazo. Esto garantiza un mejor rendimiento, al tiempo que se mantiene la granularidad necesaria para crear informes. Para los clientes que no tienen licencia para usar la edición Platinum, la limpieza se inicia al día 8, independientemente de la retención de limpieza predeterminada. Los clientes de Platinum pueden cambiar la retención de limpieza por la cantidad de días de retención que deseen; si no la cambian, se usa la predeterminada.

Los parámetros siguientes se usan para controlar la limpieza:

Nombre del parámetroLimpieza afectadaValor predeterminado (días)Se accede mediante
GroomSessionsRetentionDaysRegistros de Session y SessionDetail90Cmdlet (set/get-monitorconfiguration)
GroomSummariesRetentionDaysRegistros de DesktopGroupSummary, FailureLogSummary y LoadIndexSummary. Datos agregados, de granularidad diaria.90Cmdlet (set/get-monitorconfiguration)
GroomHourlyRetentionDaysDatos agregados, de granularidad horaria32Tabla de base de datos Monitor.Configuration. Consulte la nota de abajo.
GroomMinuteRetentionDaysDatos agregados, de granularidad de minuto3Tabla de base de datos Monitor.Configuration. Consulte la nota de abajo.
GroomFailuresRetentionDaysRegistros de MachineFailureLog y ConnectionFailureLog90Cmdlet (set/get-monitorconfiguration)
GroomLoadIndexesRetentionDaysRegistros de LoadIndex90Cmdlet (set/get-monitorconfiguration)
GroomDeletedRetentionDaysEntidades de catálogo de máquinas, grupo de escritorios e hipervisor cuyo estado de ciclo de vida (LifecycleState) es 'Eliminado' (Deleted). Esta acción también eliminará los registros de Session, SessionDetail, Summary, Failure o LoadIndex relacionados.90Cmdlet (set/get-monitorconfiguration)
GroomMachineHotfixHistoryRetentionDaysRevisiones hotfix aplicadas a las máquinas de VDA y Controllers90Cmdlet (set/get-monitorconfiguration)
Precaución: La modificación de los valores de la base de datos del servicio de supervisión (Monitor Service) requiere reiniciar el servicio para que los nuevos valores tengan efecto. Se recomienda realizar cambios en la base de datos de Monitor Service solo cuando se lo indique el personal de asistencia técnica de Citrix.

Notas sobre la retención de la limpieza de datos:

  • Los clientes de la edición Platinum pueden cambiar la retención de la limpieza de datos a la cantidad de días de retención que quieran; si no la cambian, se usa la predeterminada.
  • Para los clientes de la edición Enterprise, la limpieza de datos se inicia el día 32. 
  • Para los clientes de ediciones que no sean Platinum ni Enterprise, la limpieza de datos se inicia el día 8. 
La retención de datos durante largos periodos de tiempo tiene las implicaciones siguientes en los tamaños de las tablas:
  • Datos por hora. Si se conservan datos por hora en la base de datos durante dos años, un sitio con 1000 grupos de entrega puede hacer que la base de datos crezca así:

    1000 grupos de entrega x 24 horas/día x 365 días/año x 2 años = 17 520 000 filas de datos. El impacto que esta gran cantidad de datos tiene en el rendimiento de las tablas agregadas es importante. Puesto que los datos de panel de mandos se sacan de esta tabla, los requisitos del servidor de la base de datos pueden ser altos. Si la cantidad de datos es excesiva, el impacto en el rendimiento puede resultar significativo.

  • Datos de sesiones y eventos. Estos datos se recopilan cada vez que comienza una sesión y se realiza una conexión o reconexión. En sitios grandes (100 000 usuarios), estos datos pueden crecer muy rápidamente. Por ejemplo, las tablas correspondientes a dos años recopilarían más de un TB de datos, para lo cual se necesitaría una base de datos de nivel empresarial de gama alta.