Fundamentos de la resolución de problemas
Resolver problemas en un sistema PostgreSQL es menos memorizar consultas de diagnóstico y más ejecutar un método repetible bajo presión.
//
Busca en todas las páginas de la documentación
Resolver problemas en un sistema PostgreSQL es menos memorizar consultas de diagnóstico y más ejecutar un método repetible bajo presión.
Esta página construye el modelo mental que un ingeniero senior o DBA utiliza realmente cuando la producción está degradada, de modo que los playbooks específicos de otras secciones se lean como instancias de ese modelo en lugar de un montón de trucos no relacionados.
Cada sesión de resolución de problemas de Postgres comienza con la misma pregunta: ¿el sistema está empeorando activamente, manteniéndose igual o ya recuperándose?
Esa única pregunta decide si pasas los próximos cinco minutos estabilizando o los próximos cinco minutos diagnosticando, y confundir los dos es el error más común que incluso los ingenieros experimentados cometen bajo presión.
La estabilización significa detener el daño activo, como matar un bloqueador descontrolado o reducir la carga, sin necesariamente entender todavía por qué comenzó el daño.
El diagnóstico significa construir una cadena de evidencia, una secuencia de observaciones que conecta un síntoma con un mecanismo y una causa raíz.
Un síntoma es lo que experimenta el negocio o el usuario, mientras que una causa raíz es la condición subyacente que, dejada sola, sigue produciendo ese síntoma.
Confundir los dos es peligroso porque arreglar un síntoma, como reiniciar un servicio o matar una sesión, puede detener el pager sin tocar la condición que causará el próximo incidente.
El radio de explosión es el inventario honesto de lo que está realmente afectado en este momento, no de lo que teóricamente podría estar afectado, y debe ser re-medido a medida que llegan nuevos hechos en lugar de fijarse al principio.
Postgres expone la mayor parte de lo que necesitas para construir esa cadena de evidencia a través de un puñado de vistas del sistema, principalmente pg_stat_activity, pg_locks y las vistas de replicación, en lugar de solo a través de los registros de la aplicación.
Una analogía útil es el triaje de un médico: signos vitales primero, luego síntomas, luego pruebas, y solo entonces tratamiento.
Saltarse directamente al diagnóstico profundo mientras el paciente, es decir, la base de datos, se está deteriorando activamente es cómo los minutos se convierten en horas.
La mecánica de la resolución de problemas son realmente las mecánicas de la correlación, haciendo coincidir la línea de tiempo de un síntoma con un pequeño número de cambios de estado internos.
pg_stat_activity es lo más parecido a un monitor de signos vitales en vivo que tiene Postgres, mostrando el estado actual de cada backend, el evento de espera y cuánto tiempo ha mantenido ese estado.
Un evento de espera te dice de qué está bloqueada una sesión en este momento, ya sea un bloqueo, una operación de I/O o una simple latencia de red del cliente, y leer los eventos de espera como una distribución revela problemas sistémicos que leer una sesión a la vez nunca revelará.
Los bloqueos interactúan con las transacciones, y las transacciones interactúan con la visibilidad MVCC, por lo que una sesión que parece atascada a menudo está esperando detrás de una sesión completamente diferente que en sí misma está simplemente inactiva.
Esa indirección es la razón por la que los ingenieros senior preguntan reflexivamente de quién está realmente bloqueada una sesión antes de tocar nada, usando pg_blocking_pids() para recorrer el gráfico de dependencia real en lugar de adivinar solo por el texto de la consulta.
La replicación introduce un segundo eje de interacción, porque una primaria que parece saludable aún puede estar quedándose atrás silenciosamente de una réplica, y ese retraso en sí mismo se convierte en el próximo incidente si se deja desatendido.
Autovacuum y el hinchazón MVCC interactúan con casi todo lo demás, ya que una sola transacción de larga duración en cualquier nodo puede impedir que vacuum limpie las tuplas muertas, degradando lentamente el rendimiento hasta que una consulta no relacionada comience a fallar.
Esta es la trampa de razonamiento central en la resolución de problemas de Postgres: los subsistemas están tan estrechamente acoplados que una solución en un lugar puede crear silenciosamente un nuevo incidente en otro lugar.
Un ingeniero senior gestiona ese acoplamiento verificando la vista de segundo orden después de cualquier mitigación, como confirmar el retraso de la réplica y los recuentos de conexiones justo después de terminar una sesión bloqueadora.
La consulta a continuación ilustra el hábito de categorización en sí mismo, no un incidente específico, al agrupar los backends activos por en qué están esperando actualmente.
-- Categoriza la actividad actual por tipo de espera, no por texto de consulta.
-- Este es un hábito de diagnóstico, no una solución: te dice DÓNDE buscar a continuación.
SELECT wait_event_type, wait_event, count(*) AS sessions
FROM pg_stat_activity
WHERE state != 'idle'
GROUP BY 1, 2
ORDER BY sessions DESC;Leer ese resultado como una distribución, en lugar de perseguir la consulta más lenta, es lo que separa el diagnóstico de causa raíz de la caza de síntomas.
A escala, la resolución de problemas deja de ser un ingeniero leyendo pg_stat_activity y se convierte en un pipeline de señales automatizadas que un humano interpreta.
Herramientas como pg_stat_statements, auto_explain y agentes APM externos existen precisamente porque nadie puede observar cada consulta en tiempo real en un clúster de producción ocupado.
La habilidad avanzada no es aprender más consultas de diagnóstico, es aprender qué señal confiar cuando dos señales discrepan, como cuando la latencia a nivel de aplicación se ve bien pero los eventos de espera del lado de la base de datos muestran una contención acumulándose debajo.
Los fallos en cascada son el caso avanzado más difícil, donde una tormenta de bloqueos en la primaria causa retraso en la réplica, lo que empuja el tráfico de lectura de vuelta a la primaria, lo que profundiza la tormenta de bloqueos original.
Romper ese tipo de bucle generalmente requiere reducir la carga en el borde, a través de limitación de velocidad o disyuntores, antes de que una solución a nivel de base de datos pueda tener efecto.
La madurez de la observabilidad también cambia lo que significa causa raíz, ya que un sistema bien instrumentado te permite distinguir una anomalía única de una tendencia de lenta acumulación que las métricas han mostrado durante semanas.
La cultura de autopsia también es parte de la mecánica, porque un incidente que no se convierte en un patrón documentado simplemente se repetirá con un desencadenante diferente.
La siguiente tabla compara las posturas que los equipos suelen adoptar hacia la madurez de la resolución de problemas, ya que la postura en la que te encuentras cambia lo que parece un buen triaje día a día.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Lucha reactiva contra incendios | Rápido de empezar, no requiere inversión en herramientas | Agota al personal de guardia, los mismos incidentes se repiten | Equipos en etapa temprana con una pequeña huella de base de datos |
| Triaje basado en runbooks | Respuesta consistente, incorporación más rápida para el personal de guardia nuevo | Los runbooks se pudren si no están vinculados a incidentes reales | Equipos que han superado sus primeros Sev-1 |
| Métricas y alertas primero | Detecta tendencias antes de que notifiquen a nadie | Fatiga de alertas si los umbrales no se ajustan | Equipos con capacidad dedicada de plataforma o SRE |
| Autocuración automatizada | Elimina a los humanos de las mitigaciones rutinarias | Peligroso si la automatización diagnostica mal la causa | Plataformas maduras con modos de fallo bien entendidos |
Ningún equipo permanece en una sola postura para siempre, y el movimiento avanzado honesto es tratar esta tabla como una curva de madurez en lugar de un menú de opciones permanentes.
Comprueba si el sistema está empeorando activamente, manteniéndose estable o ya recuperándose.
Ese único hecho decide si pasas los próximos minutos estabilizando o diagnosticando, y hacer ambas cosas a la vez generalmente significa no hacer ninguna bien.
Compiten por el mismo tiempo durante un incidente, y tratarlos como una actividad borrosa única tiende a producir correcciones apresuradas y mal fundamentadas.
Estabilizar primero compra el tiempo que el diagnóstico realmente necesita para hacerse correctamente.
Un síntoma es lo que informa un usuario o un panel, como una salida de compra lenta.
Una causa raíz es la condición subyacente que produce ese síntoma, como una migración que tomó un bloqueo exclusivo sin tiempo de espera.
pg_stat_activity para saber qué está haciendo cada sesión en este momentopg_locks para saber quién está bloqueado y por quiénLos subsistemas de Postgres están estrechamente acoplados, por lo que los bloqueos afectan a las transacciones, las transacciones afectan a la visibilidad MVCC y la visibilidad afecta la capacidad de autovacuum para limpiar.
Una mitigación que ignora ese acoplamiento puede resolver un síntoma mientras inicia silenciosamente otro.
Es una táctica de estabilización válida, pero no es un diagnóstico por sí sola.
Sin entender por qué esa sesión se convirtió en un bloqueador, el mismo patrón volverá a aparecer bajo las mismas condiciones.
Mídelo como un inventario honesto de lo que está realmente afectado en este momento, y luego repite la medición a medida que llegan nuevos hechos.
Tratar una estimación temprana como definitiva es una forma común en que se juzga mal la severidad.
Un evento de espera describe de qué está bloqueada una sesión actualmente, como un bloqueo o una lectura de I/O.
Agrupar las sesiones por evento de espera revela patrones de contención sistémica que el escaneo de consultas lentas individuales tiende a pasar por alto.
Una tormenta de bloqueos en la primaria puede ralentizar la replicación, lo que empuja el tráfico de lectura de vuelta a la primaria, lo que profundiza la contención original.
Romper ese bucle generalmente significa reducir la carga en el borde antes de que la solución a nivel de base de datos pueda tener efecto.
Solo si se dirige a las señales que realmente predicen incidentes en su sistema.
Los registros o alertas indiferenciados añaden ruido que un humano aún tiene que filtrar bajo presión de tiempo.
Un incidente que no se convierte en un patrón documentado tiende a repetirse con un desencadenante ligeramente diferente.
La autopsia es donde una solución única se convierte en un cambio de proceso duradero.
Sí, los problemas de lenta acumulación como el hinchazón o la deriva de estadísticas a menudo permanecen por debajo de los umbrales de alerta hasta que cruzan un borde de acantilado.
Es por eso que la revisión periódica de las tendencias es tan importante como la reacción a las alertas activas.
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (línea estable 18, línea de mantenimiento 17); las vistas de diagnóstico y las mecánicas generales de triaje descritas aquí son estables en versiones principales recientes.
Revisado por Chris St. John·Última actualización: 15 jul 2026