Case principalProduçãoOnline

RMM-OFFLINE

Monitoramento remoto de máquinas com operação offline-first

Sistema de RMM que coleta métricas de hardware em máquinas Windows, detecta anomalias e disponibiliza dashboards e relatórios em uma interface web, com armazenamento local em JSON e suporte opcional a MongoDB.

Falar comigo

Node.jsExpressMongoDBMongooseReact NativeExpoTypeScriptDockerOpenHardwareMonitor

Visão geral

O RMM-OFFLINE é uma solução de monitoramento remoto pensada para redes locais e ambientes com conectividade limitada. Ele coleta periodicamente métricas de CPU, memória RAM, GPU, disco e uptime de cada máquina monitorada, grava esses dados em arquivos JSON organizados por mês e mantém um histórico de ocorrências para consulta posterior. A coleta é feita por um agente em Node.js que se integra ao OpenHardwareMonitor para ler sensores de hardware no Windows. Esse agente aplica limites de anomalia configuráveis, registra novas ocorrências e pode operar de forma totalmente local ou enviar os dados para uma API REST quando configurado para isso. A API em Express expõe endpoints para listar máquinas, consultar dados por período, buscar logs de ocorrências e, opcionalmente, persistir tudo no MongoDB. O frontend em React Native com Expo consome esses endpoints e oferece uma interface web com cards de monitoramento em tempo real, gráficos históricos, filtros por máquina e data, além de geração de relatórios mensais em PDF. O projeto foi estruturado para rodar tanto de forma manual quanto via Docker Compose, com serviços separados para API e frontend, e um agente de monitoramento que pode ser agendado no Windows Task Scheduler ou em cron no Linux.

A dor

Redes locais e ambientes industriais frequentemente não têm acesso à internet ou não podem depender de serviços em nuvem para monitorar a saúde das máquinas. Ferramentas tradicionais de RMM exigem conectividade constante e não oferecem armazenamento local simples de consultar.

A solução

Um sistema de monitoramento que funciona offline, com coleta local de métricas de hardware, armazenamento em arquivos JSON por mês e uma interface web que consome uma API REST local. O uso do MongoDB é opcional, permitindo escalar para volumes maiores sem alterar o fluxo principal.

Abordagem de engenharia

Modelagem dos dados de monitoramento

Estruturação dos registros em JSON com timestamp, alias da máquina e métricas detalhadas de CPU, RAM, GPU e disco, organizados por mês para facilitar consultas e relatórios.

Agente de coleta e detecção de anomalias

Implementação de um agente em Node.js que lê sensores via OpenHardwareMonitor, aplica limites configuráveis e registra ocorrências em arquivos separados, com suporte a exceções por máquina.

API REST com armazenamento flexível

Construção de uma API em Express que expõe endpoints para consulta de dados e logs, com camada de serviço para MongoDB opcional e rotas preparadas para ambos os modos de armazenamento.

Interface web com dashboards e relatórios

Desenvolvimento de um frontend em React Native com Expo, organizado em abas para visão geral, monitoramento em tempo real, logs e relatórios mensais, com gráficos e filtros por período.

Empacotamento e operação

Configuração de Dockerfiles e Docker Compose para API e frontend, além de instruções para agendamento do agente no Windows e Linux, garantindo operação contínua em ambientes locais.

O que o projeto entrega

Coleta local de métricas de hardware sem dependência de nuvem
Armazenamento em arquivos JSON por mês com opção de MongoDB
Detecção de anomalias com limites configuráveis e exceções por máquina
Interface web com gráficos, filtros e geração de relatórios em PDF

Arquitetura e desafios técnicos

RMM-OFFLINE: arquitetura offline-first em camadas

Agente Node.js coleta sensores via OpenHardwareMonitor, grava JSON mensal e/ou envia para API Express; frontend Expo consome REST e gera dashboards e PDFs; MongoDB é opcional.

Renderizando diagrama...

Desafios técnicos

Armazenamento local em JSON em vez de banco embutido

Contexto

Ambientes isolados sem internet e com baixa tolerância a instalação de serviços adicionais precisam de persistência simples e consultável.

Decisão

Adotar arquivos JSON organizados por mês e por máquina como padrão, mantendo MongoDB como opção para volumes maiores sem alterar o frontend.

Trade-off

Consultas agregadas e concorrência de escrita são limitadas em arquivos JSON; mitigado pela organização mensal, pela camada de serviço que abstrai a fonte e pelo caminho opcional para MongoDB quando o volume cresce.

Agente offline-first com envio opcional para a API

Contexto

A coleta precisa continuar funcionando mesmo sem conectividade, mas também deve alimentar a interface web quando a rede está disponível.

Decisão

O agente grava sempre em JSON local e só envia à API quando configurado, mantendo a operação local como caminho principal.

Trade-off

Há duplicidade potencial entre dados locais e dados enviados; mitigado pela estrutura mensal consistente e pela camada de serviço da API que lê a mesma organização de arquivos.

Detecção de anomalias no agente, não no servidor

Contexto

A avaliação de limites precisa ocorrer mesmo quando a API não está acessível, e por máquina com exceções específicas.

Decisão

Aplicar regras de anomalia no próprio agente Node.js, com limites configuráveis e exceções por máquina, registrando ocorrências em arquivo separado.

Trade-off

A lógica fica distribuída em cada agente, dificultando mudanças centralizadas; mitigado pela configuração por máquina e pelo registro padronizado de ocorrências consultável pela API.

Frontend React Native com Expo para web e mobile

Contexto

Era necessário entregar dashboards, gráficos e relatórios com uma base de código única e componentes reutilizáveis.

Decisão

Usar React Native com Expo e Axios para consumir a API REST, organizando a interface em abas de dashboard, monitoramento, logs e relatórios.

Trade-off

A experiência web não é tão otimizada quanto uma aplicação web dedicada; mitigado pelo uso de componentes reutilizáveis, gráficos interativos e foco nas necessidades operacionais de monitoramento.

Operação via Docker Compose com agente agendado externamente

Contexto

O sistema precisa rodar em redes locais com pouca padronização de infraestrutura e sem dependência de nuvem.

Decisão

Empacotar API e frontend em Dockerfiles e Docker Compose, deixando o agente sob responsabilidade do agendador do sistema (Task Scheduler ou cron).

Trade-off

O agente não é orquestrado pelo Compose, exigindo configuração manual de agendamento; mitigado por instruções claras para Windows e Linux e pela separação de responsabilidades entre coleta e serviços.

Resultados

Sistema funcional sem conexão com internet, com armazenamento local em arquivos JSON.

Operação offline

Coleta de CPU, RAM, GPU, disco e uptime, com detecção de anomalias configurável.

Cobertura de métricas

Dashboard web com gráficos, filtros e geração de relatórios mensais em PDF.

Interface unificada

Alternância entre arquivos JSON e MongoDB sem alteração no frontend.

Flexibilidade de armazenamento

Stack

Node.jsExpressMongoDBMongooseReact NativeExpoTypeScriptDockerOpenHardwareMonitor

Temas

#RMM#monitoramento#offline-first#Node.js#React Native#Expo#MongoDB#Docker

Vamos conversar sobre a próxima oportunidade.

Infraestrutura, IA aplicada, mobile/edge ou integrações críticas — se o desafio exige profundidade, me conte o contexto.

Enviar e-mail Ver outros projetos