Alertas e Monitoramento

O PrimeForge monitora continuamente os seus servidores — CPU, memória e disco — e pode avisá-lo automaticamente quando algo sai do normal. Você define regras de alerta com limites e severidades, escolhe por quais canais quer ser notificado, e acompanha tudo o que foi disparado no histórico de alertas, com um ciclo de vida claro de Aberto → Reconhecido → Resolvido.

Esta página cobre a criação de regras de alerta e o acompanhamento dos eventos disparados.

#Regras de Alerta

Uma regra de alerta descreve uma condição que, quando persiste por tempo suficiente, gera um evento e notifica quem você definir. As regras são avaliadas em cima das métricas que o Agent envia da frota a cada 30 segundos.

#Criando uma regra

1. Acesse Regras de Alerta na barra lateral e clique em Criar.
2. Configure a regra:

A duração existe para evitar ruído: um pico instantâneo de CPU não dispara nada; a condição precisa se manter pelo tempo configurado. O cooldown evita que a mesma regra o inunde de notificações enquanto o problema persiste. O escopo por servidor permite mirar uma regra em um servidor específico ou aplicá-la a toda a frota deixando o campo vazio.

#Canais de notificação por regra

Os campos de notificação abaixo aparecem e passam a ser obrigatórios apenas quando o canal correspondente é marcado:

Cada canal é independente: uma falha no envio de email não bloqueia o webhook, e vice-versa. Cada regra tem o seu próprio segredo de assinatura — comprometer o segredo de uma regra não permite forjar entregas de outra.

Proteção contra SSRF. O job de webhook de saída bloqueia qualquer URL que resolva para um IP privado ou reservado (RFC 1918, link-local, loopback). Se você apontar um webhook para 192.168.1.10, o painel registra um aviso e descarta a chamada — uma proteção deliberada contra usar o PrimeForge como sonda de rede interna.

#Ciclo de vida de um alerta

Quando uma métrica cruza o limite pela duração configurada:

1. Um evento de alerta é criado com status Aberto.
2. Os canais configurados disparam em paralelo — o email pela fila de e-mails do Laravel, o webhook pelo job de entrega assinada.
3. O evento aparece no cluster de Logs, na aba de Incidentes, como um bloco de aviso ou erro.
4. Um membro da equipe pode Reconhecer o alerta na página de histórico.
5. Quando a métrica volta ao normal, o alerta é Resolvido automaticamente e um payload de resolução é enviado aos mesmos canais.

#Histórico de Alertas

A página de Histórico de Alertas mostra todos os eventos disparados pelas suas regras, permitindo acompanhar padrões e tempos de resposta ao longo do tempo. Cada evento carrega a regra que o originou, o servidor afetado, a métrica e o valor que quebrou o limite, a severidade e o status atual.

Os eventos seguem o ciclo Aberto → Reconhecido → Resolvido, e você pode agir sobre eles diretamente na página:

• Reconhecer — sinaliza que a equipe está ciente do alerta e o está tratando. Útil para evitar que várias pessoas respondam ao mesmo incidente.
• Resolver — marca o evento como encerrado. Alertas também são resolvidos automaticamente quando a métrica volta ao normal.
• Dispensar — remove o evento da visão de incidentes ativos quando ele não exige ação.

Use esse histórico para investigar a linha do tempo de um incidente, medir com que frequência uma regra dispara (e se o limite precisa de ajuste) e confirmar que os alertas críticos foram efetivamente reconhecidos e resolvidos pela equipe.

#Próximos passos

• Notificações — configure os canais Email, Telegram e Discord e os webhooks de saída que recebem os alertas.
• Logs e Auditoria — onde os eventos de alerta aparecem no feed de incidentes da organização.
• Segurança — como verificar a assinatura HMAC dos webhooks que o PrimeForge envia.