Odoo · DevOps · Observabilidad
Un stack Odoo sin monitorización funciona bien... hasta que deja de hacerlo, y para entonces el problema lleva horas o días acumulándose silenciosamente en los logs. Montar Promtail + Loki + Grafana sobre los logs existentes es más rápido de lo que parece.
El punto de partida
Logs estructurados, no texto suelto
Antes de pensar en dashboards, hay que asegurarse de que Odoo está generando logs útiles. El nivel de log por defecto (info) es razonable en producción; debug genera demasiado ruido y complica encontrar el problema real.
# odoo.conf
[options]
log_level = info
log_handler = :INFO,werkzeug:WARNING,odoo.sql_db:WARNING
logfile = /var/log/odoo/odoo.loglogrotate para el fichero de Odoo; sin rotación, el log crece sin límite y acaba llenando el disco en despliegues con mucho tráfico.
Recolección
Promtail + Loki: enviar logs sin montar un ELK completo
Loki indexa solo las etiquetas (no el contenido completo de cada línea como Elasticsearch), lo que lo hace mucho más ligero para un stack Odoo de tamaño mediano. Promtail se encarga de leer el fichero de log y enviarlo a Loki con las etiquetas adecuadas.
# promtail-config.yaml
scrape_configs:
- job_name: odoo
static_configs:
- targets: [localhost]
labels:
job: odoo
env: production
__path__: /var/log/odoo/odoo.log# docker-compose.yml (extracto)
services:
loki:
image: grafana/loki:3.0.0
ports: ["3100:3100"]
promtail:
image: grafana/promtail:3.0.0
volumes:
- /var/log/odoo:/var/log/odoo:ro
- ./promtail-config.yaml:/etc/promtail/config.yaml
grafana:
image: grafana/grafana:11.0.0
ports: ["3000:3000"]Qué mirar primero
Métricas y umbrales que de verdad importan
| Señal | Umbral orientativo | Por qué importa |
|---|---|---|
Líneas WARNING/min | Pico > 3x la media horaria | Suele preceder a un ERROR en cascada |
Líneas CRITICAL | Cualquiera | Alerta inmediata, casi siempre afecta a usuarios |
| Tiempo de respuesta de queries lentas | > 1s en el log de odoo.sql_db | Indicador temprano de N+1 o falta de índices |
| Workers ocupados vs disponibles | > 90% sostenido | Señal de que faltan workers o hay peticiones colgadas |
WARNING aislado es normal; lo que indica un problema real es un cambio brusco en la frecuencia respecto al patrón habitual.
Cerrando el círculo
Dashboards y alertas en Grafana
Con Loki como fuente de datos, un dashboard mínimo pero útil combina: un panel de conteo de líneas por nivel (INFO/WARNING/ERROR) agrupado en el tiempo, y un panel de tabla con las últimas líneas ERROR o CRITICAL filtrables por texto.
# Query LogQL de ejemplo: contar WARNING por minuto
sum(count_over_time({job="odoo"} |= "WARNING" [1m]))
# Query LogQL para alertar en errores críticos
count_over_time({job="odoo"} |= "CRITICAL" [5m]) > 0- Alerta de Grafana sobre la query de
CRITICAL: notificación inmediata a Slack o email. - Alerta sobre el pico de
WARNING: notificación de menor prioridad, revisión al inicio del siguiente turno. - Panel aparte con métricas de PostgreSQL (conexiones activas, locks) si el módulo
postgres_exporterestá disponible.
Resumen
No hace falta un stack de observabilidad enterprise para dormir tranquilo con Odoo en producción: con logs bien configurados, Promtail+Loki para centralizarlos y un par de alertas bien calibradas en Grafana sobre CRITICAL y picos de WARNING, la mayoría de incidentes se detectan antes de que los reporte un usuario.