PostgreSQL
Monitoreo y observabilidad
Monitoreo de actividad, sesiones, locks, consultas, WAL, replicas y capacidad mediante vistas del sistema, métricas y alertas accionables.
- Última actualización
- Actualizada
- Nivel
- Aplicación
PostgreSQL
Monitoreo de actividad, sesiones, locks, consultas, WAL, replicas y capacidad mediante vistas del sistema, métricas y alertas accionables.
Observar PostgreSQL no consiste en coleccionar métricas. Consiste en relacionar demanda, espera, recursos y cambios para responder qué se degradó, desde cuándo, para quién y por qué.
Un modelo útil separa cuatro capas:
workload
→ qué queries, usuarios y servicios generan demanda
esperas
→ locks, I/O, CPU, red, cliente, WAL
recursos
→ conexiones, memoria, storage, checkpoints, vacuum
resultado
→ latencia, errores, throughput y disponibilidadUna métrica aislada rara vez demuestra la causa.
SELECT
pid,
application_name,
usename,
state,
wait_event_type,
wait_event,
xact_start,
query_start,
backend_xmin,
query
FROM pg_stat_activity
WHERE datname = current_database();Permite distinguir:
No registres ni expongas queries con secretos sin sanitización.
Una consulta lenta puede estar:
Lock: esperando otra transacción.IO: leyendo/escribiendo.ClientRead/ClientWrite: aplicación lenta o red.LWLock: contención interna.WAL: flush/replication.Timeout: sleeps o límites.El tiempo observado por la app incluye pool, red y serialización; PostgreSQL solo ve parte.
Extensión esencial para queries normalizadas:
SELECT queryid, calls, total_exec_time, mean_exec_time,
rows, shared_blks_hit, shared_blks_read,
temp_blks_written, wal_bytes
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;Busca:
Los valores concretos se normalizan; tracing seguro ayuda a encontrar parámetros problemáticos.
max_connections usado.Una base con CPU baja puede estar caída funcionalmente porque el pool está agotado.
SELECT pid, pg_blocking_pids(pid), wait_event, query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;Alerta por duración del bloqueo, no por existir locks. Incluye blocker, blocked count y transaction age.
pg_stat_user_tables:
n_live_tup, n_dead_tup estimados.Combina con tamaños y edad de XID. Un n_dead_tup alto no prueba por sí solo bloat grave.
pg_stat_user_indexes muestra scans y tuples leídas/fetched. Un índice “no usado” desde el último reset puede ser necesario para:
No lo elimines solo por idx_scan = 0.
Monitorea:
max_wal_size pressure.Picos pueden venir de backfills, indexes, full-page images o checkpoints frecuentes.
pg_wal separado.Disk full puede detener writes y archiving; alerta con margen suficiente para responder.
La métrica debe expresar qué garantía peligra: read freshness, failover RPO o capacidad de disco.
Alertas accionables:
Evita alertar cada métrica sin runbook.
Compara con:
Un valor absoluto puede ser normal para un workload y crítico para otro.
Añade metadata:
application_name.Esto permite unir métricas, logs y traces.
track_io_timing y logging detallado tienen overhead, normalmente razonable pero medible.confirmar impacto
→ identificar espera/recurso
→ hallar workload responsable
→ comparar cambios recientes
→ mitigar con menor riesgo
→ validar recuperación
→ corregir causaNo empieces reiniciando PostgreSQL o creando un índice al azar.
idx_scan=0 no basta para borrar?application_name?Logging y auditoría registra evidencia útil sin convertir secretos y volumen en un nuevo incidente.