Si tu stack es Odoo → PgBouncer → PostgreSQL, las métricas “que importan” no son 200 gráficos: son un set pequeño que te dice si estás limitado por pool, por DB, por crons o por recursos del host.
Odoo trae servidores HTTP, cron y live-chat integrados (según configuración, multi-thread o multi-process). Odoo
Eso significa que tu observabilidad debe cubrir aplicación + pooler + DB + sistema.
1) Las 4 métricas “de oro” (para abrir el día)
Latencia p95/p99 por endpoint (login, listado, create/write, reportes)
Tasa de errores (HTTP 5xx, timeouts, “pool full”, “deadlock detected”)
Cola de PgBouncer (si hay gente esperando conexión server)
Transacciones largas y lock waits en Postgres (si la DB está “retenida”)
Con esto, ya sueles saber dónde mirar.
2) PgBouncer: el tablero para saber si el cuello es “pool” o “DB”
A) SHOW POOLS; (tu métrica #1)
cl_waiting: cuántos clientes están intentando ejecutar transacción y PgBouncer no pudo asignarles una conexión server “ya”. Si sube sostenido, es señal fuerte de problema (pool chico, o conexiones secuestradas por transacciones largas). Runbooks
maxwait (o similar): el tiempo que lleva esperando el cliente más antiguo (si sube, ya estás degradando experiencia).
Tip: recuerda que PgBouncer crea pools por par (database, user), así que mira qué pool exacto se está ahogando. Runbooks
Alertas prácticas
cl_waiting > 0 sostenido 1–2 min → investiga
maxwait > 1s sostenido → ya impacta UX; >5s es incidente
B) SHOW STATS;
Úsalo para ver throughput y tiempos agregados (picos, caídas, variaciones bruscas). Si tu SHOW POOLS está bien pero el sistema va lento, SHOW STATS te ayuda a confirmar si hay caída de TPS o aumento de tiempo medio.
C) SHOW SERVERS; y SHOW CLIENTS;
Cuando hay cola:
SHOW CLIENTS; te dice quién está esperando
SHOW SERVERS; te dice qué conexiones server están ocupadas
Qué buscas
Muchos server ocupados y cl_waiting subiendo → pool/DB saturada
Pocos server activos pero mucha espera → suele indicar backend lento de abrir conexiones, auth/TLS lento, o límites en pool_size / max_db_connections.
3) Odoo: métricas que casi siempre explican “por qué pasó”
A) Concurrencia real: workers + cron
Si tienes crons pesados, max_cron_threads define cuántos se procesan concurrentemente (default 2). Odoo Development
Métrica clave: backlog/tiempo de ejecución de crons (¿se están solapando? ¿se están “comiendo” el horario?)
Alertas prácticas
Cron que debería durar 2 min y dura 20 min → casi siempre hay locks/long transactions o “trabajo masivo sin batching”
Dos o más crons pesados corriendo a la vez → picos de cl_waiting típicos
B) Errores típicos que debes contar como métricas
PoolError: The Connection Pool Is Full
deadlock detected
timeouts de request/reportes
reconnect loops
Si no los conviertes en contadores/alertas, los ves tarde (cuando el usuario grita).
C) Latencia por tipo de operación
Separa (aunque sea por tags simples):
web interactivo (formularios/listados)
importaciones/masivos
reportes PDF
integraciones (webhooks, APIs)
En Odoo, un “reporte PDF” puede parecer “solo una pantalla”, pero suele ser lo que más CPU/RAM y DB consume.
4) PostgreSQL: lo mínimo para saber si el problema es locks, transacciones largas o recursos
A) pg_stat_activity (tiempo real)
La vista de actividad y estadísticas es parte del sistema de estadísticas acumulativas de PostgreSQL. PostgreSQL
Qué vigilar
Transacciones largas (xact_start muy antiguo)
sesiones esperando locks (wait_event_type, wait_event)
cantidad de sesiones activas vs idle
Alertas prácticas
transacción > 60–120s en horas pico (depende del negocio) → investiga
muchas sesiones esperando locks → revisar el “blocking tree”
B) Locks y deadlocks
métrica: cantidad de bloqueos/esperas por lock
métrica: deadlocks por minuto (si aparece, es diseño/orden de locks o contención alta)
C) Autovacuum / bloat (si el rendimiento “se degrada con los días”)
autovacuum atrasado + tablas grandes con churn = performance que cae lentamente
no es “de hoy para mañana”, pero sí es un clásico de Odoo con actividad alta
5) Sistema operativo: las 6 señales que no debes ignorar
CPU (uso total y “steal” si es VM)
Load average vs cores (si load >> cores de forma sostenida, estás saturando)
I/O wait y latencia de disco (una DB lenta “parece” problema de app)
RAM (swap ≈ desastre para Odoo)
File descriptors (PgBouncer + muchos clientes puede exigirlos)
Network (drops/retransmits entre Odoo↔PgBouncer↔Postgres)
6) Un dashboard mínimo (el que sí usarás)
Panel PgBouncer
cl_waiting, maxwait
sv_active, sv_idle
SHOW STATS (TPS / tiempos agregados)
Panel Odoo
p95/p99 latencia (por “tipo”)
errores (pool full, deadlocks, timeouts)
duración y solape de crons (max_cron_threads importa aquí). Odoo Development
Panel PostgreSQL
sesiones activas / waiting locks (via pg_stat_activity). PostgreSQL
deadlocks
queries lentas (si tienes pg_stat_statements)
autovacuum (tendencia)
Panel Infra
CPU, RAM, swap
I/O wait y latencia
red (drops/retransmits)
7) Lectura rápida: si pasa X, mira Y
Sube cl_waiting → SHOW SERVERS + pg_stat_activity (transacciones largas/locks) Runbooks
No hay cola en PgBouncer pero todo lento → Postgres (I/O, locks, queries) o CPU/RAM del host
Se pone lento a cierta hora → crons solapados (revisar concurrencia y duración; default cron threads 2). Odoo Development
Errores de auth/TLS → métricas de conexiones fallidas en PgBouncer + latencia de handshake