Arquitetura
WebUI/API em PHP/Laravel, MariaDB/MySQL, RRD/RRDCached, Poller, Discovery, Alerting e Scheduler/Dispatcher formam o núcleo. Redis entra em cenários distribuídos para coordenação, cache, filas e sessões.
Ponto técnico 1
Componentes centrais: WebUI/API em PHP/Laravel, MariaDB/MySQL, RRD/RRDCached, Poller, Discovery, Alerting e Scheduler/Dispatcher formam o núcleo. Redis entra em cenários distribuídos para coordenação, cache, filas e sessões.
Ponto técnico 2
Fluxo de dados: Dispositivo → ICMP/SNMP → Poller → banco + RRD → Alert Rule → Operation/Transport → NOC. Discovery executa em cadência mais longa e atualiza inventário de portas, sensores, módulos e relacionamentos.
Ponto técnico 3
Banco relacional: O banco armazena dispositivos, portas, inventário, regras, usuários, alertas e metadados. Ele não deve ser tratado como simples cache descartável.
Ponto técnico 4
RRD e RRDCached: RRD guarda séries de desempenho. RRDCached desacopla escrita em disco, reduz I/O e é requisito prático para distributed polling.
Ponto técnico 5
Scheduler: Instalações modernas podem usar systemd scheduler e Dispatcher Service. Dispatcher agenda poller, discovery, services, alerting, billing, fast ping e manutenção diária.
Ponto técnico 6
Domínios de falha: WebUI, banco, RRD, Redis, pollers e rede SNMP podem falhar independentemente. Um painel vazio não prova que o polling parou; um poller saudável não prova que alerting está entregando.
Ponto técnico 7
Escala: Comece com uma instalação estável. Depois RRDCached, Dispatcher, tuning, separação de banco/WebUI, Redis e pollers adicionais. Escalar antes de medir cria complexidade sem benefício.
Procedimento de engenharia
Escopo e impacto
Defina serviço, owner, estado esperado e impacto antes de alterar o monitoramento.
Evidência primeiro
Valide fonte, caminho, credenciais, baseline e timestamps antes de alterar thresholds.
Mudança controlada
Altere uma variável por vez e mantenha um caminho de rollback.
Rotina operacional recomendada
- Revise estados críticos, lacunas de coleta e falhas de entrega a cada turno.
- Revise alertas ruidosos, objetos lentos, credenciais e erros recorrentes semanalmente.
- Revise versões, backup/restore, permissões e capacidade periodicamente.
Sintoma → escopo → camada → evidência → hipótese → validação
Construa, quebre, diagnostique e recupere
- Registre um baseline saudável.
- Induza uma falha controlada relacionada ao tema.
- Identifique a camada com falha antes de reiniciar componentes.
- Corrija a causa identificada e valide a recuperação.
Pronto para produção?
Responsabilidade
Objetivo, escopo e owner estão definidos.
Segurança
Credenciais e integrações seguem menor privilégio.
Validação
Falha e recuperação foram testadas e documentadas.
Documentação sensível à versão
LibreNMS é rolling release. O conteúdo foi confrontado com a documentação oficial atual; instalação, Dispatcher, API, distributed polling, RRDCached, Redis, HA e requisitos devem ser reconfirmados antes de change.