Distributed Polling

Distributed Polling

Use quando uma instalação otimizada não consegue processar a carga dentro do intervalo ou quando precisa separar workloads. A documentação afirma que um poller pode lidar com 1000+ devices, dependendo de latência e responsividade.

Ponto técnico 1

Quando usar: Use quando uma instalação otimizada não consegue processar a carga dentro do intervalo ou quando precisa separar workloads. A documentação afirma que um poller pode lidar com 1000+ devices, dependendo de latência e responsividade.

Ponto técnico 2

Não é remote polling: A documentação oficial alerta que distributed polling não é projetado especificamente para polling remoto. Latência e arquitetura precisam ser consideradas.

Ponto técnico 3

Requisitos: Dispatcher Service, RRDCached e Redis, além de banco e RRD compartilhados/acessíveis.

Ponto técnico 4

Nós: Todos os poller nodes conectam ao mesmo database, RRDCached e Redis.

Ponto técnico 5

APP_KEY/NODE_ID: APP_KEY deve ser igual em todos os nós; NODE_ID deve ser único.

Ponto técnico 6

Redis: Use para coordenação e, quando configurado, cache, queues e sessions. Proteja Redis com ACL/rede.

Ponto técnico 7

Poller Groups: Distribuem devices entre conjuntos de pollers. Workers são divididos entre grupos, então distribuição desigual pode criar pendência.

Ponto técnico 8

Sequência de evolução: Single node estável → RRDCached → Dispatcher → tuning → separar serviços → Redis → novo poller.

Ponto técnico 9

Validação: validate.php -m dist-poller e Poller UI devem fazer parte do rollout.

Ponto técnico 10

Falha: Se um nó some, confirme Redis, DB, RRDCached, NODE_ID, group e worker assignment.

Procedimento de engenharia

Comandos / fluxo de referência

cd /opt/librenms
./validate.php -m dist-poller

# Todos os nós: APP_KEY igual; NODE_ID único.

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.