En las siguientes secciones se detallan los problemas que suelen identificar mediante comprobaciones posteriores a la actualización o que se observan inmediatamente después de una actualización.

Para obtener información sobre las comprobaciones previas y posteriores a la actualización, consulte la sección Referencia de actualización.

Servicios que no se están ejecutando

No se puede acceder a la interfaz de usuario web de RMT y el comando rmtadmin status indica que los servicios necesarios se han detenido.

Se detecta mediante comprobaciones posteriores a la actualización #1, #2, #16

Para solucionar este problema, siga estos pasos:

Para Linux, use el siguiente comando:

sudo -u tabrmt-master XDG_RUNTIME_DIR=/run/user/$(id -u tabrmt-master) systemctl --user start tabrmt-master

Para Windows, use el siguiente comando:

Start-Service TableauResourceMonitoringTool

Consulte los registros de servicio en el directorio de registros en busca de errores de inicio.

PostgreSQL no acepta conexiones

Cuando la interfaz de usuario web muestra errores de base de datos y los datos no se almacenan.

Se detecta mediante comprobaciones posteriores a la actualización #5c, #6

Para solucionarlo, compruebe lo siguiente:

• Compruebe que el servicio PostgreSQL se está ejecutando

• Compruebe si hay errores de inicio en los registros de PostgreSQL en el directorio de datos

• Compruebe que el puerto de la base de datos (valor predeterminado 5555) no está bloqueado por otro proceso

RabbitMQ no responde

Cuando los agentes se muestran como desconectados y no aparecen nuevos datos de supervisión.

Se detecta mediante comprobaciones posteriores a la actualización #5b, #7, #9

Para solucionarlo, compruebe lo siguiente:

• RabbitMQ puede tardar entre 30 y 60 segundos en inicializarse por completo después de la actualización: espere y vuelva a comprobar

• Compruebe que el proceso Erlang/beam se está ejecutando

• Compruebe si hay alarmas de recursos de RabbitMQ (espacio en disco < 10 GB hace que se bloquee la publicación de mensajes)

• Compruebe que el archivo de cookies de Erlang existe y tiene los permisos correctos

Retraso en la cola de mensajes

Los datos aparecen retrasados en la interfaz de usuario web de RMT y los dashboards muestran métricas obsoletas.

Se detecta mediante la comprobación posterior a la actualización #8.

Es normal que se produzca un retraso inmediatamente después de la actualización, ya que los agentes se vuelven a conectar y reenvían los datos almacenados en búfer. Para solucionarlo, haga lo siguiente:

• Supervisar con “rmtadmin status”: el trabajo pendiente debería despejarse en un plazo de 15 a 30 minutos.

• Si el trabajo pendiente persiste, compruebe que todos los servicios del agente se estén ejecutando y conectados

Trabajadores del servidor de RMT que no consumen (datos no ingeridos después de la actualización)

Informe de todos los servicios de RMT En ejecución, la comprobación posterior a la actualización pasa los servicios/puertos/conectividad, pero la interfaz de usuario web no muestra datos nuevos y los agentes aparecen como “Problema de conexión”. “rmtadmin status” muestra una o varias colas con mensajes que se acumulan, pero con un recuento de consumidores de **0**.

Esto ocurre cuando los trabajadores en segundo plano del servidor de RMT comienzan pero no logran volver a enlazar sus canales de consumidor de RabbitMQ después de una actualización en contexto. Los agentes publican correctamente, los mensajes se acumulan en RabbitMQ y nada llega a la base de datos.

Se detecta mediante la comprobación posterior a la actualización #8a

Para solucionarlo, haga lo siguiente:

• Reinicie el maestro: `rmtadmin restart`

• Espere ~ 60 segundos, luego vuelva a ejecutar `rmtadmin status`: las colas varadas ahora deberían mostrar “Consumidores = 1” y el retraso debería agotarse en unos minutos

• Si las colas siguen mostrando “Consumidores = 0” después del reinicio, inspeccione el registro en segundo plano para ver si hay excepciones de enlace al consumidor:

• Windows: “C:\Program Files\Tableau\Tableau Resource Monitoring Tool\master\logs\background\*.log”

• Linux: “/var/opt/tableau/tabrmt/master/logs/background/*.log”

• Busque en el registro “exception”, “channel” o “binding failed”

Desajuste de modo FIPS

Cuando los servicios no logran iniciarse con errores criptográficos o TLS.

Se detecta mediante la comprobación posterior a la actualización #11

Para solucionarlo, haga lo siguiente:

• Asegúrese de que la configuración FIPS a nivel del sistema operativo coincida con la configuración RMT (“isFIPSEnabled” en setup.json)

• Linux: compruebe `/proc/sys/crypto/fips_enabled`

• Windows: compruebe “HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled”

Daños del archivo de configuración

Los servicios no se inician con errores de análisis JSON.

Se detecta mediante la comprobación posterior a la actualización #3

Para solucionarlo, haga lo siguiente:

• Valide el archivo de configuración: `python3 -c "import json; json.load(open('config.json'))"`

• Restauración a partir de la copia de seguridad previa a la actualización (se recomienda realizar antes de cada actualización)

Certificado SSL caducado o a punto de expirar

Cuando el navegador web muestra advertencias de certificado y los agentes no se pueden conectar, se produce un error de TLS.

Se detecta mediante comprobaciones posteriores a la actualización #10, #13

Para solucionarlo, haga lo siguiente:

• Renueve el certificado HTTPS y actualícelo usando `rmtadmin set-ssl-certificate`

• Para certificados RabbitMQ, reemplace los archivos PEM en el directorio certificates y reinicie el servicio

Espacio en disco agotado

Cuando los servicios se bloquean o no escriben datos y errores de base de datos en los registros.

Se detecta mediante la comprobación posterior a la actualización #14, las comprobaciones previas a la actualización #2 #2b

Para solucionarlo, haga lo siguiente:

• Libere espacio en disco o expanda el volumen

• Ejecute la limpieza de la base de datos: asegúrese de que “db:cleanup:type” esté establecido en “Purge” (no “None”) en config.json

• Archivar o eliminar archivos de registro antiguos

Errores FATALES o CRÍTICOS en los registros

Comportamiento inesperado o inestabilidad del servicio después de la actualización.

Se detecta mediante la comprobación posterior a la actualización #15

Para solucionarlo, haga lo siguiente:

• Los errores del tipo “Broker inalcanzable” inmediatamente después de la actualización suelen ser transitorios. Comprobar que RabbitMQ se está ejecutando

• Si se producen otros errores FATALES, revise la entrada de registro completa y contribuya con el servicio de soporte de Tableau con el archivo de registro

Desconexiones del agente después de la actualización del servidor de RMT

Los agentes se muestran como desconectados en la interfaz de usuario web de RMT, no hay datos de supervisión de nodos específicos de Tableau Server.

Se detecta mediante comprobaciones previas a la actualización #36b, #36c #36d

Los agentes se vuelven a conectar automáticamente después de que se complete la actualización del servidor de RMT. Espere de 5 a 10 minutos para que esto se solucione. De lo contrario, compruebe lo siguiente:

• Compruebe que el servicio del agente se esté ejecutando en cada host del agente

• Si los agentes ejecutan una versión mucho más antigua, actualícelos para que coincidan con la versión del servidor de RMT

• Compruebe la conectividad de red (puerto AMQP 5672) entre el agente y los hosts del servidor de RMT

Regresión de versiones incorrectas conocidas

Cuando se rompen funciones específicas debido a un defecto conocido en la versión instalada.

Se detecta mediante la comprobación previa a la actualización #36a

Para solucionarlo, haga lo siguiente:

• Actualice a la próxima versión de parche (por ejemplo, de 2025.3.0 a 2025.3.1+)

• Póngase en contacto con el soporte de Tableau para obtener información sobre los parches específicos de cada versión

Limpieza de Hangfire rota (W-19380780)

La base de datos crece continuamente y el esquema hangfire es anormalmente grande (>1 GB).

Se detecta mediante comprobaciones previas a la actualización #21d, #21g

Para solucionarlo, haga lo siguiente:

• La actualización a una versión fija corrige la volatilidad de la función delete_hash()

• Las filas huérfanas en el esquema hangfire pueden requerir una limpieza manual. Póngase en contacto con el servicio de soporte de Tableau.

Limpieza de la base de datos deshabilitada

El tamaño de la base de datos crece con el tiempo sin límite y la actualización se vuelve lenta.

Se detecta mediante la comprobación previa a la actualización #21c

Para solucionarlo, haga lo siguiente:

• Se establece db:cleanup:type en Purge en config.json

• Reduzca db:cleanup:afterDays a 30–90 días (valor predeterminado: 14)

• Reinicie el servicio de RMT Director para que el cambio de configuración surta efecto

Problemas de permisos de archivos

Los servicios no se inician o no pueden leer los registros de configuración o escritura.

Se detecta mediante la comprobación posterior a la actualización #4, las comprobaciones previas a la actualización #11–#16

Para solucionarlo, compruebe lo siguiente:

• Linux: Compruebe la propiedad y la pertenencia a grupos de los directorios de configuración, registro y datos

• Windows: Compruebe que la cuenta de servicio tiene acceso de lectura/escritura a los directorios de instalación

• Póngase en contacto con el servicio de soporte de Tableau si los problemas de permisos persisten después de una instalación nueva

Procesos de RMT detenidos después de detener rmtadmin

Después de ejecutarse rmtadmin stop según el procedimiento de actualización documentado, uno o más procesos tabrmt-master, tabrmt-master-background, tabrmt-agento tabrmt-agent-background siguen en ejecución. Si la actualización se lleva a cabo en este estado, el instalador puede fallar a mitad de la ejecución con errores de archivo en uso.

Se detecta mediante la comprobación previa a la actualización #38a

Para solucionarlo, haga lo siguiente:

• Espere ~30 segundos para que se apague correctamente y vuelva a realizar la comprobación previa a la actualización

• Si los procesos persisten:

• Linux: “pkill -u tabrmt-master -f tabrmt-master ; pkill -u tabrmt-agent -f tabrmt-agent” (omita los que no se aplican en este nodo)

• Windows: “Stop-Process -Name tabrmt-master,tabrmt-master-background,tabrmt-agent,tabrmt-agent-background -Force”

• Vuelva a ejecutar la comprobación previa a la actualización para confirmar un estado limpio antes de iniciar la actualización

Errores falsos durante las actualizaciones ubicadas en el mismo lugar

Si el RMT Master y el agente están ubicados en el mismo equipo, la comprobación previa a la actualización del agente (específicamente la comprobación #38a) puede detectar incorrectamente los procesos maestros. Debido a que el script busca todos los procesos tabrmt-* en lugar de filtrar estrictamente tabrmt-agent-*, puede desencadenar un estado FAIL falso.

La mayoría de los entornos utilizan máquinas independientes y no se encontrarán con esto. Sin embargo, si está utilizando una configuración de ubicación conjunta y recibe este error específico, puede omitir la verificación de manera segura y continuar con la instalación mediante lo siguiente:

--skip-upgrade-checks

Detalles técnicos:

Causa raíz: compruebe #38a coincide con nombres de procesos demasiado amplios (tabrmt-*).

Alcance: solo afecta a las actualizaciones in situ en las que el maestro y el agente comparten la misma instancia del sistema operativo.

Nivel de riesgo: Bajo. Los procesos maestros están fuera del alcance de la actualización del agente, por lo que el error no indica un conflicto real en el sistema.