Granularidade e retenção de dados

Agregação de valores de dados

O Monitor Service coleta vários dados, incluindo uso de sessão do usuário, detalhes de desempenho de logon do usuário, detalhes de balanceamento de carga de sessão e informações de falha de conexão e máquina. Os dados são agregados de forma diferente dependendo de sua categoria. Compreender a agregação de valores de dados apresentados usando as APIs do Método OData é fundamental para interpretar os dados. Por exemplo:

• Sessões Conectadas e Falhas de Máquina ocorrem durante um período. Portanto, são expostas como máximos em um período de tempo.
• A Duração do Logon é uma medida do período de tempo, portanto, é exposta como uma média em um período de tempo.
• A Contagem de Logon e as Falhas de Conexão são contagens de ocorrências em um período, portanto, são expostas como somas em um período de tempo.

Avaliação de dados concorrentes

As sessões devem se sobrepor para serem consideradas concorrentes. No entanto, quando o intervalo de tempo é de 1 minuto, todas as sessões nesse minuto (independentemente de se sobreporem) são consideradas concorrentes. O tamanho do intervalo é tão pequeno que a sobrecarga de desempenho envolvida no cálculo da precisão não compensa o valor adicionado. Se as sessões ocorrem na mesma hora, mas não no mesmo minuto, elas não são consideradas sobrepostas.

Correlação de tabelas de resumo com dados brutos

O modelo de dados representa métricas de duas maneiras diferentes:

• As tabelas de resumo representam visualizações agregadas das métricas em granularidades de tempo por minuto, hora e dia.
• Os dados brutos representam eventos individuais ou o estado atual rastreado na sessão, conexão, aplicativo e outros objetos.

Ao tentar correlacionar dados entre chamadas de API ou dentro do próprio modelo de dados, é importante entender os seguintes conceitos e limitações:

• Sem dados de resumo para intervalos parciais. Os resumos de métricas são projetados para atender às necessidades de tendências históricas em longos períodos de tempo. Essas métricas são agregadas na tabela de resumo para intervalos completos. Não há dados de resumo para um intervalo parcial no início (dados mais antigos disponíveis) da coleta de dados nem no final. Ao visualizar agregações de um dia (Intervalo=1440), isso significa que os primeiros e os mais recentes dias incompletos não possuem dados. Embora dados brutos possam existir para esses intervalos parciais, eles nunca são resumidos. Você pode determinar o intervalo agregado mais antigo e mais recente para uma granularidade de dados específica puxando o min e o max SummaryDate de uma tabela de resumo específica. A coluna SummaryDate representa o início do intervalo. A coluna Granularity representa a duração do intervalo para os dados agregados.
• Correlação por tempo. As métricas são agregadas na tabela de resumo para intervalos completos, conforme descrito na seção anterior. Elas podem ser usadas para tendências históricas, mas os eventos brutos podem ser mais atuais no estado do que o que foi resumido para análise de tendências. Qualquer comparação baseada em tempo de resumo com dados brutos deve considerar que não há dados de resumo para intervalos parciais que possam ocorrer ou para o início e o fim do período de tempo.
• Eventos perdidos e latentes. As métricas que são agregadas na tabela de resumo podem ser ligeiramente imprecisas se os eventos forem perdidos ou latentes para o período de agregação. Embora o Monitor Service tente manter um estado atual preciso, ele não volta no tempo para recalcular a agregação nas tabelas de resumo para eventos perdidos ou latentes.
• Alta Disponibilidade de Conexão. Durante a alta disponibilidade de conexão, haverá lacunas nas contagens de dados de resumo de conexões atuais, mas as instâncias de sessão ainda estarão em execução nos dados brutos.
• Períodos de retenção de dados. Os dados nas tabelas de resumo são retidos em um cronograma de limpeza diferente do cronograma para dados de eventos brutos. Os dados podem estar ausentes porque foram limpos das tabelas de resumo ou brutas. Os períodos de retenção também podem diferir para diferentes granularidades de dados de resumo. Dados de granularidade mais baixa (minutos) são limpos mais rapidamente do que dados de granularidade mais alta (dias). Se os dados estiverem ausentes de uma granularidade devido à limpeza, eles podem ser encontrados em uma granularidade mais alta. Como as chamadas de API retornam apenas a granularidade específica solicitada, não receber dados para uma granularidade não significa que os dados não existam para uma granularidade mais alta para o mesmo período de tempo.
• Fusos horários. As métricas são armazenadas com carimbos de data/hora UTC. As tabelas de resumo são agregadas em limites de fuso horário por hora. Para fusos horários que não se encaixam em limites de hora, pode haver alguma discrepância quanto à agregação dos dados.

Granularidade e retenção

A granularidade dos dados agregados recuperados pelo Director é uma função do período de tempo (T) solicitado. As regras são as seguintes:

• 0 < T <= 1 hora - usa granularidade por minuto
• 0 < T <= 30 dias - usa granularidade por hora
• T > 31 dias - usa granularidade por dia

Os dados solicitados que não vêm de dados agregados vêm das informações brutas de Sessão e Conexão. Esses dados tendem a crescer rapidamente e, portanto, têm sua própria configuração de limpeza. A limpeza garante que apenas dados relevantes sejam mantidos a longo prazo. A limpeza garante melhor desempenho, mantendo a granularidade necessária para relatórios. Clientes em sites com licença Premium podem alterar a retenção de limpeza para o número desejado de dias de retenção, caso contrário, o padrão é usado. Caso haja perda de conectividade com o banco de dados do Site, o Monitor Service usará os dias de retenção padrão para o direito Premium, conforme especificado na tabela abaixo.

Para acessar as configurações, execute os seguintes comandos PowerShell no Delivery Controller™:

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

Cuidado:

A modificação de valores no banco de dados do Monitor Service requer a reinicialização do serviço para que os novos valores entrem em vigor. Aconselha-se que as alterações no banco de dados do Monitor Service sejam feitas apenas sob a direção do Suporte Citrix.

As configurações GroomProcessUsageRawDataRetentionDays, GroomResourceUsageRawDataRetentionDays e GroomSessionMetricsDataRetentionDays são limitadas aos seus valores padrão de 1, enquanto GroomProcessUsageMinuteDataRetentionDays é limitada ao seu valor padrão de 3. Os comandos PowerShell para definir esses valores foram desabilitados, pois os dados de uso do processo tendem a crescer rapidamente. Além disso, as configurações de retenção baseadas em licença são as seguintes:

• Sites com licença Premium - a retenção de limpeza para todas as configurações é limitada a 1000 dias (a Citrix recomenda 365 dias).
• Sites com licença Advanced - a retenção de limpeza para todas as configurações é limitada a 31 dias.
• Todos os outros sites - a retenção de limpeza para todas as configurações é limitada a 7 dias.

Exceções:

• GroomApplicationInstanceRetentionDays pode ser definido apenas em sites com licença Premium.
• GroomApplicationErrorsRetentionDays e GroomApplicationFaultsRetentionDays são limitados a 31 dias em sites com licença Premium.

A retenção de dados por longos períodos tem as seguintes implicações nos tamanhos das tabelas:

• Dados por hora. Se os dados por hora puderem permanecer no banco de dados por até dois anos, um site de 1000 grupos de entrega pode fazer com que o banco de dados cresça da seguinte forma:

  1000 grupos de entrega x 24 horas/dia x 365 dias/ano x 2 anos = 17.520.000 linhas de dados. O impacto no desempenho de uma quantidade tão grande de dados nas tabelas de agregação é significativo. Dado que os dados do painel são extraídos desta tabela, os requisitos no servidor de banco de dados podem ser grandes. Quantidades excessivamente grandes de dados podem ter um impacto dramático no desempenho.

• Dados de sessão e evento. Dados coletados toda vez que uma sessão é iniciada e uma conexão/reconexão é feita. Para um site grande (100 mil usuários), esses dados crescem rapidamente. Por exemplo, dois anos de dados dessas tabelas acumulariam mais de 1 TB de dados, exigindo um banco de dados de nível empresarial de alta performance.