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 do desempenho de logon do usuário, detalhes do balanceamento de carga da sessão e informações de falha de máquina e conexão. Os dados são agregados de forma diferente, dependendo de sua categoria. Compreender a agregação de valores dos dados apresentados usando as APIs do método OData é fundamental para interpretar os dados. Por exemplo:

• Connected Sessions e Machine Failures ocorrem ao longo de um período. Portanto, são exibidas como máximos ao longo de um período de tempo.
• Duração do logon é uma medida de tempo, portanto, é exposta como uma média ao longo de um período de tempo.
• Contagem de logon e falhas de conexão são contagens de ocorrências ao longo de um período, portanto, são expostas como somas ao longo de um período de tempo.

Avaliação simultânea de dados

As sessões devem estar sobrepostas para serem consideradas simultâneas. No entanto, quando o intervalo de tempo é 1 minuto, todas as sessões nesse minuto (caso se sobreponham) são consideradas simultâneas. O tamanho do intervalo é tão pequeno que a sobrecarga de desempenho envolvida no cálculo da precisão não vale o valor adicionado. Se as sessões ocorrerem 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 as métricas de duas maneiras diferentes:

• As tabelas de resumo representam exibições agregadas das métricas granulares 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:

• Não há dados resumidos para intervalos parciais. Os resumos de métricas são projetados para atender às necessidades das tendências históricas por longos períodos de tempo. Essas métricas são agregadas na tabela de resumo para intervalos completos. Não há dados resumidos para um intervalo parcial no início (dados disponíveis mais antigos) da coleta de dados nem no final. Ao visualizar agregações de um dia (Intervalo=1440), isso significa que o primeiro dia e os dias incompletos mais recentes não têm dados. Embora possam existir dados brutos 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, extraindo o SummaryDate mínimo e máximo de uma tabela de resumo específica. A coluna SummaryDate representa o início do intervalo. A coluna Granularity representa o comprimento 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 eventos brutos podem ser mais atuais no estado do que o que foi resumido para a análise de tendências. Qualquer comparação baseada em tempo entre dados de resumo e 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. Métricas que são agregadas na tabela de resumo podem ser um pouco imprecisas se houver eventos perdidos ou latentes no 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 dos eventos perdidos ou latentes.
• Alta disponibilidade de conexão. Durante a alta disponibilidade de conexão, haverá lacunas nas contagens de dados resumidas das conexões atuais, mas as instâncias da sessão continuarão em execução nos dados brutos.
• Períodos de retenção de dados. Os dados nas tabelas de resumo são retidos em uma programação de limpeza diferente da programação para dados brutos do evento. Os dados podem estar ausentes porque foram eliminados das tabelas de resumo ou de dados brutos. 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 eliminados mais rapidamente do que os dados de granularidade mais alta (dias). Se os dados estiverem ausentes de uma granularidade devido à limpeza, eles podem ser encontrados em uma granularidade maior. 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 maior para o mesmo período de tempo.
• Fusos horários. As métricas são armazenadas com carimbos de hora UTC. As tabelas de resumo são agregadas em limites de fuso horário por hora. Para fusos horários que não caem em limites por hora, pode haver alguma discrepância quanto ao local em que os dados são agregados.

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 somente dados relevantes sejam mantidos a longo prazo. A limpeza garante melhor desempenho, mantendo a granularidade necessária para a emissão de relatórios. Os clientes em sites licenciados 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.

Para acessar as configurações, execute os seguintes comandos do 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. Recomendamos que você faça alterações no banco de dados do Monitor Service somente sob a direção do Suporte Citrix.

As configurações de GroomProcessUsageRawDataRetentionDays, GroomResourceUsageRawDataRetentionDays e GroomSessionMetricsDataRetentionDays são limitadas aos seus valores padrão de 1, enquanto GroomProcessUsageMinuteDataRetentionDays é limitado ao seu valor padrão de 3. Os comandos do PowerShell para definir esses valores foram desativados, 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 licenciados Premium – a retenção de limpeza para todas as configurações é limitada a 1000 dias (a Citrix recomenda 365 dias).
• Sites licenciados 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 só pode ser definido em sites licenciados Premium.
• GroomApplicationErrorsRetentionDays e GroomApplicationFaultsRetentionDays são limitados a 31 dias em sites licenciados 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. Como os dados do painel são extraídos dessa tabela, os requisitos no servidor de banco de dados podem ser grandes. Quantidades excessivamente grandes de dados podem ter um impacto drástico no desempenho.

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