Dominando el Rendimiento: Una Guía Práctica para Usar el Conjunto de Herramientas Sysstat

El trabajo de rendimiento se vuelve complicado cuando solo tienes el momento actual. Un servidor está lento ahora, pero ¿lo estaba hace diez minutos? ¿El disco comenzó a respaldarse antes de que la CPU subiera? ¿El problema comenzó después del cron job, el despliegue o la ventana de respaldo? El conjunto de herramientas sysstat es útil porque te proporciona tanto lecturas en vivo como un registro histórico con el que puedes comparar.

La herramienta principal es sar, el Reportador de Actividad del Sistema. Recurro a ella cuando top es demasiado breve, cuando ya pasó un incidente, o cuando necesito mostrar que un problema fue de almacenamiento, presión de memoria, tráfico de red o saturación de CPU en lugar de adivinar a partir de los síntomas. El resto del conjunto, especialmente iostat y mpstat, completa los detalles cuando sar te señala un posible cuello de botella.

Esto no reemplaza una observabilidad completa. Todavía necesitas métricas de aplicación, registros, trazado y comprobaciones externas. Pero en un host Linux, sysstat es una de las formas más rápidas de responder la primera pregunta práctica: ¿qué estaba haciendo realmente la máquina?

1. Instalación y Configuración Inicial de Sysstat

El paquete sysstat suele estar disponible en los repositorios estándar de todas las principales distribuciones de Linux.

1.1 Comandos de Instalación

Utilice el comando del gestor de paquetes apropiado para su sistema:

Debian/Ubuntu:

sudo apt update
sudo apt install sysstat

RHEL/CentOS/Fedora:

sudo yum install sysstat
# o use dnf para sistemas más nuevos
sudo dnf install sysstat

1.2 Habilitación de la Recopilación de Datos Históricos

Para que sar sea realmente útil, debe recopilar datos históricamente. Por defecto, la instalación a menudo configura un cron job o un timer de systemd, pero la verificación es crucial.

En sistemas modernos, asegúrese de que el servicio sysstat esté activo:

sudo systemctl enable --now sysstat

Archivo de Configuración

La frecuencia de recopilación de datos se controla mediante archivos de configuración, típicamente ubicados en /etc/default/sysstat (Debian/Ubuntu) o /etc/sysconfig/sysstat (RHEL/CentOS). Busque la configuración ENABLED o HISTORY. Establecer ENABLED="true" asegura la recopilación diaria de datos.

Consejo: Por defecto, los archivos de datos de sysstat se almacenan en /var/log/sa/ con nombres de archivo como saXX donde XX es el día del mes. Algunos sistemas basados en Debian también exponen informes bajo /var/log/sysstat/. Verifique los valores predeterminados de su paquete antes de asumir la ruta.

Después de habilitar la recopilación, espere al menos un intervalo y confirme que los archivos están apareciendo:

ls -lh /var/log/sa/

Si el directorio está vacío, verifique los timers de systemd:

systemctl list-timers | grep sysstat
systemctl status sysstat-collect.timer

En sistemas más antiguos, la recopilación aún puede estar impulsada por cron. El empaquetado exacto varía según la distribución, así que verifique en lugar de confiar en la memoria de otro servidor.

2. La Utilidad Principal: Reportador de Actividad del Sistema (`sar`)

sar es la interfaz principal para ver estadísticas. Puede mostrar datos en tiempo real o analizar datos históricos previamente recopilados.

2.1 Sintaxis Básica para Monitorización en Tiempo Real

La sintaxis básica está diseñada para reportar métricas específicas en un intervalo especificado durante un número definido de veces.

sar [opciones] [intervalo] [cuenta]

Ejemplo: Para reportar estadísticas generales de CPU cada 3 segundos, 10 veces:

sar -u 3 10

Ese comando es bueno durante un incidente porque te da una muestra móvil corta en lugar de una sola instantánea. Una sola línea puede capturar un segundo tranquilo y engañarte. Diez muestras durante treinta segundos muestran si el patrón es constante, con picos o ya se ha ido.

Opción	Descripción
`-u`	Utilización de CPU (predeterminado)
`-r`	Estadísticas de memoria y paginación
`-d`	Actividad de dispositivos de bloque (E/S de disco)
`-n`	Estadísticas de red (ej., `-n DEV` para estadísticas de interfaz)
`-q`	Cola de ejecución y carga promedio
`-W`	Actividad de intercambio (paginación)
`-A`	Todas las métricas (útil para instantáneas completas)

Para archivos históricos, la forma es la misma. Agregue -f para elegir el archivo de datos y a menudo -s y -e para limitar el rango de tiempo. Eso importa porque leer un día completo de salida durante una interrupción es lento y ruidoso.

3. Métricas Clave de Rendimiento y Ejemplos Prácticos de `sar`

Entender la salida de sar requiere conocimiento de qué métricas indican salud o estrés en el rendimiento.

3.1 Utilización de CPU (`sar -u`)

La utilización de CPU es a menudo el primer lugar para buscar cuellos de botella. Una alta utilización en categorías específicas indica la naturaleza de la carga de trabajo.

sar -u 5 3

Métrica	Descripción	Indicador de Cuello de Botella
`%user`	Tiempo de CPU dedicado a ejecutar procesos de nivel de usuario.	Alto indica saturación de la aplicación/servicio.
`%system`	Tiempo de CPU dedicado a ejecutar tareas del kernel/sistema.	Alto sugiere llamadas al sistema intensivas o problemas de controladores.
`%iowait`	Tiempo de CPU inactivo esperando operaciones de E/S (disco/red).	Alto indica un cuello de botella de E/S, no escasez de CPU.
`%idle`	Tiempo de CPU dedicado a esperar nada (disponible).	Bajo (ej., < 5%) sugiere saturación de CPU.

Tenga cuidado con %iowait. Comúnmente se malinterpreta como "la CPU está ocupada con el disco". En realidad significa que la CPU estaba inactiva mientras al menos una solicitud de E/S estaba pendiente. Un valor alto puede apuntar hacia latencia de almacenamiento, pero necesita confirmación con métricas de disco. En un servidor de base de datos, por ejemplo, un alto %iowait junto con un alto await de disco es una señal mucho más fuerte que %iowait por sí solo.

Otra vista útil de CPU es la cola de ejecución:

sar -q 5 5

runq-sz muestra cuántas tareas están esperando para ejecutarse. Si la carga promedio es alta pero runq-sz es modesta y %iowait es alto, es posible que esté viendo E/S bloqueada en lugar de presión pura de CPU. Si runq-sz se mantiene alto y %idle está cerca de cero, la máquina probablemente necesita menos procesos ejecutables, código más rápido o más capacidad de CPU.

3.2 Memoria y Paginación (`sar -r` y `sar -W`)

Las estadísticas de memoria revelan tanto el consumo como si el sistema está recurriendo al intercambio o la paginación.

Utilización de Memoria (sar -r):

sar -r 1 5

Concéntrese en kbavail (memoria disponible). Si kbmemfree es bajo, pero kbcached y kbbuffers son altos, la memoria está siendo utilizada de manera eficiente por el mecanismo de caché del kernel.

Actividad de Intercambio (sar -W):

sar -W 1 5

Observe pswpin/s (páginas intercambiadas hacia adentro) y pswpout/s (páginas intercambiadas hacia afuera). Cualquier valor significativo distinto de cero aquí indica que el sistema está intercambiando agresivamente, señalando presión de memoria (un fuerte cuello de botella).

La salida de memoria de Linux puede parecer alarmante hasta que recuerde que la caché no es memoria desperdiciada. Un servidor con muy poco kbmemfree aún puede estar saludable si kbavail es cómodo y la actividad de intercambio es silenciosa. El patrón peligroso es diferente: la memoria disponible cae, aparece actividad de intercambio hacia adentro y hacia afuera, y la latencia de la aplicación aumenta. Eso le dice que los procesos están tocando memoria que ya no cabe en la RAM.

Para un servidor web, eso podría suceder después de un despliegue que accidentalmente duplica el número de workers. Para un host de lotes, podría suceder cuando dos trabajos grandes se superponen. sar no le dirá qué proceso lo causó, pero le da la línea de tiempo. Combínelo con ps, top, registros de servicio o métricas de cgroup para identificar al responsable.

3.3 Actividad de E/S de Disco (`sar -d`)

Monitorear la actividad del disco es crucial para servidores de bases de datos o sistemas de almacenamiento muy utilizados.

sar -d 3 5

Esta salida requiere identificar los dispositivos específicos (ej., sda, vda). Las métricas clave incluyen:

tps: Transferencias por segundo (un valor alto indica altas solicitudes de E/S).
rd_sec/s y wr_sec/s: Cantidad de datos leídos/escritos por segundo.
%util: Porcentaje de tiempo que el dispositivo estuvo ocupado atendiendo solicitudes. Si %util se mantiene cerca del 100% en un dispositivo de bloque tradicional, el almacenamiento puede estar saturado.

En SSD modernos y discos virtuales, %util merece contexto. Algunos dispositivos manejan bien la E/S paralela, y los volúmenes en la nube pueden estar limitados por IOPS aprovisionados, rendimiento o créditos de ráfaga. Trate %util como un aviso para mirar más de cerca, no como un diagnóstico completo. Confirme con iostat -xd, latencia de aplicación y métricas de almacenamiento a nivel de plataforma si está en AWS, Azure, GCP u otro entorno virtualizado.

Un flujo de trabajo práctico es:

sar -d -f /var/log/sa/sa24 -s 09:00:00 -e 10:00:00
iostat -xd 2 5

Use sar para encontrar la mala hora, luego use iostat durante una recurrencia en vivo para inspeccionar la latencia a nivel de dispositivo.

3.4 Estadísticas de Red (`sar -n`)

sar puede reportar actividad en varias capas de red. La verificación más común es la actividad de interfaz (DEV).

sar -n DEV 5 1

Este comando muestra métricas como rxpk/s (paquetes recibidos por segundo) y txkB/s (kilobytes transmitidos por segundo) para cada interfaz de red. Úselo para identificar interfaces que experimentan carga pesada o posibles errores.

Para contadores de errores, agregue EDEV:

sar -n EDEV 5 3

Esto puede mostrar errores de recepción, errores de transmisión, descartes y colisiones cuando el controlador lo admite. Los descartes son especialmente útiles cuando un servicio se queja de timeouts intermitentes pero la CPU y el disco se ven normales. Si los descartes aumentan durante los picos de tráfico, es posible que necesite inspeccionar las colas de NIC, la configuración de red del kernel, la red de contenedores o la ruta del balanceador de carga.

Para el comportamiento a nivel de TCP, pruebe:

sar -n TCP,ETCP 5 3

Las retransmisiones, los resets y los intentos de conexión fallidos pueden convertir un informe vago de "el sitio está lento" en un problema de red o upstream más específico.

4. Análisis Histórico y Creación de Líneas Base

El verdadero poder de sysstat radica en su capacidad para analizar la actividad del sistema durante períodos prolongados, lo cual es esencial para establecer líneas base de rendimiento (qué es normal para su sistema).

4.1 Análisis de Días Anteriores

Para ver datos recopilados en un día anterior, use la bandera -f para especificar la ruta al archivo diario saXX.

Ejemplo: Para ver estadísticas de CPU del día 10 del mes actual:

sar -u -f /var/log/sa/sa10

Para revisar estadísticas en una ventana de tiempo específica de ese día, agregue las banderas -s (hora de inicio) y -e (hora de fin) (usando formato de 24 horas).

# Ver estadísticas de red de 14:00 a 16:30 del día 10
sar -n DEV -f /var/log/sa/sa10 -s 14:00:00 -e 16:30:00

4.2 Establecimiento de Líneas Base

Recopile Datos: Ejecute sysstat durante períodos normales de alta y baja carga.
Identifique Normas: Analice datos históricos (sar -f) para determinar la utilización promedio de CPU (%user, %system), la latencia máxima de E/S (%util) y el uso promedio de memoria.
Defina Umbrales: Trate las desviaciones sostenidas de su propia línea base como desencadenantes de investigación. Un host de base de datos ocupado y un jump box tranquilo no deberían compartir los mismos umbrales.

Las líneas base son más útiles cuando están vinculadas a ritmos comerciales reales. Una importación por lotes del lunes por la mañana, un respaldo nocturno y un lanzamiento de producto crean diferentes formas "normales". Tome notas cuando investigue: "respaldo comenzó a las 01:00", "nueva versión a las 14:30", "correo de marketing a las 09:05". Esas notas hacen que la salida histórica de sar sea mucho más fácil de interpretar más tarde.

5. Herramientas de Soporte de Sysstat

Mientras que sar es la herramienta general, el conjunto sysstat incluye utilidades especializadas que ofrecen informes enfocados y de alto detalle.

5.1 iostat (Estadísticas de Entrada/Salida)

iostat proporciona métricas detalladas centradas específicamente en la utilización del dispositivo, particularmente útil al diagnosticar cuellos de botella de almacenamiento.

# Reportar estadísticas de disco cada 2 segundos, 4 veces, incluyendo estadísticas extendidas (x)
iostat -xd 2 4

Métricas clave de iostat:

%util: El porcentaje de tiempo de CPU durante el cual se emitieron solicitudes de E/S al dispositivo (indicador crucial de saturación).
await: El tiempo de espera promedio (en milisegundos) para las solicitudes de E/S emitidas al dispositivo. Un await alto indica una respuesta lenta del almacenamiento.

Si await aumenta pero el rendimiento no es alto, busque E/S aleatoria pequeña, problemas del sistema de archivos, vecinos ruidosos en infraestructura virtual o una aplicación que realiza escrituras pesadas sincrónicas. Si el rendimiento es alto y la latencia aumenta con él, el dispositivo puede simplemente estar en su límite práctico.

5.2 mpstat (Estadísticas de Multiprocesador)

Si sospecha problemas de planificación de CPU o distribución desigual de la carga de trabajo entre núcleos, mpstat proporciona estadísticas de uso por procesador, algo que sar -u agrega.

# Mostrar uso para todas las CPU (A) cada 2 segundos
mpstat -P ALL 2 1

Esto es invaluable para identificar aplicaciones de un solo hilo que están saturando un solo núcleo mientras otros permanecen inactivos, o para diagnosticar la eficiencia del hyperthreading.

5.3 sadf (Exportación de Datos de Sysstat)

sadf lee los mismos datos recopilados que sar pero puede imprimirlos en formatos que son más fáciles de consumir para scripts y paneles de control.

sadf -d /var/log/sa/sa24 -- -u
sadf -j /var/log/sa/sa24 -- -r

La salida -d es útil para el procesamiento de texto delimitado. La salida -j es útil cuando desea JSON. Esto es práctico cuando necesita adjuntar evidencia a una revisión de incidente o comparar dos hosts sin copiar manualmente la salida del terminal.

6. Un Recorrido Práctico por un Incidente

Imagine un servidor API que comenzó a tener timeouts a las 10:15. Los registros de la aplicación muestran solicitudes acumulándose, pero no explican por qué. Comience con la vista histórica de CPU:

sar -u -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Si %user es alto y %idle es bajo, la aplicación puede estar limitada por CPU. Verifique el uso por núcleo:

sar -P ALL -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Si un núcleo está al máximo mientras otros están tranquilos, sospeche de un worker de un solo hilo, un bloqueo activo o una distribución desigual de procesos. Si todos los núcleos están ocupados, observe la tasa de solicitudes, los despliegues recientes y las rutas de código costosas.

Si la CPU parece mayormente inactiva pero %iowait aumenta, cambie al disco:

sar -d -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Una alta utilización del dispositivo o una profundidad de cola creciente alrededor del mismo momento apunta hacia el almacenamiento. En un servicio respaldado por base de datos, la siguiente parada son los registros de la base de datos y los datos de consultas lentas. En un host que sirve archivos, verifique si un respaldo, un trabajo de compresión o una rotación de registros se ejecutaron al mismo tiempo.

Si la CPU y el disco se ven bien, inspeccione la memoria y la red:

sar -r -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -W -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -n DEV,EDEV,TCP,ETCP -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

El punto no es ejecutar todos los comandos cada vez. El punto es seguir la evidencia. sar te da una línea de tiempo a través de las clases de recursos, que es generalmente lo que necesitas para dejar de perseguir el síntoma más ruidoso.

Un Hábito Operativo Simple

La mejor manera de aprender sysstat es usarlo antes de que algo se rompa. Verifique un servidor saludable durante el tráfico normal. Verifíquelo durante los respaldos. Verifíquelo después de un despliegue. Guarde algunos patrones de comando que coincidan con su entorno.

Cuando ocurra un incidente, ya sabrá cómo se ve lo normal. Ese es el valor real del conjunto de herramientas. sar, iostat, mpstat y sadf no diagnostican mágicamente la aplicación por usted, pero mantienen la conversación basada en evidencia: cuándo comenzó el problema, qué recurso cambió y si el host estaba realmente bajo presión.