Granularidad y retención de datos

Agregar valores de datos

Monitor Service recopila diferentes 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:

• Los errores de máquinas y sesiones conectadas se producen durante un período. Por lo tanto, se exponen como máximos a lo largo de un 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 en las métricas 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, por lo que se exponen como sumas para un período de tiempo.

Evaluar datos simultáneos

Las sesiones deben superponerse para considerarse simultáneas. Sin embargo, cuando el intervalo temporal es de 1 minuto, todas las sesiones de ese minuto (tanto si se superponen como si no) se consideran simultáneas. El tamaño del intervalo es tan pequeño que la sobrecarga de rendimiento que implica el cálculo con precisión no compensa el valor agregado. Si las sesiones se producen en la misma hora, pero no en el mismo minuto, no se consideran superpuestas.

Correlacionar tablas de resumen con datos sin procesar

El modelo de datos representa las métricas de dos maneras diferentes:

• Las tablas de resumen representan vistas agregadas de las métricas 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 objetos.

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 métricas están diseñados para satisfacer las necesidades de tendencias históricas en períodos de tiempo prolongados. Estas métricas se agregan en la tabla de resumen para intervalos completos. No hay 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 esta. 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 tienen datos. Aunque podrían existir datos sin formato para esos intervalos parciales, estos datos no se resumirán. Para determinar el intervalo combinado más antiguo y 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.
• Correlación por tiempo. Las métricas se agregan en la tabla de resumen para intervalos completos, como se describe en la sección anterior. Se pueden usar para descubrir tendencias históricas, pero los eventos sin procesar podrían 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, se debe considerar que no hay datos de resumen para intervalos parciales que puedan ocurrir ni para el comienzo o el final del período de tiempo en cuestión.
• Eventos latentes y perdidos. Las métricas agregadas en tablas de resumen podrían ser ligeramente inexactas si hay eventos perdidos o latentes en el período 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, habrá huecos en los datos de resumen sobre los recuentos de las conexiones actuales, 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 siguiendo una programación de limpieza distinta de la programación para datos de eventos sin procesar. Podrían faltar datos porque se hayan limpiado las tablas de resumen y de datos sin procesar. Los períodos de retención también podrían 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, es posible 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 período de tiempo.
• Zonas horarias. Las métricas 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, podría haber una discrepancia en cuanto a dónde se agregan los datos.

Granularidad y retención

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. Los clientes de Premium pueden cambiar la retención de limpieza por la cantidad de días de retención que quieran; si no la cambian, se usa la predeterminada.

Para acceder a los parámetros, ejecute los siguientes comandos de PowerShell en el Delivery Controller:

asnp Citrix.*
 Get-MonitorConfiguration
 Set-MonitorConfiguration -<setting name> <value>
<!--NeedCopy-->

Precaución:

Modificar valores de la base de datos de Monitor Service requiere reiniciar el servicio para que los nuevos valores surtan 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.

Los parámetros GroomProcessUsageRawDataRetentionDays, GroomResourceUsageRawDataRetentionDays y GroomSessionMetricsDataRetentionDays se limitan a sus valores predeterminados de 1, mientras que GroomProcessUsageMinuteDataRetentionDays se limita a su valor predeterminado de 3. Los comandos de PowerShell para establecer estos valores se han inhabilitado, ya que los datos de uso del proceso tienden a crecer con rapidez. Asimismo, los parámetros de la retención basada en licencia son los siguientes:

• Sitios con licencias Premium: Se puede actualizar la configuración de retención de limpieza de datos con cualquier cantidad de días.
• Sitios con licencias Advanced: La retención de limpieza de datos para todos los parámetros se limita a 31 días.
• Todos los demás sitios: La retención de limpieza de datos para todos los parámetros se limita a 7 días.

Excepciones:

• GroomApplicationInstanceRetentionDays solo se puede establecer en sitios con licencia Premium.
• GroomApplicationErrorsRetentionDays y GroomApplicationFaultsRetentionDays están limitados a 31 días en sitios con licencia Premium.

La retención de datos durante largos períodos 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 podrían ser altos. Si la cantidad de datos es excesiva, el impacto en el rendimiento podría 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 crecen 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.