Polling e Dispatcher Service
Poller coleta métricas e atualiza banco/RRD. O objetivo operacional é terminar toda a carga dentro do intervalo.
Ponto técnico 1
Poller: Poller coleta métricas e atualiza banco/RRD. O objetivo operacional é terminar toda a carga dentro do intervalo.
Ponto técnico 2
Discovery: Discovery roda com frequência menor e detecta mudanças de inventário; não confunda atraso de discovery com falha de polling.
Ponto técnico 3
Dispatcher Service: librenms-service.py agenda Poller, Discovery, Services, Alerting, Billing, Fast Ping e manutenção diária sem substituir os scripts PHP que executam as tarefas.
Ponto técnico 4
Migração de cron: Ao usar Dispatcher para uma tarefa, evite executá-la simultaneamente pelo cron. A documentação alerta para remover o cron antigo quando apropriado para evitar polling duplicado.
Ponto técnico 5
Workers: Consumed Worker Seconds deve permanecer abaixo de Maximum Worker Seconds. Devices Pending indica insuficiência ou distribuição ruim.
Ponto técnico 6
Fast Ping: É scheduler separado e desabilitado por padrão. Habilite somente se houver objetivo operacional.
Ponto técnico 7
Systemd watchdog: Há unidade alternativa com WatchdogSec para reiniciar Dispatcher travado; ela exige suporte python-systemd.
Ponto técnico 8
Diagnóstico: systemctl status librenms → logs → validate.php → Poller UI → workers/pendências → dispositivo lento.
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.
Comandos / fluxo de referência
systemctl status librenms --no-pager
journalctl -u librenms -n 200 --no-pager
cd /opt/librenms && ./validate.phpRotina 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.