pgbadger

Análisis de registros para el descubrimiento de consultas lentas en PostgreSQL 18.4 - convierte la salida de log_min_duration_statement en informes clasificados que alimentan la revisión de EXPLAIN y los tickets de diseño de índices.

Receta

ALTER SYSTEM SET log_destination = 'csvlog';
ALTER SYSTEM SET logging_collector = on;
ALTER SYSTEM SET log_min_duration_statement = '250ms';
ALTER SYSTEM SET log_statement = 'none';
ALTER SYSTEM SET log_line_prefix = '%t [%p]: user=%u,db=%d,app=%a,client=%h ';
SELECT pg_reload_conf();

pgbadger /var/log/postgresql/postgresql-18-main.csv \
  -o /var/reports/pgbadger/$(date +%F) \
  --incremental \
  --exclude-query="^(BEGIN|COMMIT|SET|SHOW)"

Cuándo recurrir a esto:

• Revisión semanal de consultas lentas sin habilitar log_statement = all completo
• Tendencia histórica: "¿el despliegue X degradó el tiempo de consulta p95?"
• Equipos sin presupuesto para pganalyze aún necesitan listas de consultas accionables

Ejemplo de trabajo

Paso 1 - Recopilar un día de registros

sudo ls -la /var/log/postgresql/
# postgresql-18-main.csv, postgresql-18-main.csv.1, ...

Paso 2 - Generar informe

OUT=/var/reports/pgbadger/2026-07-09
mkdir -p "$OUT"
pgbadger /var/log/postgresql/postgresql-18-main.csv* \
  -o "$OUT" \
  --jobs=4 \
  --top=50

Paso 3 - Clasificar la consulta principal

-- Copiar la consulta normalizada del informe a psql
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT o.id, o.total
FROM orders o
WHERE o.tenant_id = $1 AND o.status = 'open'
ORDER BY o.created_at DESC
LIMIT 50;

Lo que esto demuestra:

• pgbadger clasifica por tiempo total y recuento de llamadas
• Los informes vinculan la duración con la aplicación app=%a cuando log_line_prefix incluye %a
• La evidencia de EXPLAIN cierra el ciclo desde el registro hasta la corrección del plan

Inmersión Profunda

Tabla de Configuración de Registros

Informes Incrementales

pgbadger --incremental --report-per-database \
  --outdir /var/reports/pgbadger/incr \
  /var/log/postgresql/postgresql-18-main.csv

• El archivo de estado incremental evita reprocesar terabytes mensualmente
• Los informes por base de datos ayudan a los equipos de operaciones multitenant

Alternativa a jq para uso único

grep "duration:" /var/log/postgresql/postgresql-18-main.csv \
  | awk -F'duration: ' '{print $2}' | sort -rn | head -20

• Triaje rápido por SSH antes de la ejecución completa de pgbadger durante incidentes

Trampas Comunes

• Incompatibilidad de formato de registro JSON - pgbadger espera CSV o texto estándar, no solo jsonlog sin conversión. Solución: usar csvlog o verificar que la versión de pgbadger admita su formato.
• Registrar cada sentencia - llena el disco, colapsa la E/S. Solución: log_min_duration_statement basado en umbral.
• PII en texto de consulta - los registros capturan enlaces literales en algunas configuraciones. Solución: log_parameter_max_length=0 o redactar informes.
• Confusión de zona horaria - %t vs UTC. Solución: alinear log_timezone con las herramientas de incidentes.
• Ignorar el contexto de caché activa - una consulta lenta puede ser de caché fría. Solución: correlacionar con el tiempo medio vs máximo de pg_stat_statements.

Alternativas

Preguntas Frecuentes

Relacionado

• Conceptos Básicos de Herramientas - configuración de envío de registros
• Conceptos Básicos de Registro - configuración del colector
• Registros CSVlog y JSON - elección de formato
• Conceptos Básicos de EXPLAIN - revisión de planes después del triaje
• pganalyze / OtterTune - alternativa SaaS

Versiones de la pila: Esta página fue escrita para PostgreSQL 18.4 y pgBadger 12.4+.