Performance e Tuning

Performance e Tuning

Antes de distributed polling, otimize instalação simples. Medir duração do polling, workers, database e I/O evita complexidade prematura.

Ponto técnico 1

Primeiro princípio: Antes de distributed polling, otimize instalação simples. Medir duração do polling, workers, database e I/O evita complexidade prematura.

Ponto técnico 2

Poller: Todos os devices precisam terminar dentro do polling interval. Dispositivos lentos podem dominar worker-seconds.

Ponto técnico 3

Dispatcher metrics: Observe Consumed Worker Seconds, Maximum Worker Seconds e Devices Pending.

Ponto técnico 4

RRDCached: Reduz I/O síncrono de RRD e prepara ambiente distribuído.

Ponto técnico 5

MariaDB: Buffer pool, storage, latency e índices/queries precisam ser monitorados. Não copie tuning genérico sem medir memória e workload.

Ponto técnico 6

PHP/Web: WebUI lenta pode ser PHP-FPM/banco e não polling.

Ponto técnico 7

SNMP latency: RTT, timeout e resposta do device afetam duração. Poller remoto não é automaticamente solução; distributed polling não é projetado como 'remote polling' por si só.

Ponto técnico 8

RRD storage: I/O e quantidade de arquivos crescem com devices/ports/sensors.

Ponto técnico 9

Capacidade: Acompanhe devices, ports, sensors, alert rate, DB size, RRD size e tempo de polling.

Ponto técnico 10

Troubleshooting: device poll time → worker saturation → DB → RRD I/O → network SNMP → WebUI.

Procedimento de engenharia

Comandos / fluxo de referência

cd /opt/librenms
./validate.php

# Observe Poller UI: worker seconds, pending devices, node performance

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

1. Registre um baseline saudável.
2. Induza uma falha controlada relacionada ao tema.
3. Identifique a camada com falha antes de reiniciar componentes.
4. Corrija a causa identificada e valide a recuperação.

Pronto para produção?

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.