Granularidade e retenção de dados

Agregação de valores de dados

O Serviço de Monitoramento coleta vários dados, incluindo uso da sessão do usuário, detalhes de desempenho de logon do usuário, detalhes de balanceamento de carga da sessão e informações de conexão e falha da máquina. Os dados são agregados de forma diferente dependendo de sua categoria. Entender 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 ao longo de um período. Portanto, eles são expostos ao máximo ao longo de um período de tempo.
• A duração do LogOn é uma medida de tempo, portanto é exposta como uma média ao longo de um período de tempo.
• Contagens de logon e falhas de conexão são contagens de ocorrências ao longo de um período e, portanto, são expostas como somas ao longo de um período de tempo.

Avaliação simultânea de dados

As sessões devem ser sobrepostas para serem consideradas simultâneas. Entretanto, quando o intervalo de tempo é de 1 minuto, todas as sessões naquele minuto (independentemente de se sobreporem) 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 compensa o valor agregado. Se as sessões ocorrerem na mesma hora, mas não no mesmo minuto, elas não serã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 por minuto, hora e dia.
• Os dados brutos representam eventos individuais ou estado atual rastreados 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:

• Nenhum dado 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 resumidos 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 o primeiro e o mais recente dia incompleto não têm dados. Embora possam existir dados brutos para esses intervalos parciais, eles nunca são resumidos. Você pode determinar o intervalo de agregação 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 Granularidade representa o comprimento do intervalo para os dados agregados.
• Correlacionando pelo tempo. As métricas são agregadas na tabela de resumo para intervalos completos, conforme descrito na seção anterior. Eles podem ser usados para tendências históricas, mas eventos brutos podem ser mais atuais no estado do que o que foi resumido para análise de tendências. Qualquer comparação baseada no tempo entre dados resumidos e brutos deve considerar que não há dados resumidos 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 agregadas na tabela de resumo podem ser um pouco imprecisas se os eventos forem perdidos ou latentes no período de agregação. Embora o Serviço de Monitoramento 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.
• Conexão de alta disponibilidade. Durante a alta disponibilidade da conexão, haverá lacunas nas contagens de dados resumidos das conexões atuais, mas as instâncias da 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 mantidos em um cronograma de preparação diferente do cronograma para dados de eventos brutos. Os dados podem estar faltando porque foram extraídos de tabelas resumidas ou brutas. Os períodos de retenção também podem ser diferentes para diferentes granularidades de dados resumidos. Dados de granularidade mais baixa (minutos) são preparados mais rapidamente do que dados de granularidade mais alta (dias). Se houver dados faltando em uma granularidade devido à preparação, eles poderão 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 no mesmo período.
• Fusos horários. As métricas são armazenadas com registros de data e hora UTC. As tabelas de resumo são agregadas com base nos limites de fuso horário. Para fusos horários que não se enquadram em limites horários, pode haver alguma discrepância quanto ao local onde 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 preparação. A preparação garante que apenas dados relevantes sejam mantidos a longo prazo. A preparação garante melhor desempenho, mantendo a granularidade necessária para relatórios. Clientes em sites com licença Premium podem alterar a retenção de cuidados pessoais para o número desejado de dias de retenção; caso contrário, o padrão será usado. Em caso de 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 do PowerShell no Delivery Controller:

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

Cuidado:

Modificar valores no banco de dados do Monitor Service requer a reinicialização do serviço para que os novos valores entrem em vigor. É aconselhável fazer alterações no banco de dados do Monitor Service somente sob a orientação do Suporte da Citrix.

As configurações 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 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 preparação para todas as configurações é limitada a 1000 dias (a Citrix recomenda 365 dias).
• Sites com licença avançada - a retenção de preparação para todas as configurações é limitada a 31 dias.
• Todos os outros sites - a retenção de preparação para todas as configurações é limitada a 7 dias.

Exceções:

• GroomApplicationInstanceRetentionDays pode ser definido somente 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 horários. Se os dados horários permanecerem no banco de dados por até dois anos, um site com 1.000 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. Considerando 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 drástico no desempenho.

• Dados de sessão e evento. Dados coletados sempre 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 dessas tabelas reuniriam mais de 1 TB de dados, exigindo um banco de dados de nível empresarial de ponta.