sar, la herramienta de informes del paquete sysstat, guarda cada pocos minutos el estado de la CPU (unidad central de procesamiento), la memoria, los discos y la red de un servidor Linux, y permite reconstruir después qué pasó durante un incidente sin instalar agentes ni contratar un servicio externo. Un artículo publicado en Medium por el autor bektiaw la presenta como el «registrador de vuelo» que muchos sistemas ya tienen a mano y como alternativa ligera a plataformas como Datadog. Esta guía repasa la idea con comandos probados en Ubuntu 24.04 (sysstat 12.6.1) y señala qué cambia en Red Hat Enterprise Linux (RHEL) y sus derivadas.
Las claves de sar y sysstat en 30 segundos
- sysstat recoge métricas del sistema con sadc y las guarda en ficheros binarios diarios que después se consultan con sar o se exportan con sadf.
- En Ubuntu 24.04 y RHEL 8 y 9 la recogida depende de temporizadores de systemd, no de cron, y el intervalo por defecto es de 10 minutos.
- Las estadísticas de disco requieren la opción «-S DISK» y las de TCP, «-S SNMP».
- Bajar el intervalo a un minuto y fijar LC_ALL=C facilita investigar picos y filtrar con awk.
sar no sustituye a un sistema de monitorización con alertas y paneles. Su papel es otro: responder con datos a la pregunta de qué estaba haciendo la máquina a las 03:12 de anoche, cuando nadie miraba, y hacerlo con un consumo de recursos mínimo.
Cómo funciona sysstat y cómo dejarlo bien configurado
Las piezas: sadc, sa1, sa2, sar y sadf
El paquete reparte el trabajo entre varias utilidades. sadc es el colector: lee los contadores del kernel y escribe registros binarios. sa1 es un envoltorio de shell que llama a sadc y es lo que ejecutan los temporizadores. sa2 genera el resumen diario en texto y borra o comprime ficheros antiguos. sar lee los binarios y los presenta en tablas, y sadf exporta esos mismos datos en formatos que entienden otras herramientas.
Los datos van a un fichero por día del mes: saDD es el binario y sarDD, el informe de texto que genera sa2. En Debian y Ubuntu viven en /var/log/sysstat/; en RHEL, en /var/log/sa/. Cada línea de sar resume el intervalo transcurrido desde el registro anterior, así que con muestras de 10 minutos un pico de 30 segundos queda diluido en la media.
| Elemento | Debian y Ubuntu | RHEL y derivadas |
|---|---|---|
| Datos | /var/log/sysstat/saDD | /var/log/sa/saDD |
| Configuración | /etc/sysstat/sysstat | /etc/sysconfig/sysstat |
| Scripts sa1 y sa2 | /usr/lib/sysstat/ | /usr/lib64/sa/ |
| Retención por defecto | HISTORY=7 | HISTORY=28 |
Instalación y activación
La instalación es directa en ambas familias:
# Debian y Ubuntu
sudo apt install sysstat
# RHEL, AlmaLinux, Rocky Linux
sudo dnf install sysstat
# Activar el servicio y sus dos temporizadores
sudo systemctl enable --now sysstat
systemctl list-timers 'sysstat*'Lenguaje del código: PHP (php)En Debian y Ubuntu existe además /etc/default/sysstat, con la línea ENABLED="false" por defecto. Muchas guías indican cambiarla a "true", pero conviene entender qué controla. En sistemas con systemd, los scripts de cron que leen esa variable (debian-sa1 y el resumen diario de /etc/cron.daily) terminan sin hacer nada en cuanto detectan systemd, y lo que decide si hay recogida es el estado de sysstat-collect.timer y sysstat-summary.timer. En la prueba con Ubuntu 24.04, la instalación creó los enlaces que activan las unidades aunque el fichero seguía en «false». Para dejar ambas cosas coherentes, la vía más limpia es sudo dpkg-reconfigure sysstat, que reescribe la variable y activa o desactiva las unidades a la vez. En RHEL ese fichero no existe y basta con systemctl enable --now sysstat, porque sysstat.service arrastra los dos temporizadores.
Bajar el intervalo a un minuto
El temporizador de recogida trae OnCalendar=*:00/10, es decir, cada 10 minutos, y ejecuta sa1 1 1: un registro por ejecución, que es lo correcto. Para pasar a un minuto se crea una sobrescritura con sudo systemctl edit sysstat-collect.timer:
[Timer]
OnCalendar=
OnCalendar=*:*:00La expresión *:*:00 equivale a «cada minuto en el segundo cero» (systemd-analyze calendar '*:*:00' la normaliza igual que minutely). La línea vacía OnCalendar= borra la programación original; sin ella, systemd suma ambas. En este caso concreto el resultado sería el mismo, pero es una buena costumbre para cualquier otro intervalo. systemctl edit recarga la configuración al guardar, así que después basta con reiniciar el temporizador: sudo systemctl restart sysstat-collect.timer.
Editar /etc/cron.d/sysstat solo tiene efecto en máquinas sin systemd. En Debian y Ubuntu con systemd la tarea de cron sigue ahí, pero sale sin recoger nada; en RHEL 8 y 9 la propia Red Hat indica que se usan temporizadores en lugar de cron.
Retención, compresión y colectores opcionales
Tres variables del fichero de configuración marcan el comportamiento. HISTORY fija los días que se conservan. Si supera 28, sa1 y sa2 pasan a nombrar los ficheros como saAAAAMMDD (por ejemplo, sa20261110) para que el día 5 de un mes no pise al del mes anterior, algo a tener en cuenta en los scripts que buscan sa05. COMPRESSAFTER comprime los ficheros más antiguos que ese número de días, pero solo actúa si es menor que HISTORY: con los valores por defecto (7 y 10 en Ubuntu, 28 y 31 en RHEL) los ficheros se borran antes de llegar a comprimirse.
HISTORY=35
COMPRESSAFTER=7
SADC_OPTIONS="-S DISK,SNMP"Lenguaje del código: JavaScript (javascript)SADC_OPTIONS decide qué actividades opcionales se recogen. La opción -S DISK sigue siendo necesaria en sysstat 12.6: en la prueba, un fichero generado sin ella devolvió «Requested activities not available» al pedir sar -d. Debian, Ubuntu y RHEL la incluyen por defecto. Las estadísticas de TCP (-n TCP y -n ETCP) dependen de -S SNMP, que no viene activada, y XALL añade además particiones, sistemas de ficheros, interrupciones y energía a costa de ficheros más grandes. El manual de sadc advierte de que, si el fichero del día ya existe, mandan las actividades que ya contiene, así que un cambio en SADC_OPTIONS se nota a partir del fichero siguiente.
Qué informes mirar y cómo reconstruir un incidente
Sin argumentos de fichero, sar lee el del día. Con -f /var/log/sysstat/sa04 se consulta otro día, y con un intervalo y un número de muestras (sar 1 5) funciona en tiempo real, sin tocar el histórico.
CPU y carga
sar -u muestra el reparto de la CPU: %user, %system, %iowait, %steal e %idle. sar -P ALL lo desglosa por núcleo, útil cuando un proceso de un solo hilo satura una CPU mientras la media parece tranquila. En máquinas virtuales (VM), %steal mide el tiempo que la CPU virtual espera mientras el hipervisor atiende a otra; valores sostenidos indican que el problema está en el anfitrión y no dentro del sistema.
sar -q ofrece runq-sz (tareas esperando CPU), plist-sz, las tres medias de carga y blocked, el número de tareas bloqueadas esperando entrada/salida (I/O). En sysstat 12.6, sar -q CPU, sar -q IO y sar -q MEM añaden la información de presión (PSI) del kernel, que mide el porcentaje de tiempo en que las tareas se retrasan por falta de cada recurso.
Memoria, swap y paginación
En sar -r la columna que importa es kbavail, la estimación de memoria disponible para nuevas aplicaciones sin recurrir a swap. kbmemfree suele ser bajo en un servidor sano porque Linux usa la RAM libre como caché. %commit compara la memoria comprometida con RAM más swap y puede superar el 100 %, y kbdirty muestra datos pendientes de escribirse a disco.
sar -S informa del uso de swap y sar -W, de las páginas que entran y salen por segundo, que es lo que realmente frena. sar -B completa el cuadro: pgscank/s son páginas escaneadas por kswapd en segundo plano y pgscand/s, las que el kernel escanea de forma directa cuando un proceso pide memoria y no la hay. %vmeff divide lo recuperado entre lo escaneado; el manual considera que por debajo del 30 % la memoria virtual tiene dificultades.
Disco, red, procesos y tablas del kernel
sar -d (mejor con -p para ver nombres como nvme0n1 en lugar de dev259-0) da tps, await en milisegundos y %util. Este último tiene trampa: el manual recuerda que en dispositivos que atienden peticiones en paralelo, como cabinas RAID o SSD modernos, un 100 % no significa saturación. await creciente suele ser mejor pista.
En red, sar -n DEV muestra tráfico por interfaz, -n EDEV errores y descartes, -n SOCK sockets abiertos y conexiones en TIME_WAIT, y -n TCP y -n ETCP conexiones activas, pasivas y retransmisiones si se recoge SNMP. sar -w cuenta procesos creados y cambios de contexto por segundo, y sar -v enseña file-nr, los descriptores abiertos en todo el sistema, que se comparan con /proc/sys/fs/file-max.
Volcar la ventana del incidente
Antes de filtrar con awk conviene fijar la configuración regional. Con en_US, sar escribe la hora como «07:42:23 PM», lo que añade una columna; con es_ES usa coma decimal («0,15»), y awk deja de comparar bien los números. LC_ALL=C resuelve los dos casos, mejor que solo LC_TIME=C.
# Momentos con menos de un 20 % de CPU libre
LC_ALL=C sar -u -f /var/log/sysstat/sa04 |
awk '$1 ~ /^[0-9]+:/ && $NF ~ /^[0-9.]+$/ && $NF < 20 {print $1, "idle=" $NF, "iowait=" $(NF-2)}'
# Varios informes de la misma ventana en un fichero
F=/var/log/sysstat/sa04
for o in "-u" "-q" "-r" "-B" "-dp" "-n DEV"; do
echo "== sar $o"
LC_ALL=C sar $o -s 03:00:00 -e 03:30:00 -f "$F"
done > incidente-sa04.txtLenguaje del código: PHP (php)Las opciones -s y -e acotan el horario en formato de 24 horas. sar muestra las horas en la zona horaria de quien lo ejecuta; si el fichero viene de un servidor en otra zona, -t las presenta en la hora local original de esa máquina.
Exportar con sadf
sadf -d produce texto separado por punto y coma, fácil de convertir a CSV (valores separados por comas) o de cargar en una base de datos; sadf -j genera JSON (JavaScript Object Notation) y sadf -g, gráficos SVG (Scalable Vector Graphics) que se abren en el navegador. Ojo con la hora: sadf usa UTC por defecto y solo con -t respeta la hora local del servidor.
sadf -d -t /var/log/sysstat/sa04 -- -u -r > cpu-mem.csv
sadf -j /var/log/sysstat/sa04 -- -q > carga.json
sadf -g /var/log/sysstat/sa04 -- -d -p > discos.svgLenguaje del código: JavaScript (javascript)Síntoma, comando y qué mirar
| Síntoma | Comando | Qué mirar |
|---|---|---|
| CPU ocupada | sar -u, sar -P ALL, sar -q | %user o %system altos, runq-sz por encima del número de CPU |
| CPU ociosa pero el sistema va lento | sar -u, sar -q, sar -d -p | %iowait, blocked, await y aqu-sz del disco |
| Memoria ajustada | sar -r, sar -W, sar -B | kbavail bajando, pswpin/s y pswpout/s, pgscand/s, %vmeff |
| Timeouts remotos | sar -n EDEV, sar -n ETCP, sar -n SOCK | rxdrop/s, retrans/s, tcp-tw |
| Lentitud en una VM | sar -u, sar -P ALL | %steal sostenido |
| «Too many open files» | sar -v | file-nr frente a file-max; revisar también el límite del proceso |
| Carga súbita | sar -q, sar -w | ldavg-1, proc/s y cswch/s |
Un matiz sobre «Too many open files»: el error suele venir del límite por proceso (ulimit -n o LimitNOFILE en la unidad de systemd), que sar no ve. file-nr solo detecta el agotamiento global, así que conviene revisar también /proc/<PID>/limits. Para el diagnóstico en vivo, sar encaja bien con vmstat, el primer comando ante un servidor lento, y con las seis señales para localizar el cuello de botella en un servidor Linux.
Cuándo sar se queda corto
sar trabaja máquina a máquina, no envía alertas y guarda los datos en el propio servidor, de modo que si el disco se llena o la máquina desaparece, el histórico se va con ella. Tampoco sabe nada de aplicaciones: no mide latencia de peticiones HTTP, colas de mensajería ni consultas lentas.
Cuando hay decenas de servidores, hace falta correlacionar datos o se necesitan avisos, conviene sumar otra capa. Prometheus con node_exporter recoge métricas parecidas en un servidor central, las cruza con métricas de aplicación y se combina con Alertmanager y Grafana. Netdata ofrece paneles por segundo con muy poca configuración inicial. Zabbix cubre inventario, plantillas y alertas en entornos heterogéneos, con agentes o sin ellos. Ninguna invalida a sar, que puede seguir activo como respaldo local barato y como segunda opinión cuando el sistema central también sufrió durante el incidente.
Preguntas frecuentes
¿Dónde guarda sar sus datos en Ubuntu y en RHEL?
En Debian y Ubuntu, en /var/log/sysstat/saDD; en RHEL y derivadas, en /var/log/sa/saDD. Si HISTORY supera 28 días, los ficheros pasan a llamarse saAAAAMMDD.
¿Cómo se cambia el intervalo de recogida de sar a un minuto?
En sistemas con systemd se edita el temporizador con systemctl edit sysstat-collect.timer, se vacía OnCalendar= y se añade OnCalendar=*:*:00. Editar el cron solo sirve en máquinas sin systemd.
¿Por qué sar -d o sar -n TCP dicen que no hay datos?
Porque esas actividades son opcionales. El disco necesita -S DISK y TCP necesita -S SNMP en SADC_OPTIONS, y el cambio se aplica a partir del siguiente fichero diario.
¿Puede sar sustituir a Prometheus, Netdata o Zabbix?
No del todo. sar sirve para el análisis posterior en cada servidor, pero no centraliza datos ni envía alertas; lo habitual es usarlo como complemento.
Fuentes:
- bektiaw, «sar: The Flight Recorder Already Running on Your Server», Medium, 05/11/2026.
- Manual de sar (sysstat 12.6, Ubuntu 24.04)
- Manual de sadc (sysstat 12.6, Ubuntu 24.04)
- Manual de sadf (sysstat 12.6, Ubuntu 24.04)
- Proyecto sysstat: características
- Repositorio de sysstat en GitHub
- Red Hat: How to use SAR to monitor system performance in RHEL
- Paquete sysstat de RHEL 9 (spec de CentOS Stream 9 en AlmaLinux)
