Alertas e Detecção de Drift

Princípio que guia esta seção: uma lista de alertas em que ninguém confia é pior do que não ter alertas. Por isso o número de regras é mantido baixo, e eventos só acontecem quando o estado muda — um disco parado em 91% por uma semana é um evento, não dez mil.

Três Tipos de Evento

Tipo	Quando dispara
threshold	Uma métrica de recurso ultrapassa um limite definido por você.
drift	Uma configuração relacionada à segurança mudou desde o poll anterior.
reachability	A VM parou de responder, ou voltou a responder.

Cada evento tem nível info, warning ou critical, além de um título curto e uma descrição detalhada.

Limites de Recurso

Definidos em Configurações. Quatro limites: aviso de disco, crítico de disco, RAM e CPU.

O disco alerta imediatamente ao ultrapassar. RAM e CPU precisam ultrapassar em vários polls seguidos antes de alertar — um pico de CPU de um minuto durante um backup não vale a pena acordar ninguém.

Previsão de Disco Cheio

Limites estáticos dizem muito pouco sobre urgência. 80% que não se mexeu em um ano não precisa da atenção de ninguém; 60% que subiu dez pontos essa semana precisa que alguém aja hoje.

O app ajusta uma regressão linear pelos últimos sete dias de dados de cada mount e extrapola até o momento em que ele enche. O resultado aparece como “faltam cerca de N dias”.

Essa extrapolação prefere não responder a arriscar um chute, quando:

• há menos de 6 amostras ou os dados cobrem menos de 6 horas;
• a tendência está estável ou caindo (mount sendo liberado);
• o resultado está a mais de 365 dias de distância — “um dia vai encher” não é novidade.

As previsões são recalculadas no máximo uma vez por hora por VM, já que precisam ler uma semana de histórico.

O modelo assume que a taxa de crescimento se mantém constante. Isso é errado para rotação de log e errado para bancos de dados que dobram de tamanho da noite para o dia. Leia como um indicador de prioridade, não uma promessa.

Detecção de Drift

Quatro itens são comparados com o poll anterior. Esses são os rastros reais que um invasor deixa para trás:

Item	Mudanças detectadas
keys	authorized_keys — chaves SSH adicionadas ou removidas
users	/etc/passwd — novas contas, mudanças de shell
ports	Portas escutando — novos serviços expostos para fora
sudoers	/etc/sudoers e /etc/sudoers.d/*

A maioria das mudanças é legítima: um colega adiciona a própria chave, um novo serviço é implantado. O valor está em saber que aconteceu e quando — em vez de descobrir seis meses depois.

Revisão de Login SSH

Quando a conta usada no poll consegue ler o log de autenticação, o app resume:

• Logins bem-sucedidos — usuário, IP, método, horário.
• Falhas por IP — ordenadas por quantidade, as maiores primeiro.
• IPs bloqueados — lidos do fail2ban, se presente.
• Redes conhecidas — sub-redes de onde cada usuário costuma logar.

A parte de “redes conhecidas” é a mais útil aqui: um login bem-sucedido vindo de uma sub-rede desconhecida chama muito mais atenção do que milhares de falhas vindas da internet — falhas são normais para qualquer servidor exposto à rede.

Logins fora do horário comercial são sinalizados, não viram alertas por conta própria. Muito trabalho legítimo acontece à noite.

Confirmar Alertas

A central de alertas lista os eventos mais recentes primeiro. Marque como confirmado um por vez ou todos de uma vez; o contador na barra de status só mostra os não confirmados.

Eventos nunca são apagados quando você os confirma, e não são removidos pela retenção de 14 dias das métricas — eles são mantidos a longo prazo e alimentam os relatórios mensais.

Notificações do Sistema

Eventos de nível crítico disparam uma notificação do SO, então você os vê mesmo com a janela do app escondida. Ative/desative nas configurações de notificação do próprio sistema operacional.