Monitor de Cutover · conectando…

A jornada de cada posição de GPS

--:--
flush
PASSO A PASSO

O caminho completo, do veículo ao histórico

Cada caixa é uma parada. A bolinha verde mostra os dados se movendo. O tempo embaixo de cada seta é quanto a posição demora pra atravessar.

🛰️
Veículo
a antena GPS
O rastreador no carro envia sua posição pela rede móvel (protocolo GT06).
posições recebidas / min
☁️
Cloud
grade de proteção · pago
Rede de segurança em paralelo. O Novo virou produção; o Cloud segue rodando como reserva caso precise voltar.
veículos · memória
reserva
🔀
Transit
PRODUÇÃO · grava no bucket
É a esteira de produção: recebe o tempo real (8 faixas) e distribui pros três destinos do Novo. O dump diário do dia vai pro bucket de produção.
entradas / s · memória
🐉
3 destinos
rt · alert · hot
Cada um guarda as posições pra um uso: tempo real, alertas e histórico recente. Detalhes abaixo ↓
veículos cobertos em cada
1×/dia
🗄️
GCP
o histórico final
Uma vez por dia, o dia fechado é arquivado na nuvem do Google e a memória é liberada.
dispositivos arquivados ontem
verde = saudável amarelo = atrasando vermelho = travado 🔵 a bolinha = um dado em trânsito
QUÃO RÁPIDO CHEGA

Latência ponta a ponta · da antena até o destino

A cada 30s um pacote de teste é disparado por região e cronometrado nos dois sistemas — tempo total do envio até aparecer. "chega %" = quantos testes completaram o caminho.

Cloud (reserva) rt (produção do Novo) A reserva pode ficar alguns ms diferente — o esperado. Vermelho no "chega %" = posições não estão chegando.
DENTRO DO PASSO 4

Os três destinos (produção), conferidos com a reserva Cloud

Bate com a reserva (paridade) = % da base cuja posição no Novo (produção) confere com o Cloud (reserva) — conferência de retaguarda; quanto mais perto de 100%, mais alinhadas as duas camadas. Abaixo, veículos em movimento defasados (atrasados +60s): o que dispara o alerta — atenção a partir de 5%, crítico a partir de 15%. Carro parado e quem está adiantado não contam como defasado.

PASSO 5 · EM DETALHE

O envio diário pro histórico (flush)

Uma vez por dia o "dia fechado" é empacotado e mandado pro GCP, liberando memória.

Flush de produção — o histórico que vai pros clientes
✅ NOSSO transit → bucket de PRODUÇÃO
tracker-net-updates
🛡️ Cloud → guarda temporário
aposentado
desligado no cutover de 21/jun (era dump dobrado) — normal estar parado
  Próximo envio —
Quando rodar, manda o dia fechado e libera a memória do hot.
represados (D-2+)
com erro
✅ Conferência de ontem
📦 Arquivado ontem
dispositivos · 1:1 com o Cloud
⏳ Na fila pra enviar
de ontem · vai no próximo flush
🗑️ Lixo podado (pré-flush)
limpeza antes do GCP
TAMANHO DO TRANSIT

Memória do transit ao longo do tempo

O transit enche durante o dia com o tempo real e esvazia no dump pro bucket. A linha mostra o uso real; picos perto do limite = risco de travar a esteira de produção.

🔀 transit · memória
mínimo (pós-flush)
pico
limite
HISTÓRICO SALVO NO GCP

Cada dia, salvo ou não

Cada quadrinho é um dia. Verde ✓ = salvo no GCP (guardado, com a contagem de veículos). ⏳ a fechar = hoje e ontem — ainda não foram pro GCP (o dump de um dia sobe só ~2 dias depois; é normal). Cinza = sem volume. É o que garante que a frota nunca fica sem histórico.

🛡️
O Cloud nunca é tocado — tudo aqui é só leitura. A produção já roda 100% pelo Novo; o Cloud segue em paralelo como grade de proteção (reserva), pronto caso seja preciso voltar.