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.
  • Logon Duration é uma medida de tempo, portanto, é exibida como uma média ao longo de um período de tempo.
  • Logon Count e Connection Failures são contagens de ocorrências ao longo de um período, portanto, são exibidas como somas ao longo de um período de tempo.

Avaliação simultânea de dados

Suas sessões devem se sobrepor 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 de tendências históricas por longos períodos. 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 (Interval=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. Extraia o SummaryDate mínimo e máximo de uma tabela de resumo específica para determinar o intervalo agregado mais antigo e mais recente para uma granularidade de dados 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 levar em consideração 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 HA de conexão, ocorrem lacunas nas contagens de dados resumidas das conexões atuais, mas as instâncias da sessão continuam 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 Monitor é uma função do período de tempo (T) solicitado. As regras são as seguintes:

  • 0 < T <= 30 dias de uso, granularidade por hora
  • T > 31 dias de uso, 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. Isso garante melhor desempenho, mantendo a granularidade necessária para a emissão de relatórios.

Nome do parâmetro Limpeza afetada Dias de retenção para Premium Dias de retenção para Advanced
  1 GroomSessionsRetentionDays Retenção de registros de sessão e conexão após o encerramento da sessão 90 31
  2 GroomFailuresRetentionDays Registros de MachineFailureLog e ConnectionFailureLog 90 31
  3 GroomLoadIndexesRetentionDays Registros LoadIndex 90 31
  4 GroomDeletedRetentionDays Entidades de máquina, catálogo, grupo de áreas de trabalho e Hypervisor que têm LifecycleState como “‘Deleted”. Isso também exclui todos os registros relacionados a Session, SessionDetail, Summary, Failure ou LoadIndex. 90 31
  5 GroomSummariesRetentionDays Registros DesktopGroupSummary, FailureLogSummary e LoadIndexSummary. Dados agregados - granularidade diária. 365 31
  6 GroomMachineHotfixLogRetentionDays Hotfixes aplicados às máquinas VDA e Controller 90 31
  7 GroomHourlyRetentionDays Dados agregados - granularidade por hora 32 31
  8 GroomApplicationInstanceRetentionDays Histórico da instância do aplicativo 90 Não aplicável
  9 GroomNotificationLogRetentionDays Registros de log de notificação 90 Não aplicável
  10 GroomResourceUsageRawDataRetentionDays Dados de utilização do recurso - dados brutos 3 3
  11 GroomResourceUsageHourDataRetentionDays Dados de resumo de utilização do recurso - granularidade por hora 30 30
  12 GroomResourceUsageDayDataRetentionDays Dados de resumo de utilização do recurso - granularidade por dia 365 31
  13 GroomProcessUsageRawDataRetentionDays Dados de utilização do processo - dados brutos 1 1
  14 GroomProcessUsageHourDataRetentionDays Dados de utilização do processo - granularidade por hora 7 7
  15 GroomProcessUsageDayDataRetentionDays Dados de utilização do processo - granularidade por dia 30 30
  16 GroomSessionMetricsDataRetentionDays Dados de métricas de sessão 1 1
  17 GroomMachineMetricDataRetentionDays Dados de métricas de máquina 3 3
  18 GroomMachineMetricDaySummaryDataRetentionDays Dados de resumo de métricas de máquina 365 31
  19 GroomApplicationErrorsRetentionDays Dados de erro do aplicativo 1 1
  20 GroomApplicationFaultsRetentionDays Dados de falha do aplicativo 1 1

Cuidado:

Você não pode modificar os valores no banco de dados do Monitor Service.

A retenção de 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 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. Estes são os 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.

Granularidade e retenção de dados