Rendimiento

Historial de carga del servidor: 24 horas, 7 o 30 días (recogida cada 5 minutos)

Load Average (1m)
1.22
CPU
11.8%
RAM
30.8%
ESTABLISHED
92
Procesos
1 / 397
Load Average
CPU
Memoria
Red (KB/s)
E/S de disco (KB/s)
Conexiones TCP
Disco y límites (%)
MySQL
Procesos en la última medición 01:27
ProcesoCPU %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
Procesos en el pico del día 11.10 08:57 · load 2.00
ProcesoCPU %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

Historial de carga del servidor sin Prometheus ni Grafana

top responde a una pregunta sobre el segundo actual, mientras que la pregunta real suele ser sobre la noche pasada: por qué a las tres de la madrugada todo se detuvo y volvió por sí solo. Para entonces ya no queda nada que mirar, porque nada quedó registrado. Levantar Prometheus y Grafana para un único VPS tiene su propio inconveniente: la pila que observa pesa más que el servidor observado.

Un recolector añade una fila a la base de datos cada cinco minutos, y esta página dibuja con ellas las últimas 24 horas. Load average, uso de CPU con el I/O wait aparte, RAM y swap, tráfico de red entrante y saliente, lecturas y escrituras de disco, conexiones TCP establecidas, procesos, ocupación de la partición, inodos y descriptores de fichero como porcentaje de su límite, conexiones de MySQL. Todo en una página y sobre el mismo eje temporal, de modo que las coincidencias se ven a simple vista.

Conviene leer estas gráficas por parejas. Un I/O wait alto con la CPU tranquila significa que el servidor espera al disco, y añadir núcleos no servirá de nada. Un swap que subió una vez y nunca regresó a cero indica que el pico de memoria ya ocurrió, por tranquilo que parezca ahora. Unos descriptores de fichero cerca del cien por cien son un too many open files con varias horas de antelación. Y en la mayoría de los servidores los inodos se agotan bastante antes que el espacio libre.