PostgreSQL
Logging y auditoría
Configuración de logs, formatos estructurados, duración de consultas, conexiones, errores y auditoría sin exponer datos sensibles ni generar ruido excesivo.
- Última actualización
- Actualizada
- Nivel
- Aplicación
PostgreSQL
Configuración de logs, formatos estructurados, duración de consultas, conexiones, errores y auditoría sin exponer datos sensibles ni generar ruido excesivo.
Los logs deben permitir reconstruir qué ocurrió sin almacenar passwords, tokens ni datos personales innecesarios. Auditoría y debugging comparten evidencia, pero no tienen el mismo objetivo ni retención.
logging operativo
→ diagnosticar errores, waits y rendimiento
auditoría
→ demostrar quién hizo qué, cuándo y sobre qué datoUn log de statements no es automáticamente un audit trail confiable.
Prefiere logs estructurados o csvlog/jsonlog cuando la versión lo soporte. Incluye campos como:
Formato estructurado facilita parsing y evita regex frágiles.
En texto puede incluir:
%m [%p] %q%u@%d app=%a client=%h tx=%xLa sintaxis exacta debe revisarse para la versión. No agregues campos sin considerar volumen.
Opciones principales:
log_min_duration_statement: registra statements que superan umbral.log_statement: none, ddl, mod, all.log_duration / log_statement_stats en contextos específicos.log_min_error_statement: statement asociado a errores.Registrar todo en producción puede filtrar PII y saturar I/O.
Puede registrar planes de queries lentas:
LOAD 'auto_explain';
SET auto_explain.log_min_duration = '1s';
SET auto_explain.log_analyze = on;
SET auto_explain.log_buffers = on;ANALYZE y options detalladas añaden overhead. Configura sampling y úsalo con cautela.
El SQL parametrizado puede aparecer normalizado o con valores según driver/configuración. No intentes obtener valores sensibles a cualquier costo. Usa tracing de aplicación con redacción y sampling.
Clasifica errores estables:
23505 unique violation.23503 FK violation.40001 serialization failure.40P01 deadlock.57014 query canceled.Agrupa por código, endpoint y release para distinguir bugs de conflictos esperados.
log_lock_waits registra waits que superan deadlock_timeout. Es útil para contención, pero necesita query/transaction context y correlación con blockers.
Opciones como:
log_checkpoints.log_autovacuum_min_duration.log_connections / log_disconnections.log_temp_files.Ayudan a explicar I/O, maintenance y churn. Ajusta umbrales para evitar ruido.
Para cambios sensibles necesitas registrar:
Un pool usa el mismo role técnico para muchos usuarios; la aplicación debe pasar identidad de negocio de forma segura, por ejemplo con SET LOCAL app.actor_id validado.
Puede garantizar cobertura de writes directos, pero genera volumen y WAL. Evita almacenar:
Define columnas excluidas, particionamiento y acceso append-only.
La extensión puede producir auditoría detallada de acciones y objetos. Requiere instalación/configuración y puede generar mucho volumen. Evalúa versión, proveedor, performance y retención.
No reemplaza una tabla de auditoría de negocio con actor semántico.
Si el mismo owner puede modificar datos y borrar auditoría, la evidencia es débil. Controles:
PostgreSQL solo no garantiza inmutabilidad ante superuser comprometido.
Aplica allowlist de campos, no una lista incompleta de secretos. En logs de aplicación:
email → hash/ID interno cuando sea suficiente
card/token/password → nunca
query values → sampling/redacciónCumple minimización y políticas legales.
Separa:
Define rotación, compresión, storage, búsqueda y borrado verificable.
La aplicación puede establecer:
SET LOCAL application_name = 'orders-api';
SET LOCAL app.request_id = '...';application_name es estándar visible; custom settings pueden consultarse desde triggers. No uses valores no confiables sin longitud/validación.
Conserva:
No alteres logs originales durante análisis.
log_statement=all permanente.Rendimiento y optimización de PostgreSQL convierte observaciones en hipótesis medibles y cambios reversibles.