Linux procfs para administradores: resumen de los archivos más importantes

El Linux procfs Muestra el estado actual del núcleo a través de archivos virtuales en /proc. Para la administración, son especialmente relevantes la carga, la memoria, los procesos, los descriptores de archivos y los dispositivos de bloque. Es fundamental saber interpretar los datos: algunos valores son instantáneas, otros son contadores desde el arranque o medias móviles. Por lo tanto, nunca te limites a leer un solo valor, sino compáralo con las señales correspondientes y el contexto del host, la máquina virtual o el contenedor.

Entender procfs: una vista virtual del núcleo en lugar de un almacenamiento de datos

El procfs Es un sistema de archivos virtual: las entradas de /proc representan estructuras de datos y estados del núcleo de Linux en ejecución. No se almacenan de forma permanente en un soporte de datos. Al leerlo, el núcleo genera la vista correspondiente a partir de su estado actual; tras un reinicio, por ejemplo, muchos contadores vuelven a empezar desde cero. Por ello, /proc es una interfaz para la observación y, en parte, para el control, pero no un lugar para archivos propios ni configuraciones persistentes.

En lo que respecta a la administración, hay que distinguir tres ámbitos. Los archivos de estado globales, como /proc/meminfo, /proc/stat o /proc/loadavg, proporcionan indicadores a nivel del núcleo. Los directorios con nombres numéricos, como /proc/1234, ofrecen detalles sobre un proceso concreto. En /proc/sys, por el contrario, se encuentran los parámetros del núcleo, que, en función de los permisos y del parámetro en cuestión, pueden ser tanto de lectura como de escritura. La similitud en el formato de los archivos no debe llevar a pensar erróneamente que la consulta del estado y la modificación de la configuración tienen consecuencias fundamentalmente diferentes.

Las rutas y los campos disponibles no son los mismos en todos los sistemas Linux. La versión y la configuración del núcleo, la arquitectura, el hardware detectado y los módulos cargados influyen en las entradas visibles. Los espacios de nombres también modifican algunas vistas. Un procfs vinculado a un espacio de nombres de PID limita, en particular, la vista de procesos y PID; sin embargo, esto no implica que los archivos globales muestren automáticamente valores específicos de contenedores o cgroups. Los scripts deberían comprobar los archivos y campos antes de evaluar su contenido, en lugar de dar por sentada una estructura procfs completa e idéntica en todos los casos.

Hay que diferenciarlo de sysfs, que se encuentra en /sys: este representa principalmente dispositivos, controladores y objetos de hardware. Además, cgroup2 es relevante para la distribución de recursos y los límites de los grupos. No obstante, procfs sigue siendo la fuente directa de muchos estados del núcleo y de los procesos, necesarios para un primer diagnóstico.

Interpretar correctamente las cifras, los datos puntuales y la visibilidad

En el caso de procfs, el valor por sí solo rara vez explica un problema. En primer lugar, hay que aclarar su referencia temporal: algunos datos son contadores acumulativos desde el inicio del sistema; otros describen un estado actual; y otros representan intervalos de tiempo móviles. Un valor elevado del contador solo indica, en un primer momento, que se ha acumulado un evento desde el arranque del sistema. Una tasa solo se obtiene a partir de dos puntos de medición: la diferencia entre los valores dividida por el intervalo de tiempo transcurrido entre ellos. Esto se aplica, por ejemplo, a muchos contadores de CPU, de interrupciones y de soportes de datos.

El archivo /proc/uptime proporciona el tiempo de funcionamiento transcurrido y el tiempo de inactividad acumulado. Ayuda a situar cronológicamente los contadores desde el inicio, pero no sustituye a una serie de mediciones. Una consulta puntual es una instantánea; para obtener conclusiones fiables sobre tendencias, picos o cargas recurrentes, se necesitan consultas repetidas con marca de tiempo. Además, los valores pueden variar incluso mientras se leen, ya que el kernel sigue funcionando.

Los datos visibles también tienen sus limitaciones. /proc/self siempre hace referencia al proceso que está resolviendo la ruta en ese momento. Esto lo hace muy útil para scripts y comprobaciones interactivas, sin necesidad de asumir un PID. Sin embargo, el acceso a los directorios de procesos ajenos puede verse restringido por los permisos de los archivos, las capacidades de Linux y la opción de montaje de procfs hidepid puede verse limitado. En este caso, la falta de visibilidad no se debe a un fallo de procfs, sino a una medida de protección contra la lectura de información sensible del proceso.

Hay que tener especial cuidado en los contenedores. Un procfs vinculado a un espacio de nombres PID solo muestra, en las rutas relacionadas con procesos, los procesos de esa vista del espacio de nombres. Por el contrario, los archivos globales del núcleo, como /proc/meminfo, /proc/stat o /proc/diskstats, pueden seguir reflejando valores del host y no se limitan automáticamente al límite del contenedor. Por lo tanto, antes de cualquier diagnóstico hay que aclarar si la cuestión se refiere a los procesos, a los valores globales del núcleo o a los recursos realmente asignados; los límites y el uso de un contenedor deben incluirse además en el análisis de cgroup2.

Leer, configurar y proteger en /proc/sys

El ámbito /proc/sys Es la vista del sistema de archivos de la interfaz sysctl. La lectura de un valor tiene fines de diagnóstico. Por el contrario, el acceso de escritura modifica inmediatamente el comportamiento del núcleo en ejecución y puede afectar a los servicios, al consumo de recursos o a las características de seguridad. El hecho de que un cambio surta efecto sin necesidad de reiniciar no significa que esté exento de riesgos ni que sea automáticamente permanente: la persistencia depende de la configuración del sistema seleccionada.

La estructura de directorios facilita la orientación inicial. En /proc/sys/fs se encuentran, entre otros, los parámetros globales del sistema de archivos y de los identificadores de archivo. /proc/sys/vm agrupa los ajustes de gestión de la memoria, mientras que /proc/sys/net contiene parámetros relacionados con la red. Los subdirectorios y claves disponibles dependen, a su vez, de la configuración del núcleo y de las funciones del sistema. Por lo tanto, un parámetro existente no constituye una receta general de ajuste; lo determinante es su documentación y la carga de trabajo concreta.

Un contraejemplo de lo que parece una optimización es drop_caches en /proc/sys/vm. La documentación del núcleo clasifica esta función como «depuración y pruebas» y desaconseja su uso fuera de esos fines, ya que vaciar las cachés reutilizables puede reducir el rendimiento. La escasez de memoria libre no es, por sí sola, motivo para descartar las cachés: el núcleo utiliza deliberadamente la RAM también para la caché de archivos.

Antes de realizar cualquier cambio, debe existir una causa justificada. First, registra el valor inicial, documenta el objetivo y los efectos secundarios previstos, realiza el cambio de forma controlada y, a continuación, observa los valores de medición pertinentes y el comportamiento del servicio. Planifica de antemano el proceso de reversión y no incorpores un valor a una configuración permanente hasta que haya sido sometido a una revisión técnica. El artículo trata otros aspectos fundamentales sobre los parámetros y su gestión controlada. Ajuste del núcleo en el alojamiento Linux: los parámetros Sysctl de un vistazo.

Los archivos procfs más importantes según la tarea de administración

La selección de un archivo procfs debe partir de una cuestión de administración, no de la búsqueda de una lista de directorios lo más completa posible. Los archivos globales suelen proporcionar valores para todo el núcleo, las rutas de los procesos describen un único proceso visible y las entradas en /proc/sys/fs proporcionan la configuración y los límites a nivel del sistema. Algunos valores corresponden a estados actuales, mientras que otros son contadores acumulados desde el arranque o medias móviles. Esta distinción determina si basta con una sola lectura o si se necesitan dos puntos de medición.

La tabla es una guía de partida, no una cadena de diagnóstico. Un valor anómalo siempre requiere una verificación independiente: «load» con datos de CPU y E/S, valores de memoria con «Pressure Stall Information» y parámetros de proceso con el comportamiento del servicio. En particular, /proc/diskstats y /proc/stat son contadores acumulativos; su diferencia a lo largo de un intervalo conocido es más reveladora para las tasas que el valor absoluto. En los contenedores, además, hay que comprobar si un archivo proporciona valores globales del núcleo o una visión específica por cgroup. Por ello, en las siguientes secciones se clasifican las señales según la carga, la memoria, los procesos y las E/S.

Carga, CPU y memoria: evaluación combinada de las señales

Si el sistema va lento, /proc/loadavg es un buen punto de partida, pero no un indicador definitivo del rendimiento de la CPU. Los tres valores representan la carga media de los últimos 1, 5 y 15 minutos. En la carga no solo se incluyen las unidades listas para ejecutarse en el estado R, sino también las tareas en el estado de espera no interrumpible D, por ejemplo, en operaciones de E/S. El cuarto campo muestra las unidades de programación actualmente ejecutables frente al total de unidades existentes. Un valor elevado Promedio de carga Por lo tanto, puede indicar una situación de competencia por la CPU, accesos de E/S bloqueados o ambas cosas.

cat /proc/loadavg
grep -E '^(cpu|intr|ctxt|processes)' /proc/stat
cat /proc/meminfo
cat /proc/pressure/memory

Las líneas de la CPU en /proc/stat contienen los porcentajes de tiempo transcurrido desde el inicio del sistema en USER_HZ. Para determinar los porcentajes de carga a partir de estos datos, es necesario comparar dos lecturas; una sola lectura solo muestra el tiempo acumulado. El valor iowait no es, por tanto, una medida directa de la latencia del almacenamiento: su cálculo tiene limitaciones documentadas y, en determinadas circunstancias, puede incluso disminuir. Por ello, para determinar si la causa está relacionada con las E/S, resulta útil consultar además los valores de los dispositivos y el I/O-PSI.

Un valor bajo en «MemFree» tampoco indica necesariamente que haya escasez de RAM. Linux utiliza la memoria no utilizada de forma específica para la caché. «MemAvailable» estima cuánta memoria pueden recibir previsiblemente las nuevas aplicaciones sin necesidad de swapping, y suele ser más útil para una primera valoración. Solo cuando MemAvailable se agota y, al mismo tiempo, se producen atascos de memoria, se refuerza el indicio de presión de almacenamiento. Sin embargo, en un contenedor, estos valores de memoria globales pueden proceder del host; en el caso de los recursos garantizados o limitados, la vista de cgroup2 es también determinante.

Los archivos de /proc/pressure complementan esta visión. En el caso de «memory» e «io», «some» significa que al menos algunas tareas se quedaron bloqueadas durante una parte del intervalo de tiempo; «full» indica un estado en el que todas las tareas que no estaban inactivas se bloquearon simultáneamente. Los valores «avg10», «avg60» y «avg300» se refieren a 10, 60 y 300 segundos, respectivamente, mientras que «total» es un contador acumulado de bloqueos. En el caso de la CPU, «full» a nivel de sistema no está definido semánticamente y, desde Linux 5.13, se muestra como «null» por motivos de compatibilidad; por lo tanto, no debe interpretarse como un valor de diagnóstico a nivel de sistema. Los PSI de CPU, memoria y E/S responden a preguntas diferentes y no deben intercambiarse entre sí.

Si un servicio responde con lentitud cuando el MemFree es bajo, comprueba primero el MemAvailable y /proc/pressure/memory. Si ambos valores son normales, esto descarta una presión aguda de memoria en todo el sistema. A continuación, /proc//status puede indicar si el proceso en cuestión presenta, por ejemplo, un valor elevado de VmRSS, muchos subprocesos o un estado anómalo. Esta combinación permite distinguir entre un uso de memoria normal, aunque con una carga elevada en la caché, y un problema que requiere un análisis más detallado del proceso.

Analizar procesos, descriptores de archivos y E/S de dispositivos de almacenamiento

Para realizar un ejercicio seguro con un proceso cuya existencia está garantizada, $$ representa el PID del shell actual. El archivo «status» es más fácil de leer que el archivo «stat», orientado a campos. «Name» identifica el proceso, «State» su estado, «PPid» el proceso padre y «Threads» el número de subprocesos. «VmRSS» es una aproximación rápida a la memoria residente, cuyo registro RSS es escalable y asíncrono, por lo que puede resultar impreciso; «VmSize», por su parte, describe el espacio de direcciones virtuales. FDSize describe el tamaño de la tabla de descriptores, no necesariamente el número de entradas actualmente abiertas. Los cambios de contexto voluntarios e involuntarios pueden ayudar a clasificar el comportamiento de la programación, pero por sí solos no constituyen una prueba de error.

cat /proc/$$/status
ls -l /proc/$$/fd

El directorio fd contiene enlaces simbólicos a archivos abiertos, tuberías, dispositivos o sockets. Sirve, por ejemplo, para localizar un proceso que sigue manteniendo abierto un archivo de registro que ya se ha eliminado. Sin embargo, es de esperar que haya un gran número de descriptores de archivo abiertos en proxies, bases de datos o servidores orientados a eventos. Para obtener vistas filtradas y la asignación entre procesos, se utiliza Utilizar lsof para analizar archivos abiertos Un complemento adecuado. Las líneas de comando de «cmdline» pueden revelar argumentos confidenciales; «environ» es aún más delicado debido a la posibilidad de que contenga datos de acceso o tokens, por lo que no debe consultarse de forma rutinaria.

maps muestra una lista de áreas de memoria virtual con permisos, desplazamiento, dispositivo, inodo y, en su caso, ruta. smaps añade valores de memoria detallados para cada asignación y ofrece una instantánea más precisa que la información de RSS, aunque también más laboriosa. Ambos archivos están pensados para análisis de memoria en profundidad: su salida puede ser voluminosa, y la interpretación de cada asignación requiere contexto. Para una primera visión general, «status» y los archivos de memoria y PSI de todo el sistema suelen ser más eficaces.

Cuando la carga es elevada y la utilización de la CPU es baja, /proc/diskstats amplía el diagnóstico al nivel de los dispositivos. El archivo mantiene estadísticas acumulativas de E/S por dispositivo de bloque. Para evaluar la actividad en términos de tasa, es necesario comparar dos momentos distintos. Para ello, hay que distinguir claramente entre unidades físicas, particiones y dispositivos virtuales o de mapeo; no se deben sumar a ciegas los contadores de distintos niveles. Un descriptor de archivo abierto de un proceso no puede asignarse directamente a un contador de dispositivo de diskstats: entre ambos se interponen el sistema de archivos, la caché y las capas de mapeo. No obstante, junto con /proc/pressure/io, se puede comprobar si los atascos de E/S observables y la actividad del dispositivo coinciden en el tiempo.

procfs en funcionamiento: consultas, supervisión y protección de datos

Para realizar diagnósticos operativos repetibles, trata las consultas de procfs como puntos de medición: anota la marca de tiempo, el contexto del sistema y la consulta concreta. Muchos valores son contadores acumulados desde el inicio; solo la diferencia entre dos valores, dividida por el intervalo de tiempo, da como resultado una tasa. Esto se aplica, por ejemplo, a los contadores de /proc/diskstats. Por lo tanto, una consulta aislada puede demostrar que hay actividad, pero no permite cuantificar de forma fiable ni el rendimiento ni un deterioro duradero.

Un sistema de monitorización debería registrar, entre otras cosas, los valores almacenados a intervalos fijos de /proc/meminfo, valores de los dispositivos de /proc/diskstats, registrar los estados de los procesos y del sistema, así como las señales de impresión cuando el núcleo lo admita. Debe convertir los valores brutos a las unidades adecuadas, calcular las diferencias en el caso de los contadores y guardar los historiales. En los contenedores, no debe equiparar los valores globales de procfs con los límites de recursos de la carga de trabajo: las rutas de los procesos pueden estar limitadas al espacio de nombres del PID, mientras que los valores de memoria o de dispositivos pueden reflejar en parte los del host. Para los límites y la utilización de un grupo se necesitan métricas complementarias de cgroup2. Solo las tendencias temporales permiten establecer umbrales fiables: un valor elevado puede ser normal si se ajusta a la ventana de carga prevista; un aumento repentino con respecto a la propia línea de base suele ser más relevante. Las entradas procfs disponibles dependen del núcleo en ejecución y de su configuración.

Los archivos directos y las herramientas se complementan entre sí. ps, top o htop son adecuados para la visualización interactiva de procesos; free, vmstat, iostat, pidstat, ss y sar Dependiendo de la instalación, procesan datos para responder a preguntas concretas. procfs sigue siendo útil si quieres examinar directamente el código fuente del núcleo o crear un script pequeño y fácil de entender. Para las alertas y la planificación de la capacidad, los datos de series temporales suelen ser el nivel más adecuado.

Las restricciones de visibilidad también se aplican a las consultas de solo lectura. Los derechos de acceso, las opciones de montaje y los espacios de nombres de PID pueden ocultar datos de procesos o limitarlos a una vista del contenedor. Por el contrario, el hecho de disponer de un montaje propio de /proc no significa que cada archivo global del núcleo contenga únicamente datos del contenedor. Por lo tanto, la ausencia de una entrada de proceso o un valor global inesperadamente alto es, en un primer momento, un indicio de que hay que aclarar el entorno de ejecución, las opciones de montaje y el contexto del cgroup.

Vías de diagnóstico para servicios lentos y cuellos de botella en los recursos

La resolución de problemas comienza con un síntoma, no con un valor concreto que se supone que es el culpable. A continuación, comprueba al menos una señal independiente y anota si la observación afecta al host, a una máquina virtual o a un contenedor. De este modo, evitarás, por ejemplo, interpretar precipitadamente una carga elevada como un problema de CPU o un gran número de descriptores abiertos como una fuga. Las siguientes pautas constituyen un primer diagnóstico orientativo y no sustituyen a los registros específicos de la aplicación.

Si el promedio de carga es elevado, comprueba primero si son las tareas en ejecución o las tareas en espera las que están elevando esa cifra. Los datos de carga representan valores medios de uno, cinco y quince minutos, y tienen en cuenta tanto los estados R como los D. Por lo tanto, compara con precaución los campos de tiempo de CPU con la carga de E/S y la actividad de los dispositivos. En particular, iowait No debe interpretarse de forma aislada como latencia de memoria.

Si la aplicación va lenta y el valor de MemFree es bajo, MemAvailable el mejor valor de contexto inicial. Añade los datos PSI de memoria y el estado del proceso en cuestión, como su VmRSS, el número de subprocesos y su estado. PSI distingue, en lo que respecta a la memoria y las E/S, entre some para tareas parcialmente bloqueadas y full para el bloqueo completo de las tareas que no son de espera. Si faltan los archivos PSI, esto puede deberse a la configuración del núcleo o al entorno; no descarta la existencia de un cuello de botella.

Para el diagnóstico de archivos y procesos, se pueden conceder derechos y Espacios de nombres PID limitan su relevancia. En entornos contenidores, /proc suele describir únicamente el entorno de procesos asignado. Por lo tanto, si se deniega el acceso o los directorios están incompletos, comprueba los derechos de usuario, las opciones de montaje de procfs y el contexto del espacio de nombres antes de sacar una conclusión técnica a partir de la ausencia de datos.

Corregir los errores típicos y elegir las herramientas adecuadas

En la administración de Linux, hay cuatro errores comunes que suelen llevar a tomar medidas erróneas. Pocos MemFree No significa automáticamente que haya escasez de RAM, ya que el núcleo utiliza la memoria, entre otras cosas, como caché; para las nuevas aplicaciones, MemAvailable es la estimación más significativa. Una carga elevada no demuestra que la CPU esté saturada, ya que también se tienen en cuenta las tareas en espera ininterrumpida. Un porcentaje elevado de «iowait» no mide la latencia inmediata de un soporte de datos. Y «procfs» no es idéntico en todos los casos: la versión del núcleo, la configuración, el hardware, los módulos y los espacios de nombres influyen en los archivos y los campos.

Elige el método en función de la pregunta. Para un análisis puntual de las causas, ofrece procfs Datos brutos directos del núcleo en ejecución. Para obtener una visión general rápida y legible para el usuario, las herramientas especializadas de línea de comandos suelen ser más eficaces. Cuando lo que importa son las tendencias, las alertas o las decisiones sobre capacidad, necesitas un sistema de monitorización que ordene cronológicamente los puntos de medición, calcule las diferencias entre contadores y mantenga valores históricos de referencia. En caso de límites de recursos de servicios o contenedores individuales, un análisis a nivel de cgroup complementa la vista global del host; PSI también puede estar disponible por cgroup si se configura adecuadamente.

Se recomienda especial cautela en lo que respecta a /proc/sys. La lectura de un parámetro es una acción de diagnóstico, mientras que su modificación altera el comportamiento activo del núcleo. Solo se debe modificar un valor si se conoce la causa, se ha documentado el valor inicial, se pueden observar las consecuencias y se ha establecido un procedimiento para revertir el cambio. Los directorios fs, vm y net Clasifican los parámetros por temas, pero no ofrecen pautas universales de puesta a punto.

El ejemplo drop_caches muestra la diferencia entre una intervención y una optimización: la documentación del kernel describe la interfaz como no destructiva, pero advierte de posibles problemas de rendimiento y no la recomienda como medida operativa habitual fuera de los escenarios de prueba o depuración. Por lo tanto, una regla prudente es: primero medir, luego realizar un cambio justificado y limitado, observar los efectos y los efectos secundarios, y documentar la decisión.