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 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 ao longo de um período de tempo.
• A Duração do Logon é uma medida da duração do tempo, portanto, é exposta como uma média ao longo de um período de tempo.
• A Contagem de Logons e as Falhas de Conexão são contagens de ocorrências durante um período, portanto, são expostas como somas ao longo de um período de tempo.

Avaliação de dados concorrentes

As sessões devem ser sobrepostas 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 agregado. 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 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:

• Nenhum dado de resumo para intervalos parciais. Os resumos de métricas são projetados para atender às necessidades de tendências históricas ao longo de 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 estar mais atualizados no estado do que o que foi resumido para análise de tendências. Qualquer comparação baseada em tempo de dados 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 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 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.
• Alta disponibilidade de conexão. Durante a alta disponibilidade de conexão, haverá lacunas nas contagens de dados de resumo das conexões atuais, mas as instâncias de sessão ainda estarão sendo executadas 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 poderão 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 enquadram nos limites por hora, 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 provê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 Serviço de Monitoramento 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 Serviço de Monitoramento 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 Serviço de Monitoramento somente 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.

Reter dados por longos períodos tem as seguintes implicações no tamanho das tabelas:

• Dados por hora. Se os dados por hora puderem permanecer no banco de dados por até dois anos, um site com 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 para o 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, o valor de dois anos dessas tabelas reuniria mais de um TB de dados, exigindo um banco de dados de nível empresarial de ponta.