Las herramientas de monitoreo son fundamentales, pero una pobre interpretación de los resultados, pueden llevar a conclusiones incorrectas. Incluso usando chatbots de IA, si hacemos preguntas deficientes podemos terminar girando en círculos o tardar más tiempo en resolver un problema. Lo mejor es reducir el nivel de especulación con hipótesis técnica. A continuación vemos unos ejemplos bien sencillos.

Power Tip #1

No todas las métricas que parecen similares describen el mismo fenómeno.

• Aplicación lenta.
• Load 15.
• CPU idle 50%.

Alguien descarta CPU porque “está libre”.

Pero:

• Load describe tareas en ejecución o esperando.
• CPU usage describe tiempo ocupado.
• CPU pressure describe tiempo en que las tareas no pudieron progresar.

Son fenómenos distintos.

Antes de interpretar, mirá comportamiento:

vmstat 1 5
mpstat 1

Y si necesitás otra capa:

cat /proc/pressure/cpu

Es importante saber que “Load no es necesariamente consumo de CPU”, sin embargo, más importante es entender qué está describiendo cada señal.

Interpretarlas como si hablaran de lo mismo es especulación con números.

Power Tip #2

Tomar una métrica aislada de memoria en Linux no implica entender como funciona

free -h

Las columnas están ahí. Pero entender qué representa cada una es otra cosa.

• used no significa “memoria en crisis”.
• buff/cache no significa “desperdicio”.
• available no significa “memoria libre inmediata”.

Antes de reaccionar ante un número alto, mirá dinámica:

vmstat 1 5

Linux administra memoria como recurso dinámico, no como espacio estático.

Leer columnas sin entender el modelo del kernel es especulación con formato tabular.

Power Tip #3

Reiniciar en muchas situaciones no hace otra cosa que restaurar un estado. No explica causas.

• El servicio falla.
• Se reinicia.
• Funciona.

Eso no es diagnóstico.

Antes de repetir el gesto automático:

journalctl -u servicio-problematico -n 50

Si no entendemos por qué se degradó, volverá a pasar.

Reiniciar elimina el síntoma. No valida la hipótesis. Las herramientas no están equivocadas.

La diferencia está en entender qué fenómeno describe cada señal. Está claro que en el mundo real, muchas veces determinar la causa del problema lleva más tiempo que usar un trigger que reinice un servicio. Algo que pasa muchas veces apps legacy (la falta de especialistas o la triste realidad de falta del código fuente). Sin embargo, el problema es cuando se usa esta metodologìa como primera opción...

Power Link

La IA terminará con las operaciones de IT. ¿En serio? Bueno, en realidad no, para sorpresa de tecno-optimistas o tecno-pesimistas, aquí hay un interesante análisis de Sebastián Martínez de SUSE sobre este tema: Why AI Still Cannot Run Your Linux Infrastructure (And What Must Change)

PSI (Pressure Stall Information) permite observar ese tipo de situaciones y, sobre todo, cambiar la forma en que interpretamos problemas de rendimiento y estabilidad en Linux. A partir de esa señal, el foco deja de estar en métricas globales y pasa a decisiones concretas: entender dónde ocurre el problema, a quién afecta y cómo intervenir sin arrastrar todo el sistema. Finalmente, el Power Link nos lleva a ver qué opina Gaël Duval, el creador de la distribución Mandrake, sobre uno de los hypes actuales.

Power Tip #1: ¿Cómo se ven afectadas mis aplicaciones por falta de recursos?

Existe a veces una creencia basado en pensamiento mágico: que el monitoreo depende solamente de la herramienta que se utilice. Pero más que la herramienta lo importante, es qué se mide y cómo interpretar esos resultados. Las métricas más conocidas: uso de cpu, load-average, uso de memoria, uso de I/O, etc. si bien son útiles pueden darnos en muchos casos un panorama parcial. Eso sucede porque están basados en los recursos, o en el scheduler.

Existen sin embargo desde hace varios años métricas que están más centradas en como las aplicaciones se ven impactadas por el uso de recursos. Con PSI (Pressure Stall Information) obtenemos un indicio del tiempo que las aplicaciones quedan detenidas porque el sistema no puede darles CPU, memoria o acceso a disco en el momento en que lo necesitan.

Esto está expuesto en el sistema de archivos:

PSI distingue entre situaciones donde al menos una tarea queda bloqueada (some) y escenarios donde todas las tareas relevantes compiten por el mismo recurso (full). Valores elevados y sostenidos en este full caso suelen indicar un problema estructural: no de picos puntuales, sino de diseño, aislamiento o priorización de workloads.

Vale hacer aquí tres aclaraciones:

1. Esta funcionalidad está presente a partir de la versión 4.20 del kernel (RHEL8 la trae como backport). En algunas distribuciones puede ser necesario habilitar PSI explícitamente en el arranque.
2. Esta no es la métrica definitiva, sin embargo ignorarla es perder el cuadro completo de lo que sucede tanto en el sistema como nuestras aplicaciones.
3. Versiones recientes del kernel incluyen también la medición de la presión sobre irq.

Power Tip #2: Las disrupciones se pueden atribuir a workloads específicos

Cuando el host empieza a perder capacidad de respuesta, no siempre el problema es global. Es común que el sistema siga siendo usable mientras algunos servicios o aplicaciones comienzan a degradarse, simplemente porque no acceden a los recursos cuando los necesitan. Esa degradación suele manifestarse como lentitud, mayor latencia o pérdida de capacidad de interacción.

En un Linux moderno, el kernel organiza los procesos bajo dominios de control definidos por cgroups. Esto permite observar de forma localizada qué tareas empiezan a quedarse esperando recursos, en lugar de razonar únicamente a partir de métricas agregadas del host.

En sistemas basados en systemd, ese dominio no es abstracto: se corresponde con services, slices o scopes. El mismo síntoma que aparece a nivel global puede observarse dentro de estos límites, lo que permite atribuir dónde se generan las esperas, incluso cuando el resto del sistema continúa funcionando con normalidad.

Pensar a nivel host diluye el diagnóstico. En cambio poner el foco en en services, scopes y slices permite relacionar directamente los síntomas percibidos —lentitud, tiempos de respuesta, degradación de rendimiento— con un grupo de procesos concreto.

Es decir, uno puede decir que el host muestra la presión acumulada, pero los cgroups permiten entender qué se queda atascado y frente qué recurso.

Power Tip #3: Abordar el problema de manera localizada

Cuando un servicio o aplicación empieza a tener tiempos muertos o a interferir con el resto, tenemos varias maneras de abordar el problema. Y no estamos hablando de las típicas acciones: reiniciarlo, moverlo o rediseñarlo.

Podemos tomar medidas más estructurales, por ejemplo, crear un slice de systemd, establecer límites y luego confinar esos servicios o procesos en esos slices.

Sin embargo, antes de intervenir de manera prematura, es conveniente tener en cuenta que Linux, en general ya tiene una agrupación de slices, scopes y servicios bastante razonable. En este punto entonces, ya sabemos que ese servicio problemático ya corre dentro de un perímetro definido.

En lugar de crear un nuevo slice, que tiene un carácter más permanente, podemos adoptar una solución más sencilla y gradualista. En systemd, los parámetros que gobiernan cómo compite por recursos no están fijos en scopes o servicios.

Un vistazo rápido alcanza para verlo (los siguientes son ejemplos para entender la idea):

systemctl show -p ControlGroup,CPUWeight,MemoryMax,IOWeight procesos-ruidosos.scope

Y tomar cartas en el asunto:

systemctl set-property procesos-ruidosos.scope …

Ese tipo de intervención es local, reversible y no convierte un incidente puntual en un cambio estructural.

Intervenir sobre una unidad existente permite corregir interferencias concretas sin rediseñar el sistema ni propagar el problema.

Fuentes y más recursos

Qué son los cgroups y para qué sirven

Power Link

Gaël Duval, creador de Mandrake, Murena y e/OS reflexiona sobre el impacto de la AI en el software open source: Why AI won’t “Kill Open Source”