Gleam.br Wiki

GBR: ADR-0013 Orquestração de Tempo Distribuída (Chronos & Micro-Chronos) | Wiki

Documentação de engenharia e especificações técnicas da Gleam-BR.

GBR: ADR-0013 Orquestração de Tempo Distribuída (Chronos & Micro-Chronos)

*Status:* Aceito *Data:* 2026-05-01

*Contexto:*

Os agentes legados utilizavam ciclos de processamento imperativos (while(true)) ou cronjobs do S.O. para agendar coletas, o que gera alto consumo de CPU (Polling) e descentraliza as regras de negócio, violando o princípio de que "A Nuvem é a Fonte da Verdade".

*Decisão:*

  1. *Chronos (Nuvem - Control Plane):* Implementação de um orquestrador central no Gateway utilizando temporizadores nativos da máquina virtual Erlang (process.send_after). A complexidade computacional cai para O(1). Para sobreviver a reinicializações do servidor, o Chronos é reidratado obrigatoriamente através da injeção de dependência do Mnesia (ChronosStorage) na inicialização, restaurando todos os temporizadores.
  2. *Micro-Chronos (Borda - Data Plane):* O Agente Edge (falconctl) possui um Ator Autônomo que não avalia regras, mas executa um "Manifesto" (JSON) compilado e enviado pelo Gateway durante o Handshake P2P inicial. O Agente utiliza send_after localmente.
  3. *Hot-Reload:* Quando a Nuvem altera o manifesto, o novo JSON é injetado via Yamux, o Agente executa process.cancel_timer em todas as rotinas antigas, limpa a memória e instala as novas regras dinamicamente.

*Consequências:*

  • *Positivas:* Tolerância absoluta a quedas de backbone. Se o túnel P2P for cortado, o Micro-Chronos continua executando o seu Manifesto e acumulando métricas no armazenamento de borda local (gbr_disk_log), eliminando buracos ("gaps") nos gráficos de monitoramento após a reconexão.
  • *Negativas/Riscos:* Exige sincronização estrita de fusos horários (Timezones). A infraestrutura foi mandatada a operar exclusivamente em *UTC (Unix Epoch em nanossegundos)* no backend, transferindo qualquer cálculo de localização de fuso horário para a camada de visualização do cliente final.

A Abordagem Arquitetural (Em Níveis)

  • *O Ótimo Teórico:* Uma arquitetura Semantic-First, onde todos os nós (Gateway e Borda) operam de forma isolada sobre Grafos de Conhecimento, utilizando comunicação descentralizada DHT para troca de estados e consensos validados via Merkle Trees, erradicando a necessidade de um Data Plane central para sincronização temporal.
  • *O Caminho Pragmático (Executado):* O modelo Híbrido atual, que reconhece o legado da indústria (Bancos de dados relacionais/XMLs). Centralizamos a avaliação BPE e a Semântica na Nuvem (preservando o poder computacional isolado), enquanto delegamos aos agentes apenas o Micro-Chronos burro, capaz de operar Offline-First com armazenamento Ring-Buffer em disco para assegurar a persistência absoluta de dados durante partições de rede TCP.