Problemas en funcionamiento#

Esta página reúne los problemas de una instalación de Empowerment Center que ya está en marcha: una BD de cliente que no responde, consultas lentas, trabajos que se quedan esperando, memoria o disco, correo que no sale, tareas programadas que fallan y lo propio de varias instancias. Cada uno se explica como síntoma, causa y solución.

Antes de empezar#

Necesita Administración del sistema para la consola de operación y la auditoría, y acceso al servidor para el registro y la configuración.

La BD de un cliente no responde#

Síntoma. Alerta crítica BD de cliente inaccesible; los documentos de esa conexión fallan; en el Resumen, la conexión dice «No responde: …».

Causa y solución, según el motivo:

Motivo	Qué revisar
«la BD rechaza el usuario o la contraseña de la conexión»	La contraseña ha caducado o se ha cambiado en la BD, o la cuenta está bloqueada. Corríjala en Administración › Conexiones.
«no se llega a la BD (la máquina, el puerto o la red)»	La BD está parada, la máquina o el puerto han cambiado, o un cortafuegos corta el paso desde el servidor de ECenter.
«la BD no responde a tiempo»	La BD está saturada o la red es muy lenta. La comprobación espera 10 s (`ecenter.operations.alerts.connection-timeout`).
«la BD no admite la sesión» (con su SQLSTATE)	La BD rechaza la sesión por otro motivo: sesiones agotadas para el usuario, base en modo restringido. El código SQLSTATE lo dice.
«la contraseña guardada no se puede descifrar…»	Ha cambiado `ECENTER_SECRETS_KEY` (véase Arranque, licencia y acceso).

Arreglado, pulse Comprobar ahora en Alertas: la alerta se resuelve. Una BD de cliente caída no saca al servidor del balanceador: las demás conexiones siguen funcionando.

Los trabajos fallan con «la BD no responde a tiempo» o esperan sesión#

Síntoma. Varios cubos lanzados a la vez sobre la misma conexión fallan, o el Pool de la conexión en el Resumen enseña sesiones esperando; el gadget Pool de las BD de los clientes lo confirma.

Causa. Cada conexión tiene un pool de 5 sesiones por instancia (ecenter.datasource.pool.max-size), que comparten todas las clases de trabajo. Un trabajo sin sesión libre espera 15 s (ecenter.datasource.pool.connection-timeout) y falla aunque haya hilos libres.

Solución. Suba el pool (ECENTER_DATASOURCE_POOL_MAXSIZE) hasta cubrir los trabajos que de verdad coinciden sobre esa conexión, sin pasar de las sesiones que la BD del cliente admite para el usuario de la conexión (multiplicado por las instancias). Si subió los límites de las colas (ecenter.jobs.max-concurrent), suba el pool en proporción.

Las consultas son lentas#

Síntoma. Un documento tarda mucho en calcular, o falla pasado un rato.

Diagnóstico.

En la auditoría, abra la entrada Trabajo de ese cálculo y pulse Incluir junto al trabajo: salen sus consultas con la Duración de cada una.
Abra la consulta más lenta y copie su SQL con Copiar, con los Valores de los parámetros.
Ejecútela en la BD del cliente con su herramienta y pida su plan.

Causas y soluciones frecuentes.

Causa	Solución
Falta un índice en la BD del cliente para las columnas por las que se filtra o se une.	Es cosa del administrador de esa BD: el SQL de la auditoría le dice qué necesita.
La consulta junta tablas por un camino de relaciones más largo del necesario.	Revise las relaciones del metadata (véase Metadata).
Un cubo demasiado grande. Si la BD estima más de 100 000 filas (`ecenter.cube.warn-rows`), se pide confirmación al usuario antes de calcularlo; un cubo trae como mucho 200 000 combinaciones (`ecenter.cube.max-rows`).	Acote la segmentación del documento o use datos conservados con un recálculo programado.
Una sentencia pasa de 5 minutos (`ecenter.querying.timeout`) y el trabajo falla.	Mejore la consulta. Subir el tiempo solo aplaza el problema y ocupa más tiempo una sesión del pool.

El gadget Consultas a las BD de los clientes de la pestaña Actividad enseña el número y el tiempo medio de las consultas: un cambio brusco suele coincidir con un cambio en la BD del cliente.

Los trabajos se quedan esperando o no terminan#

Síntoma. Alerta Trabajos esperando en cola o Trabajo muy largo; los usuarios ven su cálculo «en cola» mucho tiempo.

Diagnóstico. En Administración › Operación › Trabajos, mire qué clase tiene la cola llena y qué ocupa sus huecos (En ejecución, con su usuario y su duración).

Causa	Solución
Unos pocos trabajos muy largos ocupan todos los huecos de su clase.	Decida si Terminar alguno. Si es habitual, suba el límite de esa clase (`ecenter.jobs.max-concurrent.<CLASE>`) y el pool de la conexión.
Un trabajo espera a la BD del cliente (un bloqueo, una sentencia que no acaba).	Terminar cancela la sentencia en la BD. En Oracle sin cortes fuera de banda, una sentencia que espera un bloqueo puede tardar unos segundos en soltarse.
Un usuario ha lanzado muchísimos cálculos (por ejemplo, ha procesado un libro enorme varias veces).	Termine los suyos. Cada usuario tiene un tope de 100 trabajos en cola por clase; el siguiente recibe 429 `TOO_MANY_JOBS`.

Véase Trabajos y colas.

Síntoma. Un usuario recibe «Ya tiene 100 trabajos de este tipo esperando en la cola: espere a que empiecen o cancele alguno desde la Actividad».

Causa. Ha alcanzado el tope de trabajos en cola por usuario y clase (ecenter.jobs.max-queued-per-user).

Solución. Que espere o cancele alguno desde su panel Actividad. Si su trabajo normal lo necesita (un libro con muchísimos documentos), suba el tope.

La memoria está casi llena#

Síntoma. Alerta Memoria casi llena; la tarjeta Memoria del Resumen pasa del 90 % tras la recolección; la aplicación va lenta.

Causa. Lo que calcula cada cubo se queda en la memoria del backend mientras su resultado sigue vivo (30 minutos, ecenter.jobs.result-ttl), y muchos cubos grandes a la vez la llenan.

Solución.

En el gadget Memoria, mire si la cifra tras la recolección sube y baja con el uso (picos de trabajo) o crece sin bajar.
Si son picos, suba el límite de memoria del contenedor (ECENTER_BACKEND_MEMORY, 4 GB por defecto): la JVM toma el 75 % de él. Sin límite de contenedor, fije el montón con JAVA_TOOL_OPTIONS="-Xmx3g -XX:+ExitOnOutOfMemoryError".
Si crece sin bajar durante días, reinicie el backend y avise a Action Ware con la gráfica.

ECenter no se reinicia solo por memoria: reiniciarlo le corresponde a usted o al orquestador.

Queda poco espacio en disco#

Síntoma. Alerta Poco espacio en disco (menos de 1 GB en el directorio temporal del backend).

Causa y solución.

Qué ocupa	Qué hacer
Los ficheros de las subidas de datos externos (la carpeta `ecenter-external` del directorio temporal)	Se borran solos al caducar cada subida. Si es habitual, dé más disco o mueva la carpeta con `ECENTER_EXTERNALDATA_UPLOADDIRECTORY`.
Los registros de los contenedores	`deploy/compose.yaml` los rota (5 × 50 MB por servicio). Si ha cambiado el controlador de registros, revise su rotación.
La BD propia (en su propio volumen)	La auditoría de las consultas es lo que más crece: acorte su plazo (véase Auditoría).

El disco que se vigila se cambia con ecenter.operations.alerts.disk-path y el umbral con disk-free-min.

No sale el correo#

Síntoma	Causa	Solución
Políticas dice Servidor de correo: Sin configurar (spring.mail.host)	No hay `SPRING_MAIL_HOST`. El registro lo dice una vez: «Hay avisos de operación por correo pero no hay servidor de correo (spring.mail.host)».	Configure el servidor (véase Correo).
Alerta crítica Sin servidor de correo	El servidor no responde en 10 s mientras hay suscripciones o alertas de datos activas.	Compruebe la máquina, el puerto, el usuario y la contraseña, y que el cortafuegos deja salir al servidor SMTP.
No llegan los avisos de la operación o de la planificación	El modo es `NONE` (por defecto) o no hay destinatarios.	Configure `ecenter.operations.notifications.` o `ecenter.scheduling.notifications.`.
Una suscripción no llega a un destinatario	Su dominio no está en `ecenter.distribution.allowed-domains`, el destinatario no tiene correo, o el mensaje está en su carpeta de correo no deseado.	Revise la entrada Entrega de la auditoría: dice el estado y el motivo.
Alerta Envíos que fallan; una suscripción dice que se pausó	Tres envíos seguidos han fallado por un error del sistema y se ha pausado sola, avisando a su responsable.	Arregle la causa (el correo, el navegador sin interfaz, el documento) y que el responsable la reanude.
Los correos tardan o se pierden en picos	El servidor SMTP limita los envíos.	Pida al administrador del correo que admita la dirección de ECenter, o reduzca el número de destinatarios.

El navegador sin interfaz no responde#

Síntoma. Alerta El navegador sin interfaz no responde; los envíos en PDF de gráficos, mapas y páginas fallan.

Causa. El contenedor de Chromium está parado, sin memoria o no se llega a él.

Solución. Compruébelo con docker compose -f deploy/compose.yaml ps y su registro; dele más memoria si se reinicia (ECENTER_RENDER_MEMORY). Al volver, la alerta se resuelve sola. Véase Instalación.

Una tarea programada falla#

Síntoma	Causa	Solución
«… ya no existe o no está habilitado. Guarde la tarea con otro usuario»	La tarea se ejecuta en nombre de quien la guardó, y ese usuario ya no puede.	Ábrala, pulse Modificar… y guárdela con un usuario habilitado.
No se hizo en el historial	La ejecución anterior seguía en marcha.	Si es habitual, la tarea dura más que su intervalo: espacie la programación o acelérela.
Una tarea se queda En marcha para siempre tras retirar una instancia	Sus ejecuciones eran de esa instancia, que no ha vuelto.	Arranque una instancia con el mismo `ECENTER_INSTANCE_NAME`: las da por interrumpidas.
El procedimiento falla con un error de la BD	El procedimiento no existe, cambió su firma, falta un permiso o el error es suyo.	El paso del historial dice el mensaje de la BD. En PostgreSQL, lo que confirmara antes de fallar queda confirmado.
No se lanza nada a su hora	No hay licencia válida, o `ecenter.scheduling.enabled` es `false`.	Las atrasadas se ejecutan una vez al volver.

Véase Planificación.

Eventos sin procesar#

Síntoma. Alerta Eventos sin procesar: por ejemplo, la auditoría ha dejado de anotar.

Causa. Un módulo que escucha los eventos de otro ha fallado al procesarlos (la BD propia llena, un fallo puntual) o la instancia se paró a medias.

Solución. Arregle la causa y pulse Volver a entregar… en la sección Eventos sin procesar de Alertas (véase Alertas operativas). Al reiniciar, el servidor también los vuelve a entregar. Ninguno se pierde.

Con varias instancias#

Síntoma	Causa	Solución
Un usuario lanza un cálculo y no lo encuentra («No existe el trabajo … (o ha caducado)», 404), o la API responde 404 `RESULT_NOT_FOUND`	El proxy ha mandado la petición a otra instancia. Los trabajos y sus resultados viven en la memoria de la instancia que los calcula.	Configure la afinidad del proxy por la cookie de sesión, la cabecera `Authorization` y `X-ECenter-Embed-Session` (véase Instalación).
La consola enseña trabajos distintos según el momento	Cada lectura la atiende una instancia distinta.	La cabecera de la consola dice qué instancia ve; con afinidad, siempre la misma.
Alertas de una instancia que ya no existe	Se renombró o se retiró.	Se resuelven solas a los 30 minutos sin verse. Dé nombres fijos con `ECENTER_INSTANCE_NAME`.

Tras actualizar de versión#

Síntoma. Durante un rato tras actualizar, «¿Quién usa…?» o la validación de contenido no dan todo lo que deberían.

Causa. ECenter reindexa al arrancar lo que usa cada libro y cada publicación, por lotes.

Solución. Espere. La métrica ecenter.usage-index.pending dice lo que queda.