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, a entrega acontece pelos canais de notificação da organização, e acompanha tudo o que foi disparado no Log 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. Para monitorar jobs que precisam "dar sinal de vida" em vez de métricas de servidor, use os Heartbeats do site.

#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 Configurações → Notificações → Alertas (pelo menu do avatar) e clique em Criar Regra de Alerta.
2. Configure a regra, em duas seções:

O que observar

Onde e quando avisar

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 limite é sempre um percentual e é recusado acima de 100 — uma regra "acima de 150%" seria salva, apareceria como ativa e nunca dispararia. 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.

#Quem é avisado

A regra não tem mais lista de e-mails nem URL de webhook próprios. Quem recebe um alerta são os canais de notificação da organização inscritos nos eventos de alerta — os canais de E-mail, Telegram e Discord e os endpoints de webhook configurados em Configurações → Notificações. Assim existe um só lugar para dizer "para onde vão os avisos", em vez de uma lista de destinatários escondida dentro de cada regra.

A própria página da regra mostra quem está escutando de fato — quais canais estão ligados e quantos webhooks assinam os eventos de alerta — e troca esse resumo por um aviso âmbar quando ninguém está inscrito: a regra dispararia sem avisar ninguém. Um atalho leva direto à configuração dos canais; para quem não tem permissão de mexer neles (um Developer, por exemplo), o texto diz para pedir a um administrador em vez de oferecer um botão que responderia 403.

O segredo de assinatura agora pertence ao endpoint de webhook, não à regra — veja Notificações.

Proteção contra SSRF. A entrega de webhook 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 da organização inscritos nos eventos de alerta disparam em paralelo — o e-mail pela fila do Laravel, os webhooks pelo job de entrega assinada.
3. O evento aparece no feed Precisa atenção do Dashboard e em Operações → Incidentes e logs → Incidentes, como um bloco de aviso ou erro, com link para o servidor afetado.
4. Um membro da equipe marca que está cuidando dele — Reconhecer, no feed de Incidentes, ou Confirmar, no Log de Alertas. O status passa a Reconhecido.
5. Quando a métrica volta ao normal, o alerta é Resolvido automaticamente e um payload de resolução é enviado aos mesmos canais.

#Log de Alertas

A página Log de Alertas (em Operações → Incidentes e logs) 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:

• Confirmar — marca o alerta como visto (status Reconhecido): ele deixa de ser novo, mas continua aberto até ser resolvido. Ú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; se a condição voltar a ocorrer, a regra abre um alerta novo.
• Dispensar — tira o evento do feed "Precisa atenção" do Dashboard e da severidade da frota, quando ele não exige ação. O alerta continua no log para auditoria, e Restaurar o traz de volta.

Use esse log 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.