Visualización de la supervisión de PSI en Linux con Grafana: cómo comprender y supervisar adecuadamente la carga sobre los recursos

Muestro cómo linux psi recopilar datos con Prometheus y visualizarlos en Grafana para medir la carga sobre los recursos de CPU, memoria y E/S como tiempo de espera real. Así puedo detectar Cuellos de botella Desde el principio, asígnalas a cgroups o contenedores y, si es necesario, activa medidas correctivas automatizadas.

Puntos centrales

• Métricas PSI: «some/full» para CPU, memoria, E/S y medias móviles
• Enfoque en los cgroups: Una visión específica de los contenedores y los servicios, en lugar de una visión meramente global
• Desencadenantes de alertas: Utilizar eventos en umbrales con poll/epoll
• Grafana: Paneles sobre tendencias, picos y las principales N causas
• Buenas prácticas: Umbrales, intervalos de tiempo, correlación con métricas del sistema

El PSI en pocas palabras: entender la presión como tiempo de espera real

PSI responde a la pregunta de cuánto Tiempo real Las tareas esperan en vano a la CPU, la RAM o la E/S. Los archivos en /proc/pressure/{cpu,memory,io,irq} ofrecen dos perspectivas: algunos muestra las fases en las que algunas tareas están en espera, completo indica los momentos en los que todas las tareas que no están inactivas se bloquean. Evalúo ambos valores por separado porque algunos aparece antes y completo pone de manifiesto los parones reales. Además, utilizo avg10, avg60 y avg300, para distinguir entre las oscilaciones a corto plazo y las tendencias a largo plazo. A través del creciente total-Me doy cuenta de lo mucho que se ha ido acumulando la presión desde la salida y dónde Puntos de acceso mentira.

PSI a nivel del sistema frente a PSI de cgroup: elegir el nivel adecuado

Distingo deliberadamente entre los valores de presión globales y la vista por cgroup. Los archivos que se encuentran en /proc/presión/ muestran el sistema en su conjunto, mientras que cgroup v2, además, cpu.pressure, memory.pressure y io.pressure por grupo. En entornos de contenedores, lo utilizo para organizar de forma ordenada los pods, los servicios o reciclaje de comida a. Esta asignación evita ir a ciegas: en lugar de tener que adivinar, veo directamente en el grupo cuál es la causa. En los servidores multitenant, separo así las cargas compartidas de las dedicadas y controlo Límites dirigido.

Comprobar los requisitos previos: activar el kernel, PSI y cgroup v2

Antes de recopilar métricas, me aseguro de que la plataforma sea la adecuada:

• Versión del núcleo: PSI está disponible a partir de Linux 4.20. Lo compruebo con uname -r y compruébalo a través de zcat /proc/config.gz | grep CONFIG_PSI, si la compatibilidad está integrada.
• Indicador de tiempo de ejecución de PSI: Algunas distribuciones permiten utilizar el parámetro de arranque opcional psi=1, para activar PSI por completo. Lo utilizo cuando es necesario y compruebo que /proc/pressure/* Proporciona contenidos.
• cgroup v2: Para la vista por servicio/contenedor, utilizo la jerarquía unificada. Lo compruebo con mount | grep cgroup2 y espero un cgroup2-Mount (a menudo /sys/fs/cgroup). Si no está presente, lo activo mediante el parámetro del kernel systemd.unified_cgroup_hierarchy=1 (Es necesario reiniciar el sistema).
• Autorizaciones: Los exportadores del servidor necesitan permisos de lectura en /proc/pressure/* y, en su caso, a /sys/fs/cgroup/*/*.pressure. En los contenedores, monto estas rutas en modo de solo lectura.

Aprovechar los desencadenantes PSI: reaccionar automáticamente en lugar de limitarse a observar

Además de las series temporales, también presento acontecimientos a través de encuesta o epoll introduciendo valores umbral y intervalos de tiempo en los archivos PSI. En cuanto la carga sobre el recurso supera el valor umbral establecido en el intervalo, se activa un evento y pongo en marcha las medidas correctivas. Esto puede consistir en un pod adicional, un vaciado de la caché o la limitación temporal de un Tareas por lotes ser. En las unidades de Systemd, vinculo esta reacción directamente a los servicios y mantengo bajas las latencias. De este modo, la monitorización se convierte en control, y no solo en Pantalla.

En la práctica, utilizo un programa «watcher» compacto que se encarga de los correspondientes *presión*-archivos, mediante write() un disparador (algunos o completo (incluidos el umbral y la ventana en µs) y, a continuación, con epoll espera de forma bloqueante a que se produzcan eventos. De este modo, ahorro ciclos de sondeo y reacciono de forma determinista. Mantengo las ventanas deliberadamente algo más largas (por ejemplo, entre 10 y 30 s) para filtrar los transitorios, y distingo según el recurso: memoria reacciona con mayor sensibilidad que io, CPU tiene que ser más claro para poder disparar.

Exportar PSI a Prometheus: agentes, métricas, etiquetas

Para las series temporales, recopilo datos de PSI mediante un exportador específico o integro los valores en agentes ya existentes, como el Exportador de nodos. Es fundamental utilizar etiquetas coherentes para el host, el cgroup y el contenedor, para que las consultas en Grafana se filtren correctamente. En Kubernetes utilizo además métricas de cAdvisor y Kubelet para *_presión_*_segundos_de_espera_total_, para que los niveles de nodo, pod y contenedor sigan coincidiendo. En el caso de los hosts clásicos, leo /proc/pressure/* directo y carpeta algunos y completo en nombres de métricas independientes. Una guía sobre la integración de agentes te ayudará a empezar, por ejemplo, en Configurar Node Exporter.

Variantes de Export en detalle: Node, cgroup y Kubernetes

Dependiendo del entorno, utilizo diferentes métodos:

• Exportador de nodos (Nivel de host): Activo el presión-Collector (si no está activo por defecto), p. ej., a través de --collector.pressure. Proporciona métricas como node_pressure_cpu_some_avg10, node_pressure_memory_full_avg60 y node_pressure_io_waiting_seconds_total{state="some|full"}. Estas últimas son adecuadas para rate()-Análisis y Top-N.
• Exportador propio de cgroup (Nivel de servicio/contenedor): Para obtener una visión detallada, consulto /sys/fs/cgroup//{cpu,memory,io}.pressure y genero métricas como cgroup_pressure_memory_waiting_seconds_total{state="full",cgroup="..."} y el avg10/60/300‑Gauges. Normalizo la ruta del cgroup como etiqueta (cgroup) o carpeta en servicio/contenedor Etiquetas.
• Kubernetes: A nivel de nodo, Prometheus recopila datos node‑exporter. Para la vista de contenedores, utilizo un exportador de DaemonSet con hostPID:true y montajes de solo lectura de /sys/fs/cgroup y /proc, para poder ver los archivos cgroup del host. Además, utilizo las métricas de Kubelet/cAdvisor, siempre que muestren los totales de PSI; las etiquetas espacio de nombres, pod y contenedor En eso soy coherente.

A mí me ayuda tener una idea clara Estrategia de marca: instancia (nombre del servidor o del nodo), cgroup (ruta), espacio de nombres/pod/contenedor (en el caso de los K8) así como estado (algunos/completo) y recurso (CPU/memoria/io/irq). Así puedo realizar una agregación a gran escala y, al mismo tiempo, ampliar la imagen al máximo.

Tareas de Prometheus, reglas de registro y consultas de ejemplo

Para obtener análisis precisos, utilizo dos modelos: los medidores de porcentaje (avg10/60/300) y derivadas rate()‑Valores en el *_segundos_de_espera_totales_‑Contadores.

• Scrape: 15 segundos es un buen comienzo. Si se acorta, aumenta la carga, lo que supone avg10 pero rara vez aporta un valor añadido.
• Normas de grabación: Calculo series temporales derivadas para simplificar los paneles de control y las alertas:
  • registro: psi:node_memory_full:avg60 = media_a_lo_largo_del_tiempo(node_pressure_memory_full_avg10[60 s])
  • registro: psi:node_io_full:rate5m = rate(node_pressure_io_waiting_seconds_total{state="full"}[5m])
  • registro: psi:cgroup_memory_full:rate5m = suma por (cgroup) (rate(cgroup_pressure_memory_waiting_seconds_total{state="full"}[5m]))

Con PromQL creo vistas típicas:

• Tendencia de los anfitriones: node_pressure_memory_full_avg60 a lo largo del tiempo, desglosado por nodos.
• Los principales responsables: topk(5, psi:cgroup_memory_full:rate5m) Muestra los cgroups más ruidosos.
• Repercusión en la latencia: (incremento(http_request_duration_seconds_sum[5m]) / incremento(http_request_duration_seconds_count[5m])) contra node_pressure_io_full_avg60 establecer, para detectar correlaciones.
• Reconocer los estancamientos: clamp_min(psi:node_io_full:rate5m, 0,0) en forma de mapa de calor por nodo.

Paneles de control de Grafana: visualizar tendencias e identificar puntos clave

En Grafana muestro por separado la carga de la CPU, la memoria y las E/S, en cada caso para algunos y completo como gráficos independientes. Los indicadores de barra me muestran el estado actual, mientras que los paneles de series temporales revelan picos y mesetas. Para el análisis de causas, utilizo vistas «Top N» por cgroup, contenedor o pod y, desde allí, accedo a los paneles detallados. Lo importante sigue siendo la combinación de avg10, avg60 y avg300, para evitar sobrecargas provocadas por picos breves. Quien quiera planificar con antelación los paneles de control encontrará ideas útiles en torno al Grafana y Prometheus Pila.

Las alertas en la práctica: normas, ventanas y escalado

Sigo un modelo de dos fases: Advertencia para detectar señales tempranas, Crítica para un cuello de botella permanente. A modo de ejemplo, pongo:

• Memoria
  • Advertencia: node_pressure_memory_full_avg60 > 0,01 durante 10-30 s
  • Crítico: node_pressure_memory_full_avg60 > 0,05 durante ≥60 s
• E/S
  • Advertencia: rate(node_pressure_io_waiting_seconds_total{state="some"}[5m]) > 0,02
  • Crítico: node_pressure_io_full_avg60 > 0,02 durante ≥120 s
• CPU
  • Advertencia: node_pressure_cpu_some_avg60 > 0,05
  • Crítico: node_pressure_cpu_full_avg60 > 0,01 (porque completo (aquí es donde más duele)

En las anotaciones, relaciono contextos (top-cgroups, rendimiento, latencia) y ejecuto guiones: escalado vertical, ajuste de límites, acciones de caché, limitación de lotes. En caso de eventos recurrentes, doy prioridad a las decisiones sobre capacidad.

Umbrales y alertas: elegir correctamente el intervalo de tiempo

Defino umbrales claros para cada recurso y distingo entre fallos graves y picos de carga breves. Por ejemplo, evalúo memoria llena Considero crítico un valor superior a 5 % durante más de 60 segundos, mientras que un valor de 1-2 % durante más de diez segundos solo activa una advertencia. Para la CPU, establezco límites más estrictos completo, ya que allí los tiempos de espera generalizados ralentizan notablemente el sistema. La combinación con métricas de rendimiento y latencia aporta un valor añadido: cuando la presión aumenta y las solicitudes se ralentizan, la urgencia se incrementa. Siempre configuro las alertas en intervalos de tiempo, no en valores concretos, para evitar falsas alarmas debidas a Ráfagas que hay que evitar.

Kubernetes: configuración de Scrape, permisos y correlación

En el clúster, recopilo datos PSI de tal forma que los niveles coincidan:

• Node-Exporter como DaemonSet: El «Standard-Scrape» por nodo proporciona valores globales de PSI.
• cgroup-Exporter como Sidecar/DaemonSet: Lee los archivos cgroup v2 del host y les asigna etiquetas según espacio de nombres/pod/contenedor. Utilizo los permisos y los montajes RO estrictamente necesarios.
• Kubelet/cAdvisor: Activo la visualización de las métricas relevantes de los contenedores y recojo datos del punto final de Kubelet. Conservo las claves de unión de etiquetas (por ejemplo,. contenedor vs. nombre_del_contenedor) de forma coherente, para que las uniones de PromQL funcionen sin problemas.
• Join con métricas de carga de trabajo: Establezco una correlación entre Pod-PSI y las latencias de las aplicaciones (por ejemplo, métricas HTTP), los casos en que se alcanzan los límites de la CPU y los errores de memoria. De este modo, puedo determinar si la causa son los límites, la programación o los cuellos de botella en el almacenamiento.

Archivos PSI, indicadores y interpretación: resumen conciso

La siguiente tabla resume los archivos, indicadores y fines de uso más importantes, para que pueda interpretarlos más rápidamente y crear paneles de Grafana adecuados. La utilizo durante el análisis para planificar la siguiente cuestión: ajuste, escalabilidad o resolución de problemas. Siguen siendo especialmente relevantes las diferencias entre algunos y completo así como las tres ventanas de media. Así es como clasifico los síntomas cronológicamente y compruebo si la presión se presenta de forma localizada o generalizada. La columna „Intervención“ ayuda a... Clasificación.

Recursos	Archivo	Cifras clave	Significado	Utilice
CPU	/proc/pressure/cpu	algunos, completo; promedio 10/60/300; total	Tiempo de espera para obtener tiempo de cálculo disponible	Hosts sobrecargados, CPU con poco margen...Límites
Memoria	/proc/presión/memoria	algunos, completo; promedio 10/60/300; total	Tiempo de espera debido a «Reclaim», «Swap» y estado cercano a OOM	Escasez de RAM, sobrecarga de la caché, errores Solicitudes
E/S	/proc/pressure/io	algunos, completo; promedio 10/60/300; total	Tiempo de espera en los dispositivos de almacenamiento/sistema de archivos	Unidades de almacenamiento lentas, picos de sincronización, Descarga-Fases
IRQ	/proc/pressure/irq	algunos, completo; promedio 10/60/300; total	Presión debida al procesamiento de interrupciones	Carga de red, ajuste de controladores, Afinidad
cgroup	*/{cpu,memory,io}.pressure	algunos, completo; promedio 10/60/300; total	Presión por servicio/contenedor	Búsqueda de la causa raíz, específica Límites

Aplicación práctica: proteger de forma eficaz el alojamiento web y las pilas de WordPress

En servidores de WordPress con mucho tráfico, PHP-FPM, la base de datos y la capa de caché compiten habitualmente por la memoria RAM y las operaciones de E/S, lo cual puedo comprobar a través de memoria y io lo veo enseguida. Sube completo En cuanto a la memoria, optimizo OpCache, aumento los tamaños de los pools de forma gradual o elimino los plugins que consumen muchos recursos. En caso de presión de E/S, compruebo los planes de consulta, la configuración del registro en diario y la escritura asíncrona. PSI por cgroup permite ver si el cuello de botella lo provoca el servidor web, los trabajadores o la base de datos. Quien quiera profundizar más, encontrará indicaciones en el Guía de Linux-PSI, que resume la introducción y la evaluación.

Planificación de la capacidad y optimización: de las cifras a las acciones

Relaciono el PSI con la carga de la CPU, los errores de página, el rendimiento de E/S y las latencias para identificar las causas reales. Si persiste... memoria llena amplié la RAM, optimicé los parámetros de recuperación o separé las cargas de trabajo. Muestra io completo En caso de platós prolongados, aumento la profundidad de las colas, activo estrategias de «write-back» o utilizo soportes de almacenamiento más rápidos. Para gestionar la carga de la CPU, mido en paralelo la longitud de las colas de ejecución, ajusto las clases de programación y distribuyo los hilos más activos. Solo tomo decisiones cuando se observan tendencias en el avg60 y avg300 mantener la coherencia y no limitarse a un Spike está disponible.

Resolución de problemas y validación: desde el host hasta el contenedor

Si faltan los valores PSI, compruebo la versión del kernel, CONFIG_PSI y, opcionalmente, el parámetro de arranque psi=1. A continuación, compruebo los resultados de los archivos en /proc/pressure/* manualmente y compáralas con las métricas de Exporter. En cgroup v2, además, controlo el *.presión-Archivos dentro de los directorios de grupo. Pruebo las alertas con generadores de carga y observo la lógica de respuesta a través de epoll, para detectar a tiempo los errores de configuración. Por último, comparo los paneles de Grafana con los registros, los trazas y los resultados del perfilador, para garantizar que el diagnóstico y las medidas correctivas sean fiables ajuste.

Los obstáculos típicos que tengo en cuenta son:

• Interacción de intercambio: Ligera memoria algoLos valores son normales en un proceso de recuperación agresivo. La situación se vuelve crítica cuando completo aumenta y, al mismo tiempo, se incrementan las latencias.
• Aislamiento y afinidad de la CPU: Los núcleos fijados o aislados pueden, a nivel local, CPU a pleno rendimiento generar, aunque el servidor aún tenga margen. Compruebo irq-PSI adicional si la red o el almacenamiento tienen una carga elevada de interrupciones.
• Entornos virtuales: En las máquinas virtuales, los valores de PSI también reflejan la influencia del hipervisor. Mido por separado los niveles de host e invitado para identificar con claridad el overcommitment.
• Sobrecarga de scraping: El PSI en sí es económico, pero unos intervalos de scraping demasiado cortos aumentan la carga de Prometheus. A menudo, 15 s es el punto óptimo.
• Cardinalidad de las etiquetas: Las rutas de los cgroups pueden dispararse. Yo lo regulo con labeldrop/mantener y solo recopilo los datos de las capas que analizo (por ejemplo, el servicio en lugar de cada «task-cgroup» de corta duración).

Brevemente resumido

PSI mide la verdadera tiempo de espera en la CPU, la RAM y las E/S, lo que indica claramente que hay una presión sobre los recursos. Con Prometheus Export y los paneles de Grafana, creo una vista que distingue las causas y detecta rápidamente los puntos críticos. La separación de algunos y completo además de las ventanas avg10/60/300 facilita la toma de decisiones con fiabilidad. Configuro las alertas en función de intervalos de tiempo, las vinculo a tiempos de latencia y controlo las reacciones automáticas mediante desencadenantes. De este modo, tomo decisiones fundamentadas sobre la capacidad, resuelvo los cuellos de botella a tiempo y mantengo los servicios en el día a día receptivo.