Desempenho

Histórico de carga do servidor: 24 horas, 7 ou 30 dias (recolha a cada 5 minutos)

Load Average (1m)
1.22
CPU
11.8%
RAM
30.8%
ESTABLISHED
92
Processos
1 / 397
Neste período são mostradas médias horárias, não as medições individuais.
Load Average
CPU
Memória
Rede (KB/s)
Disco I/O (KB/s)
Ligações TCP
Disco e limites (%)
MySQL
Processos na última medição 01:27
ProcessoCPU %RAM %
apache2 13.4 4.7
clamd 9.8 5.3
crowdsec 6.6 9.6
suricata 4.7 0.9
falco 2.6 16.5
Processos no pico do dia 11.10 08:57 · load 2.00
ProcessoCPU %RAM %
falco 19.5 5.3
mysqld 13.1 9.6
fail2ban-server 8.1 8.8
crowdsec 5.7 13.6
apache2 3.5 11.0

Histórico de carga do servidor sem Prometheus nem Grafana

O top responde a uma pergunta sobre o segundo actual, ao passo que a pergunta que realmente se faz é sobre a noite passada: porque é que às três da manhã tudo parou e voltou sozinho. A essa altura já não há nada para ver, porque nada ficou registado. Instalar Prometheus e Grafana para um único VPS levanta um problema próprio: a pilha que observa pesa mais do que o servidor observado.

Um colector acrescenta uma linha à base de dados de cinco em cinco minutos, e esta página desenha a partir daí as últimas 24 horas. Load average, utilização do CPU com o I/O wait à parte, RAM e swap, tráfego de rede recebido e enviado, leituras e escritas de disco, ligações TCP estabelecidas, processos, ocupação da partição, inodes e descritores de ficheiro em percentagem do limite, ligações do MySQL. Tudo numa página e no mesmo eixo temporal, de modo que as coincidências se vêem a olho.

Estes gráficos lêem-se aos pares. Um I/O wait elevado com o CPU tranquilo significa que o servidor está à espera do disco, e acrescentar núcleos não ajudará. Uma swap que subiu uma vez e nunca regressou a zero diz que o pico de memória já aconteceu, por muito calmo que pareça agora. Descritores de ficheiro perto dos cem por cento são um too many open files com algumas horas de antecedência. E na maioria dos servidores os inodes esgotam-se bastante antes do espaço livre.