Métodos de Brendan Gregg para latencia y perfilado

Por qué el enfoque de Brendan Gregg reduce las conjeturas

Brendan Gregg es una de las voces más influyentes en rendimiento de sistemas, especialmente en el mundo Linux. Ha escrito libros ampliamente usados, creado herramientas prácticas y—lo más importante—compartido métodos claros para investigar problemas reales en producción. Los equipos adoptan su enfoque porque funciona bajo presión: cuando la latencia sube y todos quieren respuestas, necesitas una manera de pasar de “quizá es X” a “es definitivamente Y” con el mínimo dramatismo.

Qué significa realmente “metodología de rendimiento”

Una metodología de rendimiento no es una única herramienta o un comando ingenioso. Es una forma repetible de investigar: una lista de verificación sobre qué mirar primero, cómo interpretar lo que ves y cómo decidir el siguiente paso.

Esa repetibilidad es lo que reduce las conjeturas. En lugar de depender de quien tenga más intuición (o la opinión más ruidosa), sigues un proceso consistente que:

• reduce el problema a un recurso, servicio o ruta de código concreta
• mide lo que está pasando en la misma ventana temporal que el incidente
• confirma el cuello de botella con evidencia antes de hacer cambios

El modo de fallo habitual: arreglar antes de medir

Muchas investigaciones de latencia se torcen en los primeros cinco minutos. La gente salta directo a arreglos: “añadir CPU”, “reiniciar el servicio”, “aumentar la caché”, “afinar el GC”, “debe ser la red”. A veces esas acciones ayudan—a menudo enmascaran la señal, desperdician tiempo o introducen nuevos riesgos.

Los métodos de Gregg te empujan a retrasar las “soluciones” hasta que puedas responder preguntas más simples: ¿qué está saturado? ¿qué está fallando? ¿qué se hizo más lento—throughput, encolamiento o operaciones individuales?

Qué te ayuda a hacer esta guía

Esta guía te ayuda a acotar el alcance, medir las señales correctas y confirmar el cuello de botella antes de optimizar. El objetivo es un flujo de trabajo estructurado para investigar latencia y problemas de perfilado en producción, de modo que los resultados no dependan de la suerte.

Fundamentos de latencia: qué medir antes de afinar

La latencia es un síntoma: los usuarios esperan más a que termine el trabajo. La causa suele estar en otro lugar—contención de CPU, esperas en disco o red, contención de locks, recolección de basura, encolamiento o retrasos en dependencias remotas. Medir solo la latencia te dice que existe dolor, no dónde se origina.

Throughput, latencia y errores se mueven juntos

Estas tres señales están acopladas:

• Throughput (solicitudes/segundo) en aumento puede incrementar el encolamiento, lo que aumenta la latencia.
• Los errores pueden reducir la latencia observada (fallos rápidos) o aumentarla (reintentos y timeouts).
• Limitar el throughput (rate limits, backpressure) puede mejorar la latencia de cola a costa de que menos solicitudes tengan éxito.

Antes de afinar, captura las tres en la misma ventana temporal. Si no, podrías “arreglar” la latencia dejando caer trabajo o fallando más rápido.

No confíes en los promedios: percentiles y latencia de cola

La latencia media oculta los picos que los usuarios recuerdan. Un servicio con 50 ms de promedio puede tener frecuentes bloqueos de 2 s.

Rastrea percentiles:

• p50: experiencia típica del usuario
• p95/p99: latencia de cola (donde reside la mayor parte del dolor en incidentes)

También vigila la forma de la curva de latencia: un p50 estable con un p99 en aumento a menudo indica paradas intermitentes (p. ej., contención de locks, problemas de I/O, pausas stop-the-world) más que una desaceleración general.

Presupuestos de latencia: dónde puede ir el tiempo

Un presupuesto de latencia es un modelo de contabilidad simple: “Si la solicitud debe terminar en 300 ms, ¿dónde puede gastarse ese tiempo?” Divídelo en cubos como:

• tiempo en tu servicio (cómputo + esperas)
• tiempo en servicios downstream
• tiempo en bases de datos/cachés
• tránsito de red y TLS
• tiempo encolado (hilos, pools de conexión, balanceadores)

Este presupuesto enmarca la primera tarea de medición: identifica qué cubo creció durante el pico y luego investiga esa área en lugar de afinar a ciegas.

Empieza con una pregunta clara y un alcance definido

El trabajo de latencia se descarrila cuando el “problema” se describe como el sistema está lento. Los métodos de Gregg empiezan antes: fuerza la cuestión a una pregunta específica y comprobable.

Define qué significa “lento” (y para quién)

Escribe dos frases antes de tocar herramientas:

• ¿Qué está lento? (carga de página, endpoint de API, job batch, login, checkout, una consulta SQL concreta)
• ¿Dónde se observa la lentitud? (navegador del cliente, app móvil, una región, un pod, un host, un servicio interno)

Esto evita que optimices la capa equivocada—por ejemplo, CPU del host—cuando el dolor está aislado a un endpoint o una dependencia downstream.

Elige una ventana temporal y un alcance

Escoge una ventana que coincida con la queja e incluye, si es posible, un periodo de comparación “bueno”.

Define explícitamente el alcance de tu investigación:

• Host vs servicio vs endpoint: “Un nodo de Kubernetes” es diferente de “una ruta de API”.
• Qué porción del tráfico: región, nivel de cliente, solo solicitudes con error o todas las solicitudes.
• Qué señal motivó el reporte: p95 de latencia, timeouts, profundidad de colas o timings de usuario.

Ser preciso aquí hace que los pasos siguientes (USE, RED, perfilado) sean más rápidos porque sabrás qué datos deberían cambiar si tu hipótesis es correcta.

Trata los cambios recientes como hipótesis, no como respuestas

Anota despliegues, cambios de configuración, desplazamientos de tráfico y eventos de infra—pero no asumas causalidad. Escríbelos como “Si X, entonces esperaríamos Y”, para poder confirmar o rechazar rápidamente.

Mantén un registro ligero de la investigación

Un pequeño registro evita trabajo duplicado entre compañeros y facilita las transiciones.

Time | Question | Scope | Data checked | Result | Next step

Incluso cinco líneas como esta pueden convertir un incidente estresante en un proceso repetible.

El método USE: un inventario rápido de cuellos de botella por recurso

El método USE (Utilization, Saturation, Errors) es la lista de verificación rápida de Gregg para escanear los “cuatro grandes” recursos—CPU, memoria, disco (almacenamiento) y red—para que dejes de adivinar y empieces a acotar el problema.

Qué es: una lista por recurso

En lugar de mirar docenas de dashboards, hazte las mismas tres preguntas para cada recurso:

• Utilización: ¿qué tan ocupado está ahora?
• Saturación: ¿se está acumulando trabajo (colas, tiempo de espera), aunque la utilización no esté al máximo?
• Errores: ¿está fallando o reintentando de formas que generan demora?

Aplicado consistentemente, esto se vuelve un inventario rápido de dónde existe “presión”.

Cómo aplicarlo en la práctica

Para CPU, la utilización es el % de CPU ocupado, la saturación se manifiesta como presión en la run-queue o hilos esperando para ejecutarse, y los errores pueden incluir throttling (en contenedores) o interrupciones mal comportadas.

Para memoria, la utilización es la memoria usada, la saturación aparece como paginación o recolecciones de basura frecuentes, y los errores incluyen fallos de asignación o eventos OOM.

Para disco, la utilización es el tiempo de busy del dispositivo, la saturación es la profundidad de cola y el tiempo de espera de lectura/escritura, y los errores son errores de I/O o timeouts.

Para red, la utilización es el throughput, la saturación son drops/colas/latencia y los errores son retransmisiones, resets o pérdida de paquetes.

Señales más útiles durante incidentes de latencia

Cuando los usuarios reportan lentitud, las señales de saturación suelen ser las más reveladoras: colas, tiempo de espera y contención tienden a correlacionar más directamente con la latencia que la simple utilización.

USE complementa métricas de servicio (no las reemplaza)

Las métricas de nivel de servicio (como latencia de petición y tasa de errores) te dicen el impacto. USE te dice dónde mirar a continuación identificando qué recurso está bajo tensión.

Un bucle práctico es:

1. Confirma el impacto de usuario (Duration/Errors)
2. Ejecuta el inventario USE
3. Zoom al recurso sospechoso con herramientas más profundas (perfiles, trazas, stats del kernel)

El método RED: señales centradas en el servicio que apuntan al impacto

El método RED te mantiene anclado a la experiencia del usuario antes de sumergirte en gráficas del host.

• Rate: cuántas solicitudes por segundo maneja tu servicio o endpoint
• Errors: cuántas solicitudes fallan (y qué significa “fallar” para tu app)
• Duration: cuánto tardan las solicitudes exitosas (seguido por percentiles, no promedios)

Por qué RED te ayuda a priorizar

RED evita que persigas métricas “interesantes” del sistema que no afectan a los usuarios. Fuerza un bucle más cerrado: ¿qué endpoint está lento, para qué usuarios y desde cuándo? Si Duration sube solo en una ruta mientras la CPU global está estable, ya tienes un punto de partida más afilado.

Un hábito útil: mantener RED desglosado por servicio y endpoints principales (o métodos RPC clave). Eso facilita distinguir una degradación amplia de una regresión localizada.

Mapear síntomas RED a chequeos USE

RED te dice dónde duele. USE te ayuda a probar qué recurso es responsable.

Ejemplos:

• Duration ↑ + Rate estable → revisar saturación/encolamiento: run queue de CPU, latencia de almacenamiento, pools de conexión a BD.
• Errors ↑ + Duration ↑ → revisar timeouts y reintentos: downstreams sobrecargados, pools de hilos, drops de red.
• Rate ↑ + Duration ↑ → revisar límites de capacidad: utilización de CPU, comportamiento del balanceador, retardos en autoscaling.

Un dashboard mínimo de “qué cambió”

Mantén el diseño enfocado:

1. Resumen RED: Rate, Errors y p50/p95/p99 de Duration para el servicio.
2. Endpoints principales: las mismas señales RED por endpoint, ordenadas por tráfico o peor p95.
3. Dependencias: paneles estilo RED para downstreams importantes (BD, caché, APIs externas).
4. Una fila de correlación: un conjunto pequeño de métricas del sistema (CPU, presión de memoria, latencia de I/O en disco, retransmisiones de red) para acelerar el salto desde la vista del servicio al test de causa raíz.

Si quieres un flujo de incidentes consistente, empareja esta sección con el inventario USE en /blog/use-method-overview para que puedas moverte de “los usuarios lo sienten” a “este recurso es la restricción” con menos idas y venidas.

Priorización: elige la siguiente mejor pregunta

Una investigación de rendimiento puede explotar en docenas de gráficos e hipótesis en minutos. La mentalidad de Gregg es mantenerlo estrecho: tu trabajo no es "recoger más datos", sino hacer la siguiente pregunta que elimine la incertidumbre más rápido.

La regla 80/20 para cuellos de botella

La mayoría de los problemas de latencia están dominados por un único costo (o una pequeña pareja): un lock caliente, una dependencia lenta, un disco sobrecargado, un patrón de pausas de GC. Priorizar significa cazar ese costo dominante primero, porque recortar 5% en cinco lugares raramente mueve la latencia visible por el usuario.

Una prueba práctica: “¿Qué podría explicar la mayor parte del cambio de latencia que vemos?” Si una hipótesis solo puede explicar una porción pequeña, es una pregunta de menor prioridad.

De arriba hacia abajo vs. de abajo hacia arriba: dónde empezar

Usa top-down cuando respondes “¿Los usuarios están impactados?” Empieza por endpoints (señales estilo RED): latencia, throughput, errores. Esto ayuda a evitar optimizar algo que no está en la ruta crítica.

Usa bottom-up cuando el host está claramente enfermo (síntomas estilo USE): saturación de CPU, presión de memoria descontrolada, espera de I/O. Si un nodo está al tope, perderás tiempo mirando percentiles de endpoints sin entender la restricción.

Un árbol de decisión simple que previene el vaivén

Cuando suena una alerta, elige una rama y mantente en ella hasta confirmarla o falsarla:

• Spike de latencia + spike de errores → “¿Es una dependencia o un evento de capacidad?” (timeouts, agotamiento de pools de conexión, downstream 5xx)
• Spike de latencia + spike de CPU → “¿La CPU hace trabajo útil o está atascada?” (tiempo on-CPU vs off-CPU)
• Spike de latencia + alta espera de I/O → “¿Qué dispositivo o sistema de archivos se está acumulando?”
• Spike de latencia sin picos de recursos → “¿Dónde se gasta el tiempo en espera?” (locks, scheduler, red, llamadas remotas)

Evita la sobrecarga de métricas, mantente sistemático

Limítate a un pequeño conjunto inicial de señales, y profundiza solo cuando algo se mueva. Si necesitas una lista para mantener el foco, enlaza tus pasos a un runbook como /blog/performance-incident-workflow para que cada nueva métrica tenga un propósito: responder una pregunta específica.

Perfilado en producción sin tumbar el sistema

El perfilado en producción puede parecer riesgoso porque toca el sistema en vivo—pero a menudo es la manera más rápida de reemplazar el debate por evidencia. Logs y dashboards pueden decirte qué es lento. El perfilado te dice dónde se va el tiempo: qué funciones consumen más, qué hilos esperan y qué rutas de código dominan durante el incidente.

Qué responde realmente el perfilado

El perfilado es una herramienta de “presupuesto de tiempo”. En lugar de debatir teorías (“es la base de datos” vs “es el GC”), obtienes evidencia como “45% de las muestras de CPU estaban en parsing JSON” o “la mayoría de las solicitudes están bloqueadas por un mutex”. Eso reduce el siguiente paso a una o dos correcciones concretas.

Tipos comunes que puedes usar en producción

• Perfilado de CPU: muestra qué código se ejecuta on-CPU.
• Perfilado off-CPU (espera): muestra dónde los hilos pasan tiempo bloqueados (esperas de I/O, retrasos del scheduler, sleep, red, disco).
• Perfilado de locks: muestra la contención—tiempo perdido esperando locks, mutexes y cerrojos de lectura/escritura.

Cada uno responde a una pregunta diferente. Latencia alta con baja CPU a menudo apunta a tiempo off-CPU o contención de locks más que hotspots de CPU.

Siempre activo vs bajo demanda

• Perfilado siempre activo (continuo, con bajo overhead) ayuda con misterios de “ocurrió a las 3am” porque puedes mirar hacia atrás.
• Perfilado bajo demanda es una captura dirigida durante un spike. Es más sencillo de adoptar, pero debes estar listo para activarlo rápido.

Muchos equipos empiezan bajo demanda y luego pasan a siempre activo cuando confían en la seguridad y ven problemas recurrentes.

Seguridad: overhead, muestreo y ventanas cortas

El perfilado seguro en producción trata de controlar el costo. Prefiere muestreo (no trazar cada evento), mantén ventanas de captura cortas (por ejemplo, 10–30 segundos) y mide el overhead en un canario primero. Si no estás seguro, empieza con muestreo de baja frecuencia y aumenta solo si la señal es demasiado ruidosa.

Flame graphs: cómo leerlos y evitar conclusiones falsas

Los flame graphs visualizan dónde se fue el tiempo muestreado durante una ventana de perfilado. Cada “caja” es una función (o frame de stack), y cada stack muestra cómo la ejecución llegó a esa función. Son excelentes para detectar patrones rápido—pero no te dicen automáticamente “el bug está aquí”.

Qué muestra un flame graph (y qué no)

Un flame graph generalmente representa muestras on-CPU: tiempo que el programa estuvo realmente corriendo en un núcleo. Puede resaltar paths de código que consumen CPU, parsing ineficiente, serialización excesiva o hotspots que realmente queman CPU.

No muestra directamente esperas por disco, red, retrasos del scheduler o tiempo bloqueado por un mutex (eso es off-CPU y requiere otro tipo de perfilado). Tampoco prueba causalidad para la latencia visible al usuario a menos que lo conectes a un síntoma acotado.

Leer anchura y profundidad de stack

• Anchura: cuántas veces ese frame apareció en las muestras. Más ancho normalmente significa “más tiempo de CPU”, pero solo dentro de la ventana de tiempo elegida.
• Profundidad de stack: profundidad de llamadas. Stacks profundos no son inherentemente malos; lo importante es qué paths dominan y si coinciden con el trabajo que te importa.

Trampas comunes a evitar

La caja más ancha es tentadora de culpar, pero pregúntate: ¿es un hotspot que puedes cambiar, o simplemente “tiempo pasado en malloc, GC o logging” porque el verdadero problema está aguas arriba? También vigila el contexto faltante (JIT, inlining, símbolos) que puede hacer que una caja parezca culpable cuando solo es el mensajero.

Combina flame graphs con una pregunta precisa

Trata un flame graph como una respuesta a una pregunta acotada: qué endpoint, qué ventana temporal, qué hosts y qué cambió. Compara flame graphs “antes vs después” (o “saludable vs degradado”) para la misma ruta de solicitud para evitar ruido de perfilado.

Tiempo off-CPU: la fuente oculta de latencia

Cuando la latencia sube, muchos equipos miran el % de CPU primero. Es comprensible—pero a menudo indica en la dirección equivocada. Un servicio puede estar “solo al 20% de CPU” y aun así ser dolorosamente lento si sus hilos pasan la mayor parte del tiempo sin ejecutarse.

Por qué el % de CPU engaña

El % de CPU responde “qué tan ocupado está el procesador”. No responde “¿dónde se fue el tiempo de mi solicitud?”. Las solicitudes pueden quedarse atascadas mientras los hilos esperan, están bloqueados o son aparcados por el scheduler.

Una idea clave: el tiempo de reloj de pared de una solicitud incluye tanto trabajo on-CPU como esperas off-CPU.

Culpables comunes off-CPU

El tiempo off-CPU suele esconderse detrás de dependencias y contención:

• I/O de disco: lecturas/escrituras sincrónicas, fsyncs, almacenamiento lento, misses de caché de página.
• Esperas de red: búsquedas DNS, retransmisiones TCP, upstreams sobrecargados.
• Contención de locks y mutexes: hilos bloqueados en locks, reader/writer locks, contención del asignador.
• Encolamiento: esperando en pools de hilos, pools de conexión o colas internas de trabajo.

Síntomas a vigilar

Unas pocas señales suelen correlacionar con cuellos off-CPU:

• aumento del tiempo en cola (solicitudes esperando antes de empezar a ejecutarse)
• incremento de hilos ejecutables (más competencia por tiempo de CPU)
• elevación de I/O wait y latencias más largas de disco/red

Estas señales te dicen “estamos esperando”, pero no en qué se está esperando.

Cómo el perfilado off-CPU muestra “dónde se fue el tiempo”

El perfilado off-CPU atribuye tiempo a la razón por la que no estábamos corriendo: bloqueo en syscalls, espera en locks, sleep o des-scheduling. Eso es potente para trabajo de latencia porque convierte desaceleraciones vagas en categorías accionables: “bloqueado en mutex X”, “esperando read() de disco” o “atascado en connect() a un upstream”. Una vez que puedes nombrar la espera, puedes medirla, confirmarla y arreglarla.

Confirma el cuello de botella con evidencia, no intuición

El trabajo de rendimiento a menudo falla en el mismo momento: alguien ve una métrica sospechosa, la declara “el problema” y empieza a afinar. Los métodos de Gregg te empujan a desacelerar y probar qué está limitando el sistema antes de cambiar nada.

Cuello de botella, hotspot y ruido

Un cuello de botella es el recurso o componente que actualmente limita el throughput o impulsa la latencia. Si lo alivias, los usuarios ven mejora.

Un hot spot es donde se gasta tiempo (por ejemplo, una función que aparece frecuentemente en un perfil). Los hotspots pueden ser cuellos de botella reales—o simplemente trabajo ocupado que no afecta la ruta lenta.

Ruido es todo lo que parece significativo pero no lo es: jobs de background, picos puntuales, artefactos de muestreo, efectos de caché o “talkers” que no correlacionan con el problema visible al usuario.

Pruébalo con comparaciones y cambios controlados

Empieza por capturar una instantánea limpia antes: el síntoma visible (latencia o tasa de errores) y las señales candidatas principales (saturación de CPU, profundidad de colas, I/O de disco, contención de locks, etc.). Luego aplica un cambio controlado que debería afectar solo a la causa sospechada.

Ejemplos de pruebas causales:

• Añadir capacidad al recurso sospechado (otro worker, más shares de CPU, pool de conexión mayor) y comprobar si la latencia mejora.
• Reducir temporalmente la demanda (limitar un endpoint ruidoso, reproducir menos carga) y ver si la restricción sospechada se relaja.

La correlación es una pista, no un veredicto. Si “la CPU sube cuando la latencia sube”, verifica cambiando la disponibilidad de CPU o reduciendo trabajo de CPU y observa si la latencia sigue.

Documenta lo que probaste

Anota: qué se midió, el cambio exacto realizado, los resultados antes/después y la mejora observada. Esto convierte una victoria puntual en un playbook reutilizable para el próximo incidente—y evita que la “intuición” reescriba la historia después.

Construye un flujo repetible para incidentes de rendimiento

Los incidentes de rendimiento se sienten urgentes, que es precisamente cuando se cuela la conjetura. Un flujo ligero y repetible te ayuda a pasar de “algo está lento” a “sabemos qué cambió” sin dar vueltas.

El ciclo del incidente: detectar → priorizar → medir → arreglar

Detectar: alertar sobre latencia y errores visibles para el usuario, no solo CPU. Avisar cuando p95/p99 cruza un umbral sostenido.

Priorizar: responde inmediatamente tres preguntas: qué está lento, cuándo empezó y quién está afectado? Si no puedes nombrar el alcance (servicio, endpoint, región, cohorte), no estás listo para optimizar.

Medir: recoge evidencia que acote el cuello de botella. Prefiere capturas acotadas en el tiempo (por ejemplo, 60–180 segundos) para poder comparar “malo” vs “bueno”.

Arreglar: cambia una cosa a la vez y vuelve a medir las mismas señales para confirmar la mejora y descartar efecto placebo.

Estandariza un pequeño conjunto de gráficas

Mantén un dashboard compartido que todos usen durante incidentes. Hazlo aburrido y consistente:

• Latencia: p50 / p95 / p99 (por endpoint crítico)
• Señales RED: Rate, Errors, Duration (vista centrada en el servicio)
• Unos pocos métricos USE: utilización, saturación, errores para CPU, disco y red

El objetivo no es graficar todo; es acortar el tiempo hasta el primer hecho.

Define “señales doradas” por endpoint crítico

Instrumenta los endpoints que más importan (checkout, login, búsqueda), no todos. Para cada uno, acuerda: p95 esperado, tasa máxima de errores y dependencia clave (BD, caché, tercero).

Decide qué capturar durante incidentes

Antes del próximo outage, acuerda un kit de captura:

• Perfiles (CPU y off-CPU), más flame graphs
• Trazas para los endpoints lentos
• Logs de errores/timeouts (muestreados)

Documenta esto en un runbook corto (p. ej., /runbooks/latency), incluyendo quién puede ejecutar capturas y dónde se almacenan los artefactos.

Dónde encaja Koder.ai en un flujo estilo Gregg

La metodología de Gregg es fundamentalmente sobre cambio controlado y verificación rápida. Si tu equipo crea servicios usando Koder.ai (una plataforma guiada por chat para generar e iterar apps web, backend y móviles), dos características encajan bien con esa mentalidad:

• Planning Mode te ayuda a convertir “quizá es X” en una hipótesis explícita y un conjunto pequeño de cambios comprobables antes de tocar producción.
• Snapshots and rollback soportan experimentos seguros y de variable única: aplica un cambio, vuelve a medir señales RED/USE y revierte rápido si la evidencia dice “no”.

Aunque no generes nuevo código durante un incidente, esos hábitos—diffs pequeños, resultados medibles y reversibilidad rápida—son los mismos que Gregg promueve.

Un recorrido práctico: del pico de latencia a la solución verificada

El escenario: p99 sube en hora punta

Son las 10:15 y tu dashboard muestra que el p99 de la API sube de ~120ms a ~900ms durante el tráfico pico. La tasa de errores está plana, pero los clientes reportan solicitudes “lentas”.

Paso 1 — Empieza con RED para encontrar el impacto al usuario

Comienza centrado en el servicio: Rate, Errors, Duration.

Segmentas Duration por endpoint y ves una ruta dominando el p99: POST /checkout. El Rate sube 2×, los errores son normales, pero la Duration se dispara cuando aumenta la concurrencia. Eso apunta a encolamiento o contención, no a una falla directa.

Luego comprueba si la latencia es tiempo de cómputo o espera: compara el “handler time” de la aplicación vs el tiempo total de la petición (o spans upstream vs downstream si tienes tracing). El handler time es bajo, el tiempo total es alto—las solicitudes están esperando.

Paso 2 — Aplica USE a los host(s) sospechosos

Inventaria los cuellos probables: Utilización, Saturación, Errores para CPU, memoria, disco y red.

La utilización de CPU está solo en ~35%, pero la run queue y los context switches suben. Disco y red parecen estables. Ese desajuste (CPU baja, mucha espera) es un clásico: los hilos no consumen CPU—están bloqueados.

Paso 3 — Elige perfilado según los síntomas

• Si la CPU está alta: usa perfilado de CPU (flame graphs on-CPU) para ver dónde se gasta el tiempo.
• Si las solicitudes esperan: usa perfilado off-CPU para ver en qué están bloqueados los hilos (locks, I/O, scheduler).

Capturas un perfil off-CPU durante el pico y encuentras mucho tiempo en un mutex alrededor de una caché compartida de “validación de promociones”.

Paso 4 — Arregla y verifica

Reemplazas el lock global por un lock por clave (o un camino de lectura sin lock), despliegas y observas que el p99 vuelve a la línea base mientras el Rate se mantiene alto.

Checklist post-incidente:

• Registra los síntomas RED exactos y el endpoint acotado.
• Guarda el perfil y la ventana temporal.
• Añade una alerta para la señal de saturación específica (p. ej., espera de lock / run queue).
• Escribe la “siguiente pregunta a hacer” si vuelve a ocurrir.