Cómo monitorizar el rendimiento de un servidor Linux: comandos, métricas y herramientas

Para monitorizar el rendimiento de un servidor Linux, compruebe cuatro recursos: CPU, memoria, E/S de disco y red. Use comandos integrados como top, vmstat, free, iostat y ss para el diagnóstico en directo, y una herramienta basada en agentes, como Prometheus con node_exporter, Zabbix o el agente de CloudWatch, para guardar el histórico y enviar alertas.

Puntos clave

• Para cada recurso, compruebe utilización, saturación y errores (el método USE). Una utilización alta por sí sola no es un problema; lo son las colas y los errores.
• Compare la carga media con el número de núcleos de CPU y vigile %wa (espera de E/S) y %st (steal time) en las VM en la nube.
• En la memoria, lea la columna available de free, no free. Linux usa la memoria sobrante como caché a propósito.
• La información de bloqueo por presión (PSI) de /proc/pressure/ muestra directamente cuánto tiempo esperan las tareas por CPU, memoria o E/S.
• Los comandos muestran el presente. Para tendencias y alertas necesita un agente de monitorización y un almacén de series temporales.

¿Qué métricas de rendimiento de Linux importan?

Empiece con el método USE del ingeniero de rendimiento Brendan Gregg: para cada recurso, compruebe utilización, saturación y errores. Le da una lista de verificación en lugar de conjeturas.

¿Cómo se comprueba el uso de CPU y la carga en Linux?

Ejecute top (o htop) y lea la línea de CPU; después compare la carga media con el número de núcleos que da nproc.

top # vista en directo; pulse 1 para ver cada núcleo
nproc # número de núcleos de CPU
uptime # carga media a 1, 5 y 15 minutos
mpstat -P ALL 1 # uso por núcleo cada segundo (paquete sysstat)

Según la página de manual de proc_loadavg, la carga media cuenta los trabajos que se están ejecutando o esperan E/S de disco, promediados a 1, 5 y 15 minutos. Una carga de 6 en un servidor de 8 núcleos es normal. Una carga de 6 en un servidor de 2 núcleos significa que el trabajo se está acumulando en cola. Como la carga incluye procesos que esperan al disco, una carga alta con poco uso de CPU suele apuntar a un problema de almacenamiento.

En la línea de CPU de top, dos campos importan en los servidores en la nube:

• wa: tiempo que la CPU estuvo inactiva esperando E/S. Los valores altos sostenidos apuntan a discos o almacenamiento en red lentos.
• st: según la página de manual de top, «tiempo robado a esta VM por el hipervisor». Un steal sostenido en una VM en la nube significa que el host está ocupado o que una instancia con ráfagas ha agotado sus créditos de CPU.

¿Cómo se comprueba el uso de memoria en Linux?

Ejecute free -h y lea la columna available. La página de manual de free la define como una estimación de la memoria disponible para aplicaciones nuevas sin recurrir al swap, teniendo en cuenta la caché de páginas.

free -h # resumen de memoria legible
vmstat 1 5 # las columnas si/so muestran swap de entrada/salida por segundo
journalctl -k | grep -i "out of memory" # eventos del OOM killer

Un servidor con poca memoria «libre» pero mucha «disponible» está sano: Linux llena la RAM sobrante con caché de disco y la libera cuando los programas la necesitan. Las señales de alarma son una memoria available que cae a lo largo de días (posible fuga), actividad constante de swap en vmstat y entradas del OOM killer en el registro del kernel.

¿Cómo se comprueban el rendimiento y el espacio del disco?

Use iostat -xz 1 para el rendimiento de E/S y df para el espacio y los inodos.

iostat -xz 1 # utilización, cola y latencia por dispositivo (sysstat)
df -h # espacio en disco por sistema de archivos
df -i # uso de inodos: muchos archivos pequeños pueden llenarlos antes
du -sh /var/log/* | sort -h # averigüe qué ocupa espacio

En iostat, vigile r_await y w_await (milisegundos medios por solicitud) y aqu-sz (longitud de la cola). La página de manual de iostat señala que, en los dispositivos que atienden solicitudes en paralelo, como las matrices RAID y los SSD modernos, %util no refleja sus límites de rendimiento. Una latencia y una longitud de cola crecientes son mejores señales de saturación.

¿Cómo se monitoriza el rendimiento de la red?

sar -n DEV 1 # rendimiento por interfaz
sar -n TCP,ETCP 1 # conexiones TCP y retransmisiones
ss -s # resumen de sockets
ip -s link # errores y descartes por interfaz

El aumento de retransmisiones, descartes o errores de interfaz indica problemas de red aunque el rendimiento parezca normal. En las VM en la nube, compare el rendimiento con el límite de red del tipo de instancia.

¿Qué es la información de bloqueo por presión (PSI)?

PSI es una función del kernel que informa de cuánto tiempo pasan las tareas esperando CPU, memoria o E/S. La documentación del kernel explica que cada archivo de /proc/pressure/ tiene una línea «some» (proporción de tiempo en que al menos algunas tareas están bloqueadas) y, para memoria y E/S, una línea «full» (todas las tareas no inactivas bloqueadas a la vez, lo que el kernel describe como thrashing).

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

PSI responde directamente a «¿este recurso está frenando el trabajo?», lo que lo convierte en una buena señal para alertas. Si los archivos no existen, su kernel se compiló o arrancó sin soporte de PSI.

¿Qué herramientas usar para la monitorización continua?

Los comandos muestran lo que ocurre ahora. Para detectar problemas por la noche, ver tendencias y avisar a la persona adecuada, instale un agente de monitorización que envíe las métricas a un almacén de series temporales.

¿Qué alertas conviene configurar primero?

1. Espacio en disco e inodos por encima del 80–85 % en cualquier sistema de archivos, con una alerta de previsión de «lleno en 24 horas».
2. Memoria disponible baja durante más de 10 minutos, o cualquier evento del OOM killer.
3. Carga media superior al número de núcleos durante más de 15 minutos, o presión de CPU en aumento.
4. Latencia de disco o presión de E/S muy por encima de la línea base normal del servidor.
5. Comprobaciones de servicio: el puerto de la aplicación responde y una URL de salud devuelve éxito.
6. Copias de seguridad y caducidad de certificados, que fallan en silencio.

Estos umbrales son puntos de partida. Ajústelos al comportamiento normal de cada servidor para que las alertas sigan siendo accionables. Nuestra guía sobre cómo monitorizar el rendimiento de un servidor cubre Windows y las prácticas generales, y la de monitorizar la infraestructura cloud cubre los servicios gestionados más allá del servidor.

Cómo ayuda Opsio

Opsio monitoriza y opera servidores Linux en AWS, Azure y en local como parte de nuestros servicios de TI gestionados, con respuesta a alertas 24/7, parcheo y revisiones de capacidad, con Prometheus y Grafana o con herramientas nativas de la nube. Por ejemplo, la plataforma AWS que construimos para WorkBuster funciona sobre instancias EC2 en un grupo de escalado automático, con paneles y alarmas de CloudWatch para la operación diaria.

Preguntas frecuentes

¿Cuál es el mejor comando para comprobar el rendimiento de un servidor Linux?

Empiece con top para una visión general en directo, después vmstat 1 para las tendencias de CPU, memoria y swap, e iostat -xz 1 para los discos. Juntos muestran la mayoría de los cuellos de botella en un minuto.

¿Qué es una buena carga media para un servidor Linux?

Depende del número de núcleos de CPU. Una carga media igual o inferior al número de núcleos suele significar que no hay colas. Una carga sostenida por encima del número de núcleos significa que las tareas esperan CPU o disco.

¿Por qué Linux muestra casi nada de memoria libre?

Linux usa la RAM sin utilizar como caché de disco y la devuelve cuando las aplicaciones la necesitan. Compruebe en su lugar la columna available de free -h; es la memoria realmente disponible para trabajo nuevo.

¿Cómo veo qué proceso usa más CPU o memoria?

En top, pulse P para ordenar por CPU y M para ordenar por memoria. Desde un script, use ps aux --sort=-%cpu | head o ps aux --sort=-%mem | head.

¿Cómo monitorizo un servidor Linux de forma remota?

Instale un agente como node_exporter, el agente de Zabbix o el agente de CloudWatch, y envíe las métricas a un servidor central o a un servicio en la nube. Así tiene histórico, paneles y alertas sin entrar en cada máquina.