Troubleshooting
Sintoma → escopo → horário → camada → evidência → hipótese → teste → causa raiz → correção → validação. Não reinicie antes de capturar logs/estado quando possível.
Ponto técnico 1
Método: Sintoma → escopo → horário → camada → evidência → hipótese → teste → causa raiz → correção → validação. Não reinicie antes de capturar logs/estado quando possível.
Ponto técnico 2
Validate: Comece com ./validate.php e também Validate Config na WebUI; os dois caminhos testam itens diferentes.
Ponto técnico 3
Device não descobre: ping/SNMP reachability → credencial/version → snmpwalk → sysObjectID/sysDescr → discovery.php -d → OS/module.
Ponto técnico 4
Device sem polling: poller.php -d → poller UI → worker pending → SNMP latency → DB/RRD write → ownership.
Ponto técnico 5
Graphs vazios: poller atualiza? → RRD existe/ownership → RRDCached → rrdtool fetch → módulo/DS → range.
Ponto técnico 6
Alert não dispara: regra/escopo → entidade atual → alert scheduler → fault → operation → transport → template.
Ponto técnico 7
Notificação não chega: alert ativo → operation step → transport test → SMTP/API/TLS/DNS → destination logs.
Ponto técnico 8
WebUI lenta: browser → NGINX/PHP-FPM → DB → query/IO → recursos; não aumente PHP workers sem medir DB.
Ponto técnico 9
Dispatcher falha: systemctl → service log → settings → cron duplicado → workers → Redis/DB/RRDCached.
Ponto técnico 10
Distributed poller: validate.php -m dist-poller → APP_KEY → NODE_ID → DB → Redis → RRDCached → group.
Ponto técnico 11
RRD corrompido: validate.php -m rrdcheck → storage/errors → backup → repair/recreate somente com entendimento do impacto.
Ponto técnico 12
API falha: v0/v1 correto → token/header → HTTPS → endpoint → payload/filter → user permissions.
Ponto técnico 13
Oxidized: API feed → token → model/group → SSH → credentials → repo → WebUI.
Ponto técnico 14
Pós-incidente: Registre timeline, impacto, causa raiz, ação corretiva, prevenção e evidência de recuperação.
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
su - librenms
cd /opt/librenms
./validate.php
./discovery.php -h HOSTNAME -d
./poller.php -h HOSTNAME -d
tail -n 200 /opt/librenms/logs/librenms.logRotina 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.