--- schema_version: "1" id: ee748a0c1edd9482807121ef8e98d7f7647ee6ec58a877d65ca7ad5ce1d70779 title: Solucionar errores después de la actualización collection: tableau version: current locale: es-es portal_url: https://docs.salesforce.com/tableau/current/es-es/server-linux/rmt-troubleshoot-upgrade.md canonical_url: https://help.tableau.com/current/server-linux/es-es/rmt-troubleshoot-upgrade.htm source_site: help.tableau.com content_type: documentation content_hash: 52e36f01bd01d7f579eb96c296f022d038fbbe5e52df6ecb872ea4cdb592f89f description: Troubleshoot errors encountered after upgrading the Resource Monitoring Tool. --- [Saltar al contenido principal](#main-content) # Solucionar errores después de la actualización 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](https://help.tableau.com/current/server-linux/es-es/rmt-admin-upgrade-reference.htm). ## 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-agent`o `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.