Monitoreo de Odoo: Logs, Alertas y Diagnóstico

Un sistema de monitoreo efectivo detecta problemas antes de que afecten a los usuarios. Odoo genera logs detallados que, combinados con herramientas externas, permiten identificar cuellos de botella, errores recurrentes y tendencias de rendimiento. Este artículo cubre cómo configurar, analizar y actuar sobre la información de monitoreo de tu instalación Odoo.

1. Niveles de Log en Odoo

Odoo utiliza el sistema de logging de Python con varios niveles de detalle. En odoo.conf puedes configurar log_level con valores como debug, info, warn, error, y critical. El nivel warn es el recomendado para producción porque equilibra visibilidad de problemas con rendimiento. Para diagnosticar un problema específico, incrementa temporalmente el nivel a info o debug.

Los logs de Odoo se escriben en el archivo definido por logfile en odoo.conf y también se envían a stdout/stderr del proceso. Cada línea incluye la marca de tiempo, el nivel de severidad, el nombre del logger y el mensaje. Los logs de debug incluyen información adicional como parámetros de funciones y resultados de búsquedas ORM.

2. Configuración de Logrotate

Sin control, los logs de Odoo pueden crecer indefinidamente y llenar el disco. Configura logrotate para rotar los archivos diariamente, mantener 30 días de historial, comprimir los archivos antiguos, y notificar a Odoo para que reinicie el manejo del archivo de log.

/opt/odoo/logs/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 odoo odoo
    sharedscripts
    postrotate
        systemctl reload odoo > /dev/null 2>&1 || true
    endscript
}

3. Logs de PostgreSQL

PostgreSQL genera sus propios logs que son igual de importantes. Configura log_min_duration_statement para registrar consultas lentas, log_statement para controlar qué operaciones se registran, y log_line_prefix para incluir información útil como el usuario, la base de datos y la dirección IP en cada línea de log.

Analiza los logs de PostgreSQL con pgBadger para generar reportes HTML interactivos con estadísticas de rendimiento, consultas más lentas, distribución de tiempos de respuesta y gráficas de tendencias.

4. Sentry para Errores en Odoo

Sentry captura errores en tiempo real con contexto detallado incluyendo stack trace, variables locales, y estado de la sesión. Instala el SDK de Sentry en tu entorno Odoo y configúralo para capturar excepciones no manejadas. Sentry agrupa errores similares, rastrea si son nuevos o recurrentes, y envía alertas cuando aparecen por primera vez.

# En odoo.conf o en el init de tu módulo
sentry_dsn = https://[email protected]/proyecto
sentry_enabled = True
sentry_environment = production
sentry_logging_level = warn

5. Health Checks y Endpoints de Monitoreo

Implementa endpoints de health check en Odoo que verifiquen la conectividad con PostgreSQL, la disponibilidad del filestore, el estado de los workers, y la latencia de respuesta. Estos endpoints se pueden usar con herramientas de monitoreo externas como Uptime Robot, Pingdom o Prometheus.

6. Métricas de Rendimiento

Las métricas clave para monitorear incluyen tiempo de respuesta promedio por petición, número de peticiones por segundo, uso de memoria de cada worker, número de conexiones activas a PostgreSQL, tamaño del filestore, y tasa de errores HTTP (500, 502, 504).

7. Alertas y Notificaciones

Configura alertas automáticas para condiciones críticas: uso de memoria superior al 80 por ciento, disco duro lleno al 90 por ciento, tiempo de respuesta superior a 5 segundos, errores HTTP recurrentes, y caída del servicio. Usa herramientas como Grafana, Prometheus o Nagios para gestionar las alertas.

8. Análisis de Logs con Herramientas Externas

ELK Stack (Elasticsearch, Logstash, Kibana) centraliza y analiza logs de múltiples fuentes. Fluentd es una alternativa más ligera. Ambas herramientas permiten buscar, filtrar y visualizar logs de Odoo y PostgreSQL en una interfaz web unificada.

9. Monitoreo de Workers

Los workers de Odoo son procesos independientes que pueden fallar o quedarse bloqueados. Monitorea su estado con ps aux, verifica que el número de workers activos sea el configurado, y configura systemd para reiniciar automáticamente los workers que fallen.

10. Diagnóstico de Problemas Comunes

Los problemas más comunes incluyen workers sin memoria (solución: reducir workers o aumentar RAM), consultas lentas de PostgreSQL (solución: crear índices), archivos de log gigantes (solución: configurar logrotate), y certificados SSL expirados (solución: renovar con certbot). Mantén un runbook de troubleshooting con los procedimientos para resolver cada tipo de problema.

11. Auditoría de Seguridad

Los logs de Odoo registran inicios de sesión, creaciones y modificaciones de registros, cambios de configuración, y acceso a datos sensibles. Revisa periódicamente estos logs para detectar accesos no autorizados, cambios sospechosos en configuración, y patrones de uso anómalos que puedan indicar problemas de seguridad.

12. Documentación de Incidencias

Mantén un registro de todas las incidencias con fecha, duración, causa raíz, solución aplicada y tiempo de resolución. Esta documentación te ayuda a identificar patrones recurrentes, justificar inversiones en infraestructura, y capacitar al equipo de soporte con ejemplos reales.

Conclusión

El monitoreo no es un lujo, es una necesidad para cualquier instalación Odoo en producción. Implementa logs estructurados, alertas proactivas y un plan de respuesta a incidentes. Los problemas detectados tempranamente son mucho más fáciles y baratos de resolver que los que explotan cuando los usuarios ya están afectados.

13. Monitoreo de Recursos del Sistema

Las metricas clave del sistema incluyen: uso de CPU por proceso, consumo de memoria RAM y swap, espacio en disco utilizado, trafico de red, y numero de conexiones abiertas. Estas metricas se pueden monitorear con herramientas como htop, iostat, vmstat, y netstat.

El uso de CPU de los workers de Odoo no debe superar consistentemente el 80%. Si el CPU esta saturado, significa que necesitas mas workers o optimizar las consultas de base de datos. Los picos breves de CPU son normales, pero el uso sostenido alto indica un problema.

El consumo de memoria debe ser estable a lo largo del tiempo. Si ves un crecimiento continuo de memoria sin liberacion, probablemente hay un memory leak en un modulo personalizado. Usa tracemalloc o objgraph para identificar la fuente del leak.

El espacio en disco debe monitorearse con alertas cuando se supere el 75%. Los archivos que mas crecen son los logs de Odoo y PostgreSQL, los archivos temporales, y el filestore de adjuntos. Configura logrotate y scripts de limpieza para mantener el disco bajo control.

14. Alertas Proactivas

Configura alertas automaticas para condiciones que requieren atencion inmediata. Las alertas criticas incluyen: servicio Odoo caido, base de datos no accesible, disco duro al 90%, memoria agotada (OOM killer activado), y certificado SSL por expirar en menos de 15 dias.

Las alertas de advertencia incluyen: tiempo de respuesta superior a 3 segundos, uso de CPU superior al 80% por mas de 5 minutos, mas de 100 conexiones activas a PostgreSQL, y tasa de errores HTTP superior al 1%.

Usa herramientas de monitoreo como Grafana con Prometheus para crear dashboards visuales que muestren las metricas en tiempo real. Los dashboards facilitan la identificacion de patrones y tendencias que no son evidentes en los logs de texto.

Configura canales de notificacion segun la criticidad de la alerta: Slack o Teams para advertencias, email para informacion, y llamada telefonica o SMS para alertas criticas que requieren respuesta inmediata fuera del horario laboral.

15. Monitoreo de Rendimiento de Red

El rendimiento de la red es critico para la experiencia del usuario. Mide la latencia entre el cliente y el servidor con ping, el throughput con iperf, y la calidad de la conexion con mtr. Los usuarios con latencia superior a 200ms experimentaran lentitud significativa en la interfaz de Odoo.

El ancho de banda disponible afecta directamente el tiempo de carga de las paginas. Para usuarios con conexiones lentas, habilita la compresion gzip en Nginx, optimiza las imagenes para web, y usa lazy loading para cargar contenido de forma diferida.

Los problemas de red mas comunes incluyen: paquetes perdidos que causan reconexiones TCP, jitter que afecta las conexiones WebSocket de Odoo, y MTU mismatch que fragmenta los paquetes grandes. Usa traceroute y pathping para diagnosticar problemas de red.

Para oficinas remotas con conexiones lentas, considera implementar un proxy local de Odoo o un sistema de cache que almacene los assets estaticos localmente. Esto reduce la cantidad de datos que se transfieren por la conexion lenta.

16. Analisis de Trafico de Red

Herramientas como tcpdump y Wireshark permiten capturar y analizar el trafico de red entre el cliente y el servidor. Esto es util para diagnosticar problemas de rendimiento de red, detectar paquetes corruptos, y verificar que la compresion gzip esta funcionando correctamente.

Para analisis automatizado de trafico, usa tcpreplay para reproducir capturas de trafico y medir el rendimiento bajo diferentes condiciones de red. Esto te permite simular escenarios como conexiones lentas, alta latencia, o paquetes perdidos.

El monitoreo de trafico de red debe ser continuo para detectar problemas intermitentes que solo ocurren en condiciones especificas como horas pico o tormentas electricas. Configura alertas que se activen cuando la latencia o la tasa de perdida de paquetes superen umbrales criticos.

17. Monitoreo de Rendimiento de Aplicacion

Ademas del monitoreo de infraestructura, necesitas monitorear el rendimiento de la aplicacion Odoo. Las metricas de aplicacion incluyen: tiempo promedio de respuesta por tipo de peticion, numero de errores por tipo, tasa de exito de operaciones de base de datos, y uso de recursos por worker.

El tiempo de respuesta de las vistas de lista debe ser inferior a 2 segundos para 80 registros. Si es superior, significa que hay consultas lentas o campos compute costosos que necesitan optimizacion. Monitorea el tiempo de respuesta de las vistas mas usadas por los usuarios.

El numero de errores HTTP 500 (Internal Server Error) debe ser cero en produccion. Si ves errores 500, revisa los logs de Odoo para encontrar la causa raiz. Los errores 502 (Bad Gateway) indican que Nginx no puede conectar con Odoo, lo que puede ser causado por workers sin memoria o servicios caidos.

El uso de recursos por worker se puede monitorear con herramientas de profiling como py-spy que adjuntan a procesos en ejecucion y muestran el consumo de CPU y memoria en tiempo real. Esto te permite identificar workers que consumen mas recursos que otros y diagnosticar la causa.

18. Analisis de Logs con Herramientas de IA

Las herramientas de analisis de logs con inteligencia artificial pueden detectar patrones anomalous que los humanos pasan por alto. Herramientas como Elastic SIEM, Splunk o Datadog usan machine learning para aprender el patron normal de los logs y alertar cuando se detectan anomalías.

Los patrones anomalous incluyen: picos inusuales de errores, tiempos de respuesta que crecen gradualmente, patrones de acceso inusuales que pueden indicar un ataque, y cambios en el comportamiento de los cron jobs.

Para configurar el analisis de logs con IA, alimenta la herramienta con al menos 30 dias de logs historicos para que aprenda el patron normal. Despues, configura alertas para desviaciones significativas del patron aprendido.

El analisis predictivo puede anticipar problemas antes de que ocurran. Por ejemplo, si el tiempo de respuesta crece gradualmente, la herramienta puede predecir cuando superara el umbral critico y alertar con tiempo suficiente para tomar medidas preventivas.

19. Integracion con Herramientas de APM

Application Performance Monitoring (APM) es una practica esencial para mantener la calidad del servicio en produccion. Herramientas como New Relic APM, Datadog APM, o Elastic APM monitorean automaticamente el rendimiento de la aplicacion y proporcionan insights detallados sobre cuellos de botella.

El APM para Odoo monitorea: tiempo de respuesta de cada peticion HTTP, consumo de base de datos por cada peticion, uso de memoria y CPU por worker, errores y excepciones, y dependencias externas como servicios de terceros.

Los dashboards de APM muestran graficas de tendencias que permiten detectar degradaciones graduales del rendimiento antes de que afecten a los usuarios. Por ejemplo, si el tiempo de respuesta promedio crece 10% en una semana, el dashboard lo mostrara como una tendencia ascendente.

Las alertas de APM se configuran para notificar al equipo de operaciones cuando las metricas superan umbrales criticos. Las alertas pueden enviarse por email, Slack, PagerDuty, o cualquier canal de notificacion configurado.

20. Estrategia de Respuesta a Incidentes

Implementa un proceso formal de respuesta a incidentes que defina los pasos a seguir cuando ocurre un problema critico en produccion. El proceso debe incluir: deteccion del incidente, clasificacion de severidad, notificacion al equipo, diagnostico, resolucion, y post-mortem.

Los niveles de severidad deben definirse claramente: Severidad 1 (sistema no disponible), Severidad 2 (funcionalidad critica degradada), Severidad 3 (funcionalidad no critica afectada), y Severidad 4 (problema menor sin impacto en usuarios). Cada nivel tiene un tiempo de respuesta objetivo diferente.

Para incidentes de Severidad 1, el tiempo de respuesta objetivo no debe exceder los 15 minutos fuera del horario laboral. Implementa un sistema de guardia donde un miembro del equipo este disponible 24/7 para responder a incidentes criticos. Usa herramientas como PagerDuty para gestionar las guardias.

Despues de cada incidente, realiza un post-mortem que documente la linea de tiempo del incidente, la causa raiz, las acciones correctivas implementadas, y las mejoras preventivas para evitar incidentes similares. El post-mortem se comparte con todo el equipo para fomentar el aprendizaje organizacional.

21. Estrategia de Revision de Logs

La revision sistematica de logs es una practica preventiva que detecta problemas antes de que escalen a incidentes criticos. Establece un proceso de revision diaria donde un miembro del equipo revise los logs de Odoo, PostgreSQL y Nginx en busca de errores, warnings, y patrones anomalous. Los logs de errores recurrentes deben investigarse y resolverse antes de que afecten a multiples usuarios.

Para facilitar la revision de logs, crea dashboards en Grafana o Kibana que muestren los metricas clave de logs: numero de errores por hora, tipos de errores mas frecuentes, y usuarios afectados. Los dashboards permiten identificar tendencias y patrones que no son evidentes en los logs de texto.

Los logs de acceso deben revisarse periodicamente para detectar patrones de uso inusuales como accesos fuera del horario laboral, multiples intentos de login fallidos, o accesos desde ubicaciones geograficas inesperadas. Estos patrones pueden indicar intentos de acceso no autorizados.

Mantene un registro de las revisiones de logs con la fecha, el revisor, los problemas encontrados, y las acciones tomadas. Este registro demuestra el cumplimiento de las politicas de seguridad y proporciona un historial para diagnosticar problemas futuros.

22. Monitoreo de Seguridad de la Aplicacion

El monitoreo de seguridad va mas alla del firewall y los logs de acceso. Implementa WAF (Web Application Firewall) como ModSecurity o CloudFlare para detectar y bloquear ataques web como SQL injection, XSS, y CSRF. El WAF inspecciona las peticiones HTTP entrantes y bloquea las que contienen patrones maliciosos.

Configura alertas para patrones de acceso sospechosos como multiples intentos de login fallidos, accesos a endpoints sensibles desde IPs desconocidas, y descargas masivas de datos. Estos patrones pueden indicar un ataque en curso que requiere respuesta inmediata.

Implementa un sistema de logs de seguridad centralizado que agregue logs de Odoo, Nginx, PostgreSQL, y el sistema operativo en una sola ubicacion. Usa herramientas como ELK Stack o Splunk para analizar los logs de seguridad y detectar amenazas que cruzan multiples capas del sistema.

Realiza auditorias de seguridad trimestrales que revisen las configuraciones, los permisos, las dependencias de software, y los patrones de acceso. Las auditorias de seguridad identifican vulnerabilidades antes de que los atacantes las exploten y proporcionan recomendaciones de mejora priorizadas.