Ir al contenido principal

Formateando salida de SAR

SAR es la herramienta por excelencia para el monitoreo de los sistemas operativos GNU/Linux. Cuenta con históricos, además de una gran cantidad de métricas relacionadas al desempeño de nuestro servidor, como cpu, memoria, I/O y red. Cada uno de estos hitos puede ser diseccionado con mayor granularidad, es decir, observar la parte que compone cada recurso.

Algunas veces es necesario realizar reportes de desempeño a otras áreas o incluso para efectos de conocimiento de patrones de utilización de cada servidor. Por desgracia, las formas de llevar a un modelo de visualización más amable es tarea un poco más complicada y no está incorporada por defecto con SAR. Existen herramientas ex profeso, sin embargo, tienen que ser utilizadas con cierta complejidad y algunas veces no producen el resultado deseado, como por ejemplo, gráficas de muy pobre visualización.

En lo personal me gusta graficar las métricas; son una manera muy simple de entender lo que sucede y enfocarnos en los momentos en el tiempo que así nos lo exigen. Aunado a eso, realizar ciertos agregados, como el cruzamiento de algunos datos.

Lo primero que hago es convertir en .csv la salida, añadiendo comas y retirando los promedios. Quiero que la visualización sean en las mismas escalas y con la misma validez.

Yo utilizo libre office Calc para esta tarea. Solo tengo que abrir el .csv con tal programa y puedo jugar con las gráficas según mis necesidades. El script que construí para 3 casos es casi identido, solo cambian las columnas que se visualizarán y las cadenas que vamos evitar incluir en la salida. 

Yo expreso los comandos por separado a efectos de su explicación y presentación. Ustedes pueden incluirlos dentro de un shell que realice todos los formateos que necesiten y los almacene en un archivo distinto en cada caso. 




CPU

for i in $(ls -lrth /var/log/sa/sa*); do sar -p -f /var/log/sa/sa$i 2>/dev/null | grep -v 'Average'| awk 'BEGIN {OFS=","} {print $1,$2,$3,$4,$5,$6,$7,$8,$9}' > coso$i;DDATE=$(grep -o '[0-9][0-9]/[0-9][0-9]/[0-9][0-9][0-9][0-9]' coso$i); cat coso$i | awk -v var="$DDATE" 'BEGIN {OFS=","} {print var,$0}'| grep -v 'Linux' | grep -v ',,,,,,,,,' | grep -v 'CPU'; done; rm -rf coso*;

Abierto con Calc podemos realizar una gráfica muy simple con casi todos los elementos que nos brinda. Yo quito las horas, debido a que pocas veces elaboro en ésta unidad. 



La gráfica de consumo de CPU muestra que apenas se ha utilizado éste. Aún tiene capacidad para computar muchas más cosas. 





Los casos de memoria, disco, TPS, etcétera, son análogos a la construcción anterior. En caso de ser muchos servidores, vale la pena buscar maximizar la automatización de ésta tarea, debido al trabajo manual que conlleva.


Memoria

for i in $(ls -lrth /var/log/sa/sa*); do sar -r -f /var/log/sa/sa$i 2>/dev/null | grep -v 'Average'| awk 'BEGIN {OFS=","} {print $1,$2,$3,$4,$5,$6,$7,$8,$9}' > coso$i;DDATE=$(grep -o '[0-9][0-9]/[0-9][0-9]/[0-9][0-9][0-9][0-9]' coso$i); cat coso$i | awk -v var="$DDATE" 'BEGIN {OFS=","} {print var,$0}'| grep -v 'Linux' | grep -v ',,,,,,,,,' | grep -v 'memused'; done; rm -rf coso*;

TPS

for i in $(ls -lrth /var/log/sa/sa*); do sar -b -f /var/log/sa/sa$i 2>/dev/null | grep -v 'Average'| awk 'BEGIN {OFS=","} {print $1,$2,$3,$4,$5,$6,$7}' > coso$i;DDATE=$(grep -o '[0-9][0-9]/[0-9][0-9]/[0-9][0-9][0-9][0-9]' coso$i); cat coso$i | awk -v var="$DDATE" 'BEGIN {OFS=","} {print var,$0}'| grep -v 'Linux' | grep -v ',,,' | grep -v 'tps'; done; rm -rf coso*;

Comentarios

Entradas populares de este blog

Ángulo de Corte

El armar un gallo de pulgada es una de las cosas más sujeta a mitos y medias verdades. Este es uno de los muchos temas que los galleros enuncian con una seguridad a prueba de balas.  Hasta el momento no he leído un solo escrito o esquema con detalle científico que tenga conclusiones claras y precisas de lo que sucede en un combate ni la ergonomía que mejor se adapta, todo proviene de un sistema de creencias que, muy en lo personal, me cuesta creer. El ángulo de corte se refiere a la posición de la punta de la navaja con respecto al codo de la pata. Dependiendo del amarrado es que la sitúa en un rango de los 5° a los 9°. De lo que no dudo es que no hay una manera precisa de emitir teorema alguno sobre este rubro. La formula del corte está dada por la sujeción de la navaja, la forma de la navaja, la altura de la botana, la posición de disparo del gallo, así como la calidad y aprendizaje del mismo durante el desarrollo de la pelea. Son muchas las variables, sin emba...

Análisis de conexiones TIME_WAIT

El tema de las conexiones mal utilizadas es un dolor de cabeza para muchos administradores de servidores de aplicaciones. Es común que las aplicaciones que mantenemos en nuestro resguardo sufran degradación, e incluso fallos, por el "simple" hecho de no cerrar las conexiones o tardar demasiado en hacerlo (vía sistema operativo). Como sabemos, una conexión pasa por varios estados, mismos que salen de la intención de este escrito. Las conexiones establecidas (ESTABLISHED) son demasiado costosas cuando abren y cierran, debido a eso, se han creado manejadores de conexiones (pooles) que mantienen abiertas las conexiones para reutilizarlas dependiendo la demanda. Es por eso, que en medida de lo posible, hay que utilizar un manejador de conexiones, ya sea a base de datos o algún broker. Entrando de lleno al tema, las conexiones en estado TIME_WAIT son un problema por el consumo de memoria, ocupando cada una 64k de memoria no paginable, es decir,  todo el tiempo se mantiene...

Significado de los dígitos de versión del kernel Linux

Algunas de las cosas que siempre quise saber, pero nunca me hice del tiempo para investigarlo es la función de los cuatro dígitos del kernel Linux. Su significado poco tiene que ver con hechos cabalísticos o confusos enunciados matemáticos. Mejor que en mis palabras están las de Tanenbaum: Los números de versión de Linux consiste en cuatro números, A.B.C.D, como 2.6.9.11. El primer número indica la versión del kernel. El segundo indica la revisión mayor. Antes del kernel 2.6 los números pares correspondían a versiones estables del kernel, mientras que los impares correspondían a versiones inestables que estaban en desarrollo. Después del kernel 2.6 los significados se manejaron de forma distinta. El tercer número corresponde a la revisión de versiones menores, como la aceptación de drivers. El cuarto número corresponde a las correcciones de errores menores o parches de seguridad.  Como ven, el señor Tanenbaum es sumamente lacónico con la explicación de los dígitos que compo...