Monitorear un ERP en producción

La mayoría de los equipos que ejecutan Odoo en producción saben cuándo el sistema va lento. Lo que rara vez saben es cuándo empezó a ir lento, qué peticiones lo causaron y si el problema afectó a las operaciones del negocio o simplemente molestó a unos pocos usuarios. Esa brecha entre la sensación y la evidencia es lo que la monitorización debería cerrar.

La observabilidad en un ERP no es lo mismo que la monitorización genérica de aplicaciones. Las señales que importan están ligadas a las operaciones de negocio, y los umbrales que importan están ligados a las consecuencias para el negocio.

Monitorización operativa frente a monitorización de negocio

La monitorización operativa responde si el sistema está funcionando. La monitorización de negocio responde si el sistema está haciendo lo que debe. Ambas importan, pero los equipos suelen invertir mucho en la primera y descuidar la segunda.

Señales operativas que vale la pena seguir:

• Tasa de errores HTTP y códigos de estado en los endpoints de Odoo.
• Número de workers de Odoo, activos frente a inactivos, para detectar saturación del pool.
• Utilización de conexiones de PostgreSQL.
• Uso de memoria, CPU y disco por contenedor.

Señales de negocio que vale la pena seguir:

• Tasa de fallos de queue jobs y tiempo medio de procesamiento por canal.
• Errores de cron jobs y tiempo desde el último éxito.
• Latencia de confirmación de pedidos desde la creación hasta el estado confirmado.
• Tasa de fallos en integraciones externas: EDI, pagos y APIs de transporte.

Las señales operativas dicen que el sistema está degradado. Las señales de negocio dicen si esa degradación está afectando a lo que le importa a la empresa.

Las señales de rendimiento que realmente importan

No todas las métricas merecen atención. Promediar el tiempo de respuesta de todas las rutas oculta los peores casos. Una confirmación de pedido de venta que tarda ocho segundos es invisible cuando se promedia con decenas de peticiones rápidas. Hay que seguir el percentil 95 y el 99 de los cinco o diez endpoints que más depende el negocio, y hacerlo por separado.

La saturación de workers es la otra señal de alto valor. Odoo funciona con un pool fijo. Cuando todos los workers están ocupados con peticiones lentas, las nuevas peticiones se encolan o fallan. Un pool saturado suele aparecer antes de que los usuarios se quejen, y casi siempre lo causa un pequeño número de endpoints lentos o una acción programada de larga duración que retiene una conexión.

Los slow query logs de PostgreSQL son la herramienta más infrautilizada en las operaciones de Odoo. La mayoría de los problemas de rendimiento en la base de datos no son causados por consultas complejas, sino por la misma consulta moderadamente costosa ejecutándose miles de veces por hora.

Construir dashboards de Grafana que cuenten una historia

Un dashboard útil responde una pregunta, no solo muestra datos. Los dashboards de Odoo más efectivos están organizados alrededor de flujos operativos, no de componentes del sistema.

Tres dashboards cubren la mayoría de las necesidades en producción. Un resumen de salud del sistema con estado de workers, tasa de errores y resumen de queue jobs es lo que un ingeniero de guardia abre primero. Un dashboard de rendimiento con tiempos de respuesta por endpoint, conteo de slow queries y profundidad de la cola de workers es lo que se usa durante la investigación de un incidente. Un dashboard de salud del negocio con tasa de fallos de queue jobs por canal, estado de los cron jobs y tasa de éxito de las integraciones es lo que revisa a diario el responsable técnico.

El error más común es combinar todo esto en un único dashboard cargado de paneles que nadie lee.

Umbrales de alerta anclados en el impacto de negocio

Los umbrales genéricos generan ruido. Una alerta que salta porque el CPU llegó al sesenta por ciento durante un cierre contable no es útil. Una alerta que salta porque la tasa de fallos de queue jobs para facturas salientes superó el diez por ciento durante quince minutos consecutivos sí es un problema real.

Umbrales que vale la pena configurar:

• Tasa de fallos de queue jobs por encima de un porcentaje definido durante varios minutos, por canal.
• Cualquier cron job que no haya completado con éxito en el doble de su intervalo esperado.
• Percentil 95 del tiempo de respuesta para confirmación de pedidos superando un umbral definido por el negocio.
• Conteo de slow queries por minuto en PostgreSQL por encima de la línea base en operaciones normales.
• Ocupación del pool de workers por encima del noventa por ciento durante más de cinco minutos.

Cerrar la brecha entre sensación y evidencia

El coste real de una observabilidad deficiente en un ERP no es el tiempo que se pierde investigando incidentes. Son las decisiones que se toman sin datos. Los equipos añaden servidores sin saber si el problema es de concurrencia o de volumen de consultas. Los ingenieros optimizan los endpoints equivocados porque los promedios ocultan los casos extremos. Los responsables de negocio escalan basándose en percepciones porque no hay dashboards que mostrarles.

Una buena monitorización no previene todos los problemas. Reduce el tiempo entre que aparece un problema y que el equipo lo entiende lo suficiente como para actuar.