Historial de carga del servidor: 24 horas, 7 o 30 días (recogida cada 5 minutos)
| Proceso | CPU % | RAM % |
|---|---|---|
| falco | 7.4 | 5.6 |
| mysqld | 4.4 | 7.3 |
| crowdsec | 2.6 | 15.6 |
| apache2 | 1.4 | 4.5 |
| fail2ban-server | 0.7 | 17.1 |
| Proceso | CPU % | RAM % |
|---|---|---|
| apache2 | 18.0 | 9.3 |
| mysqld | 12.8 | 14.0 |
| clamd | 8.9 | 14.3 |
| falco | 6.2 | 11.0 |
| suricata | 2.8 | 18.4 |
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.