Ir al contenido 
sar sysstat Me proporciona métricas históricas de servidores Linux, con las que puedo realizar un seguimiento preciso de los patrones de carga, los cuellos de botella y los comportamientos anómalos a lo largo del tiempo. De este modo, analizo retrospectivamente la CPU, la RAM, las E/S y la red, y detecto picos recurrentes que una herramienta que solo funciona en tiempo real podría pasar por alto fácilmente.
Puntos centrales
A continuación resumo de forma breve y clara las ideas principales.
- Historia En lugar de una instantánea: el registro periódico permite visualizar los patrones de carga.
- Combinación De la recopilación y el análisis: sysstat recopila los datos y sar los procesa.
- Anchura Métricas: CPU, RAM, espacio de intercambio, E/S de disco, red y otras.
- Diagnóstico Causas: ajustar y comparar de forma específica los intervalos de tiempo.
- Planificación Teniendo en cuenta las tendencias: dimensionar las capacidades de forma realista.
¿Para qué sirven sar y sysstat en el día a día?
Utilizo sar como System Activity Reporter, que permite leer los datos almacenados por sysstat. sysstat recopila periódicamente valores de CPU, memoria, E/S y red, mientras que con sar obtengo informes específicos para intervalos de tiempo concretos. De este modo, puedo detectar sin tener que hacer conjeturas los picos de carga recurrentes debidos a copias de seguridad, tareas de cron o picos de tráfico. A diferencia de Herramientas en directo A diferencia de top o htop, no evalúo el estado momentáneo, sino que tengo en cuenta la evolución a lo largo del tiempo. Esta perspectiva evita los diagnósticos erróneos, ya que separa la causa de la consecuencia y me proporciona indicios fiables.
Instalación y activación en las distribuciones más habituales
Instalo sysstat A través del gestor de paquetes, activa el registro y comprueba los temporizadores de systemd. En Debian/Ubuntu suele bastar con apt install sysstat y echar un vistazo a /etc/default/sysstatseguido de systemctl enable --now sysstat. En RHEL, CentOS y Oracle Linux utilizo dnf install sysstat y controla los temporizadores a través de systemctl. A continuación, los archivos diarios suelen guardarse en /var/log/sa/ con nombres como sa10 para el día 10 del mes. Verifico el registro con sar sin parámetros o con sar -u 1 3 para una breve comprobación improvisada.
Explicación de las órdenes SAR más importantes
Para la CPU utilizo sar -u y, si es necesario, por núcleo sar -u -P ALLcon el fin de Consejos No pasa desapercibido. En cuanto a la memoria y el almacenamiento en caché, lo considero con sar -r y el intercambio con sar -S. La actividad de la placa la leo con sar -d, la red con sar -n DEV,ETCP,TCP,UDP. Abro los archivos históricos con sar -f /var/log/sa/sa10 y delimitar un intervalo de tiempo con -s HH:MM -e HH:MM uno. Para los análisis detallados sobre los tiempos de espera, añado «sar» mediante Analizar las esperas de E/S, porque así puedo evaluar mejor las colas y el rendimiento, y Cuellos de botella identifico con claridad.
Cómo interpretar correctamente los valores de medición: CPU, memoria, E/S, red
Me fijo en unos pocos indicadores que me ofrecen rápidamente una visión fiable y que comparo a lo largo del tiempo. CPU-Ocioso Un valor cercano a 0 y un %iowait elevado indican la presencia de colas en el disco. Un valor elevado de %steal revela una escasez de recursos de la CPU en la virtualización. En cuanto a la RAM, presto atención a las páginas de memoria libres, al comportamiento de la caché de páginas y a las entradas y salidas del swap. En cuanto a la red, los errores de paquetes, las pérdidas y las retransmisiones ayudan a detectar límites de capacidad o interferencias.
| Métricas | interruptor SAR | Valores anómalos | medida inmediata |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle muy bajo, %iowait alto | Comprobar las E/S, distribuir los subprocesos, validar los requisitos de CPU |
| Memoria | sar -r | poca memoria libre, gran pérdida de caché de página | Optimizar los servicios, ampliar la memoria RAM, evaluar el almacenamiento en caché |
| Intercambiar | sar -S | Cambios frecuentes de entrada y salida | Aliviar la carga de la memoria RAM, ajustar los límites |
| Disco E/S | sar -d | Valores elevados de «await» y «svctm», la cola crece | Comprobar el perfil de E/S, ajustar la organización por niveles de almacenamiento o las ventanas de procesamiento por lotes |
| Red | sar -n DEV,ETCP | Pérdidas, errores, retransmisiones | Probar MTU y la descarga de tráfico; analizar el ancho de banda y la latencia |
Analizar datos históricos y intervalos de tiempo
Casi siempre trabajo con Ventanas de tiempo, por ejemplo sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 para los trabajos nocturnos. Así comparo franjas horarias idénticas en días diferentes y detecto tendencias en lugar de casos aislados. Para el análisis automático, guardo los datos con sadf -d en formato CSV y los subo a mi propio panel de control. Ante picos inusuales, analizo los intervalos adyacentes para descartar efectos secundarios. Mantengo este método sencillo porque me proporciona información útil rápidamente, sin necesidad de un largo trabajo previo.
Análisis de tendencias y planificación de la capacidad
Utilizo los valores archivados para Previsiones y dimensiono los recursos basándome en datos reales, en lugar de en corazonadas. Si la carga de la CPU aumenta semana tras semana, preveo núcleos o reservas de frecuencia. Si la demanda de memoria aumenta debido a las cachés, sopeso entre el beneficio y la ampliación de la RAM. Si la ruta de E/S muestra tiempos de espera cada vez mayores, opto por un almacenamiento más rápido o por ventanas de procesamiento por lotes desacopladas. Para la visualización, integro los datos alternativamente en Grafana y Prometheus y combina las tendencias de SAR con las métricas de los exportadores.
Caso práctico: servidor web con picos de carga
Voy a describir un caso en el que las páginas de WordPress tardan en responder cada noche y Usuarios Notificar interrupciones. Con sar -u -s 18:00:00 -e 20:00:00 y sar -d Detecto picos de E/S simultáneos durante las copias de seguridad. Al mismo tiempo, se observa sar -n DEV un aumento del rendimiento de la red, lo que completa el panorama de la carga. La comprobación realizada al día siguiente, sin copia de seguridad, confirma esta tendencia. Reubico el trabajo, optimizo las consultas a la base de datos y reequilibro las cachés, con lo que desaparecen los picos vespertinos y los tiempos de respuesta vuelven a mantenerse constantes.
Consejos para la gestión, la rotación y la conservación de datos
Compruebo el Almacenamiento en /etc/sysconfig/sysstat o /etc/default/sysstat y configuro el periodo de retención según sea necesario. Para los hosts críticos, conservo los datos entre 30 y 90 días, con el fin de detectar efectos estacionales. El tamaño de los archivos se mantiene manejable siempre que los intervalos sean razonables y no se active una frecuencia excesiva en segundos. Traslado los archivos más antiguos a un directorio central o los guardo en un sencillo sistema de almacenamiento a largo plazo. De este modo, mantengo los datos disponibles sin sobrecargar el sistema ni ralentizar el análisis.
Integración con pilas de monitorización y registros
Yo defino «sar» como Datos brutos-Proveedor y lo combino con supervisión centralizada, análisis de registros y alertas. Una pila de APM o de registros me proporciona eventos, mientras que sar ordena cronológicamente los valores de la infraestructura. Para los hosts especialmente ruidosos, utilizo además pidstat y iostat, para asignar procesos y rutas de E/S. Además, me ayuda Contabilidad de procesos, identificar con precisión los procesos que consumen muchos recursos. Esta combinación de la perspectiva de eventos y la de métricas evita que tenga que actuar a ciegas y reduce considerablemente el tiempo que dedico a la resolución de errores.
Ajustar la configuración con precisión: intervalos, sa1/sa2 y temporizador
Puse el Intervalos de registro de tal forma que se adapten a la dinámica del sistema. Una frecuencia de un minuto es la opción estándar, aunque en el caso de hosts muy volátiles también puede ser conveniente una frecuencia de entre 10 y 30 segundos. La recopilación se encarga de sa1 (muestras frecuentes), el resumen diario sa2 (Informes diarios). En systemd, compruebo los temporizadores o servicios correspondientes y ajusto la frecuencia. En Debian/Ubuntu, suelo activar la recopilación de forma explícita con ENABLED="true" en /etc/default/sysstat. Documento los intervalos por entorno para que las comparaciones posteriores sean correctas y nadie saque conclusiones erróneas a partir de muestras de 5 segundos en comparación con los datos de 1 minuto.
Resumen de las opciones avanzadas de sar
Además de los clásicos, los botones adicionales me ayudan a... Vista completa: sar -b muestra el rendimiento de E/S por bloques de forma agregada, sar -B el comportamiento de paginación del núcleo y sar -W La actividad de swap en detalle. Con sar -q Veo la cola de espera (procesos que esperan a la CPU) y la evolución de la carga. sar -H proporciona datos de Hugepage, si procede. En el caso de los discos, utilizo, si es necesario, sar -d -p, para ver las particiones por separado. Soy cauteloso con svctm: Este valor puede resultar poco fiable en algunos núcleos modernos o ser igual a 0; prefiero considerar await (latencia de extremo a extremo) y avgqu-sz/aqu-sz (tamaño de la cola). Y cuando necesito hacerme una idea general rápida, me ofrece sar -A una visión general amplia, que luego voy concretando.
Cómo evaluar correctamente las máquinas virtuales y los contenedores
En Virtualizaciones Presto especial atención a %steal: unos valores elevados de «steal» indican que el hipervisor resta tiempo de CPU a la máquina virtual. Esto puede llevar fácilmente a valoraciones erróneas si solo analizo %idle. Por eso, establezco una correlación entre la carga de la CPU, el «steal» y la cola de ejecución (sar -q) conjuntamente. En entornos de contenedores, separo la vista del host y la de la carga de trabajo: sar supervisa el host, no los contenedores individuales. Si necesito detalles por servicio, lo complemento con pidstat (por proceso) y tengo en cuenta los límites de cgroups. Además, compruebo la escalabilidad de la frecuencia de la CPU y los estados de consumo energético (cambios de frecuencia), ya que pueden provocar latencias a corto plazo que, fuera de contexto, parecen una escasez de CPU.
Referencia temporal: husos horarios, horario de verano y correlación fiable
Presto atención a base de tiempo constante, para que las comparaciones sean correctas. Por defecto, sar guarda los datos en hora local; en el caso de los clústeres, conviene utilizar una zona horaria uniforme (a menudo UTC). En torno al cambio de hora de verano, compruebo si hay intervalos de tiempo duplicados o que falten y, si es necesario, utilizo la salida de sadf con marcas de tiempo en formato ISO. Para establecer correlaciones con registros o eventos de APM, ajusto las zonas horarias con el fin de relacionar con exactitud los picos en las métricas con los eventos (implementaciones, copias de seguridad, tareas programadas). Unas referencias temporales claras reducen considerablemente los malentendidos en los análisis posteriores a las incidencias.
Automatizar y exportar con sadf
Para los informes y los paneles de control, exporto los datos con sadf. En mi día a día utilizo sadf -d (CSV) para análisis sencillos; como alternativa, sadf -j (JSON) para flujos de trabajo flexibles. Una exportación típica tiene este aspecto: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_abend.csv. Así es como genero un archivo con los indicadores de CPU, RAM, E/S de bloques y red correspondientes a un intervalo horario vespertino. En los scripts, utilizo estos datos para comparar automáticamente los días de la semana, calcular la mediana y el percentil 95, y señalar los valores atípicos. Mantengo deliberadamente reducido el número de métricas para preservar la legibilidad y evitar falsas alarmas.
Caso práctico: servidor de base de datos con presión en la caché de páginas
Un servidor MySQL presenta retrasos esporádicos en las consultas. sar -r muestra una disminución de la caché de páginas por la noche, sar -S intercambios ocasionales. Al mismo tiempo, en sar -d el await-Tiempo, y sar -b indica un aumento en los flujos de escritura. La correlación con las rotaciones de los registros y una tarea ETL explica este patrón: las grandes oleadas de escritura secuencial desplazan la caché y empujan las lecturas de la base de datos hacia la E/S. Distribuyo los trabajos, aumento moderadamente la RAM y amplío de forma selectiva el búfer de la base de datos. A continuación, los valores de «await» y «swap» se mantienen estables, las latencias disminuyen y la caché de páginas mantiene de forma fiable los conjuntos más activos en la memoria.
Aspectos operativos: gastos generales, listas de dispositivos y filtros
Sostengo el Sobrecarga pequeño, seleccionando muestras de forma proporcional. Sysstat lee principalmente de /proc y escribe en binario; con intervalos de un minuto, apenas noto la carga. En hosts con un gran número de dispositivos o dispositivos de bloque de corta duración (por ejemplo, en instantáneas), filtro la salida de forma selectiva y evalúo solo las rutas relevantes. En el caso de dm-crypt, MD-RAID o dispositivos multipath, compruebo tanto el dispositivo lógico como —siempre que sea posible— el dispositivo subyacente, para identificar correctamente los cuellos de botella. Al hacerlo, documento los nombres de los dispositivos para que las comparaciones posteriores no fracasen debido a rutas renombradas.
Metodología: valores de referencia y días de comparación
Defino una por cada host Línea de base por franja horaria (por ejemplo, de 01:00 a 05:00 h: «Batch»; de 09:00 a 18:00 h: «Office»; de 18:00 a 22:00 h: «Peak»). Para cada franja, anoto los valores medianos típicos y los percentiles aceptables (por ejemplo, CPU-%idle, await, avgqu-sz, retransmisiones). Ante cualquier desviación, primero busco nuevos trabajos, implementaciones o patrones de tráfico; solo después me planteo ampliar la capacidad. Este orden metódico evita las decisiones precipitadas: a menudo, un pequeño cambio en la planificación o un ajuste de los límites resuelve más que una costosa ampliación del hardware. Para ello, sar me proporciona una base de datos fiable a lo largo de semanas y meses.
Límites y complementos útiles
No considero que sar sea un sustituto de Alerta, ya que, por defecto, no supervisa umbrales ni envía notificaciones. Las alertas en tiempo real deben gestionarse en sistemas específicos que reflejen reglas, escalaciones y flujos de trabajo de los equipos. También cubro métricas detalladas sobre aplicaciones, bases de datos o JVM mediante exportadores y trazas. sar destaca cuando quiero comparar los recursos del sistema a lo largo del tiempo y comprender los cuellos de botella en el funcionamiento. En resumen, lo utilizo de forma específica cuando se necesitan respuestas rápidas y repetibles a cuestiones relacionadas con la infraestructura.
Brevemente resumido
Utilizo sar y sysstat, para convertir los valores de medición en un historial claro de la carga del servidor. La combinación de una recopilación periódica y un análisis retrospectivo específico permite identificar las causas, en lugar de limitarse a adivinar los síntomas. Con unos pocos comandos, detecto problemas de CPU, memoria, E/S y red, y los situo en el tiempo. A partir de ahí, tomo decisiones realistas sobre la capacidad y detecto rutinas ineficientes, como las copias de seguridad mal programadas. Quien se encargue de servidores Linux obtendrá con este método una orientación fiable y ahorrará tiempo en el análisis, la planificación y el funcionamiento.
