Alert Rules
Alert Rule usa entidade, condição e valor, com lógica, macros e expressões. Um alerta deve representar condição operacional acionável.
Ponto técnico 1
Modelo: Alert Rule usa entidade, condição e valor, com lógica, macros e expressões. Um alerta deve representar condição operacional acionável.
Ponto técnico 2
Severidade: Use Warning/Critical conforme impacto, não apenas valor numérico. Um link backup down e backbone down não são iguais.
Ponto técnico 3
Escopo: A regra pode ser global ou restrita por devices, groups e locations.
Ponto técnico 4
Portas: Evite alertar todas as portas down. Use ifAlias/descrição, tipo e finalidade para filtrar portas administrativamente desligadas ou access vazias.
Ponto técnico 5
Macros: Macros como device_up e past_5m ajudam regras mais ricas. Entenda o SQL/lógica gerada antes de usar expressões complexas.
Ponto técnico 6
Recovery: Recovery alerts devem ser planejados, não presumidos. O NOC precisa saber quando o serviço realmente voltou.
Ponto técnico 7
Procedure URL: Associe runbook/procedimento quando possível, tornando o alerta uma entrada de operação.
Ponto técnico 8
Ruído: Mute transport não elimina a existência do alerta no WebUI. Diferencie supressão de notificação de condição real.
Ponto técnico 9
Teste: Crie regra em laboratório, provoque condição, confirme fault, severidade, template, operação, transporte e recovery.
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.