Transparência das métricas da plataforma

Inventário de métricas

Métricas de ciclo de sessão Sem dados pessoais

Contamos totais de login/logout e faixas de duração de sessão para entender padrões de uso. Não rastreamos quem entrou.

O quê: eventos diários de login, logout e distribuições de duração.

Por quê: detectar problemas de autenticação, reduzir atrito e melhorar planejamento de capacidade.

Como: contadores diários e buckets fixos.

Retenção: 30 dias raw -> 52 semanas rollup -> 24 meses mensal -> purga.

Buckets:

• 0-5min - verificações rápidas
• 5-30min - sessão típica
• 30-60min - sessão estendida
• 60min+ - sessão longa de trabalho

Chaves de exemplo:

telemetry:auth:login:2026-03-09      -> 247
telemetry:auth:logout:2026-03-09     -> 219
telemetry:session:duration:0-5min    -> 45
telemetry:session:duration:5-30min   -> 128
telemetry:session:duration:30-60min  -> 39
telemetry:session:duration:60min+    -> 7

Privacy Guard: o hash de sessão é destruído logo após o cálculo de duração. Nenhum UUID de usuário é armazenado em chaves de telemetria.

Limite de volume: máximo 734 chaves/ano.

Métricas de saúde Redis Sem dados pessoais

Monitoramos Redis como dados de saúde de infraestrutura, não como atividade do usuário.

O quê: uso de memória, contagem de chaves por namespace e estatísticas de conexão.

Por quê: detectar vazamentos de memória, prevenir evictions e acompanhar crescimento.

Como: parse da saída Redis INFO em intervalo programado.

Retenção: 24 horas raw -> 7 dias por hora -> 4 semanas diário -> purga.

Namespaces: máximo 10 namespaces rastreados (allowlist fixa).

• session:* - Active sessions
• lock:* - Distributed locks
• cache:* - Application cache
• telemetry:* - Metrics storage
• ratelimit:* - Rate limiting counters
• nonce:* - CSRF tokens
• temp:* - Temporary data
• queue:* - Job queues
• encryption:* - Wrapped keys
• feature:* - Feature flags

Chaves de exemplo:

telemetry:redis:memory:used_mb:2026-03-09:14  -> 247
telemetry:redis:keys:session:2026-03-09:14    -> 342
telemetry:redis:keys:lock:2026-03-09:14       -> 18

Privacy Guard: contagens por namespace são apenas agregadas. Conteúdo de chaves não é inspecionado.

Limite de volume: máximo 1.680 chaves na janela ativa.

Métricas agregadas de negócio Sem dados pessoais

São totais de plataforma usados para planejamento, não para perfilar indivíduos.

O quê: usuários totais, contas ativas, média de work entries.

Por quê: planejamento de capacidade e análise de crescimento.

Como: agregação diária de contagens do banco.

Retenção: 30 dias diário -> 52 semanas semanal -> 24 meses mensal -> purga.

Chaves de exemplo:

telemetry:business:users:total:2026-03-09     -> 1247
telemetry:business:users:active:2026-03-09    -> 892
telemetry:business:work:avg_per_user:2026-03  -> 23.4

Privacy Guard: apenas valores agregados. Sem registros de telemetria por usuário.

Limite de volume: 1.095 chaves/ano.

Eventos de telemetria frontend Sem dados pessoais

Telemetria de eventos ajuda a detectar falhas client-side e problemas de confiabilidade de features.

O quê: eventos de performance frontend, contagens de erro e eventos de uso de feature.

Por quê: identificar problemas de cliente e monitorar saúde do produto.

Como: POST para /api/telemetry/record apenas para tipos aprovados.

Retenção: 30 dias (TTL aplicado no incremento).

Limites de envio e tipos de evento de exemplo:

• 90 events/minute per client (abuse prevention)
• calendar.load.success
• calendar.load.failure
• encryption.dek.unwrap.success
• encryption.dek.unwrap.failure
• passkey.login.success
• passkey.login.failure

Chaves de exemplo:

telemetry:event:calendar.load.success:2026-03-09    -> 3421
telemetry:event:passkey.login.failure:2026-03-09    -> 17

Privacy Guard: tipos de evento são allowlisted. Sem strings arbitrárias ou identificadores usuário/sessão em chaves.

Limite de volume: máximo 18.250 chaves/ano.

Métricas de operações de criptografia Sem dados pessoais

Operações criptográficas são monitoradas como sinais de confiabilidade da plataforma.

O quê: contadores de sucesso e falha DEK wrap/unwrap.

Por quê: detectar rapidamente falhas criptográficas e configuração incorreta.

Como: contadores sucesso/falha incrementam para cada resultado.

Retenção: 30 dias raw -> 52 semanas rollup -> 24 meses mensal -> purga.

Chaves de exemplo:

telemetry:encryption:dek:wrap:success:2026-03-09      -> 1203
telemetry:encryption:dek:wrap:failure:2026-03-09      -> 2
telemetry:encryption:dek:unwrap:success:2026-03-09    -> 5847
telemetry:encryption:dek:unwrap:failure:2026-03-09    -> 31

Privacy Guard: somente contagens de operação são registradas. Sem material de chave, ciphertext ou identificadores pessoais.

Limite de volume: 1.460 chaves/ano.

Pipeline de retenção e compactação

Dados raw: contadores diários expiram automaticamente após 30 dias.

Rollups semanais: agregação programada para retenção de 52 semanas.

Rollups mensais: agregação programada para retenção de 24 meses.

Purga: métricas com mais de 24 meses são excluídas.

Script de compactação: /scripts/compact-metrics.php.