--- schema_version: "1" id: 7a743ba746f58f4524f2bc60ee827bdad8d2626008e3f6d3d47da60ec8a52663 title: Risolvere i problemi dopo l’aggiornamento collection: tableau version: next locale: it-it portal_url: https://docs.salesforce.com/tableau/next/it-it/server/rmt-troubleshoot-upgrade.md canonical_url: https://help.tableau.com/v0.0/server/it-it/rmt-troubleshoot-upgrade.htm source_site: help.tableau.com content_type: documentation content_hash: d419ff5715048f466c4cff3820684d5b30d57083b335122714b4e10230b3d25f description: Troubleshoot errors encountered after upgrading the Resource Monitoring Tool. --- [Passa al contenuto principale](#main-content) # Risolvere i problemi dopo l’aggiornamento Le sezioni seguenti descrivono in dettaglio i problemi spesso identificati dai controlli post-aggiornamento o osservati immediatamente dopo un aggiornamento. Per informazioni sui controlli pre-aggiornamento e post-aggiornamento, consulta la sezione [Aggiornamento di RMT: informazioni tecniche di riferimento](https://help.tableau.com/v0.0/server/it-it/rmt-admin-upgrade-reference.htm). ## I servizi non sono in esecuzione L’interfaccia utente Web di RMT non è accessibile e il comando rmtadmin status indica che i servizi richiesti si sono arrestati. Viene rilevato dai controlli post-aggiornamento #1, #2 e #16 Per risolvere questo problema, procedi come segue: Per Linux, usa il comando seguente: sudo -u tabrmt-master XDG\_RUNTIME\_DIR=/run/user/$(id -u tabrmt-master) systemctl --user start tabrmt-master Per Windows, usa il comando seguente: Start-Service TableauResourceMonitoringTool Controlla i log dei servizi nella directory dei log per verificare la presenza di errori di avvio. ## PostgreSQL non accetta connessioni L’interfaccia utente Web mostra errori del database e i dati non vengono archiviati. Viene rilevato dai controlli post-aggiornamento #5c e #6 Per risolvere questo problema, esegui i seguenti controlli: - Verifica che il servizio PostgreSQL sia in esecuzione - Controlla i log PostgreSQL nella directory dei dati per verificare la presenza di errori di avvio - Assicurati che la porta di database (impostazione predefinita: 5555) non sia bloccata da un altro processo ## RabbitMQ non risponde Gli agenti sono visualizzati come disconnessi e non vengono visualizzati nuovi dati di monitoraggio. Viene rilevato dai controlli post-aggiornamento #5b, #7 e #9 Per risolvere questo problema, esegui i seguenti controlli: - L’inizializzazione completa di RabbitMQ dopo l’aggiornamento potrebbe richiedere 30-60 secondi. Attendi e ricontrolla - Verifica che il processo Erlang/beam sia in esecuzione - Verifica la presenza di allarmi di risorse RabbitMQ (se lo spazio su disco è minore di 10 GB la pubblicazione di tutti i messaggi viene bloccata) - Verifica che il file cookie Erlang esista e disponga delle autorizzazioni corrette ## Backlog della coda di messaggi I dati appaiono in ritardo nell’interfaccia utente Web di RMT e le dashboard mostrano metriche non aggiornate. Viene rilevato dal controllo post-aggiornamento #8. Un backlog subito dopo l’aggiornamento è normale quando gli agenti si riconnettono e inviano nuovamente i dati memorizzati nel buffer. Per risolvere questo problema, procedi come segue: - Esegui il monitoraggio con “rmtadmin status”: il backlog dovrebbe cancellarsi entro 15-30 minuti - Se il backlog persiste, verifica che tutti i servizi agente siano in esecuzione e connessi ## I worker di RMT Server non funzionano (dati non inseriti dopo l’aggiornamento) Tutti i servizi RMT risultano in esecuzione, i servizi, le porte e la connettività superano il controllo post-aggiornamento, ma l’interfaccia utente Web non mostra nuovi dati e per gli agenti è segnalato un problema di connessione. ’`rmtadmin status`’ mostra una o più code con messaggi che si accumulano, ma un conteggio di utilizzatori pari a \*\*0\*\*. Ciò si verifica quando i worker in background di RMT Server si avviano ma non riescono a ristabilire il binding ai canali utilizzatori RabbitMQ dopo un aggiornamento sul posto. Gli agenti eseguono correttamente la pubblicazione, i messaggi si accumulano in RabbitMQ e nulla viene aggiunto al database. Viene rilevato dal controllo post-aggiornamento #8a Per risolvere questo problema, procedi come segue: - Riavvia il master: `` `rmtadmin restart ``’ - Attendi circa 60 secondi, quindi esegui nuovamente ’`rmtadmin status`’: le code stranded dovrebbero ora mostrare ‘Consumers = 1’ e il backlog dovrebbe esaurirsi in pochi minuti - Se le code mostrano ancora ‘Consumers = 0’ dopo il riavvio, esamina il log in background per individuare eccezioni di binding degli utilizzatori: - Windows: ’`C:\Program Files\Tableau\Tableau Resource Monitoring Tool\master\logs\background\*.log`’ - Linux: ’`/var/opt/tableau/tabrmt/master/logs/background/*.log`’ - Cerca ’`exception`’, ’`channel`’ o ’`binding failed`’ nel log ## Mancata corrispondenza della modalità FIPS I servizi non si avviano con errori di crittografia o TLS. Viene rilevato dal controllo post-aggiornamento #11 Per risolvere questo problema, procedi come segue: - Assicurati che l’impostazione FIPS a livello di sistema operativo corrisponda alla configurazione RMT (‘isFIPSEnabled’ in setup.json) - Linux: seleziona `` `/proc/sys/crypto/fips_enabled ``’ - Windows: seleziona ’`HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled`’ ## File di configurazione danneggiato I servizi non si avviano con errori di analisi JSON. Viene rilevato dal controllo post-aggiornamento #3 Per risolvere questo problema, procedi come segue: - Convalida il file di configurazione: ’`` python3 -c "import json; json.load(open('config.json'))"` `` - Esegui il ripristino dal backup di pre-aggiornamento (che è consigliabile eseguire prima di ogni aggiornamento) ## Certificato SSL scaduto o in scadenza Il browser Web mostra avvisi relativi al certificato e gli agenti non riescono a connettersi, segnalando errori TLS. Viene rilevato dai controlli post-aggiornamento #10 e #13 Per risolvere questo problema, procedi come segue: - Rinnova il certificato HTTPS e aggiornalo utilizzando `` `rmtadmin set-ssl-certificate` `` - Per i certificati RabbitMQ, sostituisci i file PEM nella directory dei certificati e riavvia il servizio ## Esaurimento dello spazio su disco I servizi si arrestano in modo anomalo o non riescono a scrivere dati e nei log sono presenti errori del database. Viene rilevato dal controllo post-aggiornamento #14 e dai controlli pre-aggiornamento #2 e #2b Per risolvere il problema, procedi come segue: - Libera spazio su disco o espandi il volume - Esegui la pulizia del database: assicurati che ’`db:cleanup:type`’ sia impostato su ‘Purge’ (non su ‘None’) in config.json - Archivia o elimina i file di log meno recenti ## Errori FATAL o CRITICAL nei log Comportamento imprevisto o instabilità dei servizi dopo l’aggiornamento. Viene rilevato dal controllo post-aggiornamento #15 Per risolvere questo problema, procedi come segue: - Gli errori relativi all’irraggiungibilità del broker subito dopo l’aggiornamento sono in genere temporanei. Verifica che RabbitMQ ora sia in esecuzione - Per altri errori FATAL, consulta la voce di log completa e contatta l’assistenza Tableau con il file di log ## Disconnessioni degli agenti dopo l’aggiornamento di RMT Server Gli agenti risultano disconnessi nell’interfaccia utente Web di RMT; nessun dato di monitoraggio da nodi specifici di Tableau Server. Viene rilevato dai controlli pre-aggiornamento #36b, #36c e #36d Gli agenti si riconnettono automaticamente al termine dell’aggiornamento di RMT Server. Attendi 5-10 minuti che il problema si risolva. Se questo non avviene, controlla quanto segue: - Verifica che il servizio agente sia in esecuzione su ciascun host agente - Se gli agenti eseguono una versione molto precedente, eseguine l’aggiornamento in modo che la loro versione corrisponda a quella di RMT Server - Controlla la connettività di rete (porta AMQP 5672) tra l’agente e gli host RMT Server ## Regressione a una versione notoriamente non valida Alcune funzionalità specifiche non funzionano a causa di un difetto noto nella versione installata. Viene rilevato dal controllo pre-aggiornamento #36a Per risolvere questo problema, procedi come segue: - Esegui l’aggiornamento alla versione patch successiva (ad esempio, da 2025.3.0 a 2025.3.1+) - Contatta l’assistenza Tableau per le patch specifiche di versione ## Pulizia Hangfire non funzionante (W-19380780) Il database cresce continuamente e lo schema `hangfire` ha raggiunto una dimensione anomala (>1 GB). Viene rilevato dai controlli pre-aggiornamento #21d e #21g Per risolvere questo problema, procedi come segue: - L’aggiornamento a una versione corretta rimuove la volatilità della funzione `delete_hash()` - Le righe orfane nello schema hangfire possono richiedere una pulizia manuale. Contatta l’assistenza Tableau. ## Pulizia del database disabilitata Le dimensioni del database aumentano nel tempo senza limiti e l’aggiornamento diventa lento. Viene rilevato dal controllo pre-aggiornamento #21c Per risolvere questo problema, procedi come segue: - Imposta `db:cleanup:type` su `Purge` in `config.json` - Riduci `db:cleanup:afterDays` a 30–90 giorni (impostazione predefinita: 14) - Riavvia il servizio RMT Director per rendere effettive le modifiche ## Problemi relativi alle autorizzazioni dei file I servizi non si avviano o non riescono a leggere i log di configurazione o di scrittura. Viene rilevato dal controllo post-aggiornamento #4 e dai controlli pre-aggiornamento #11–#16 Per risolvere questo problema, esegui i seguenti controlli: - Linux: verifica la proprietà e l’appartenenza a gruppi delle directory di configurazione, log e dati - Windows: verifica che l’account di servizio disponga dell’accesso in lettura/scrittura alle directory di installazione - Contatta l’assistenza Tableau se i problemi di autorizzazione persistono dopo una nuova installazione ## Processi RMT stranded dopo l’arresto di rmtadmin Dopo l’esecuzione di `rmtadmin stop` secondo la procedura di aggiornamento documentata, uno o più processi `tabrmt-master`, `tabrmt-master-background`, `tabrmt-agent` o `tabrmt-agent-background` sono ancora in esecuzione. Se l’aggiornamento procede in queste condizioni, il programma di installazione potrebbe avere esito negativo a metà esecuzione con errori di file in uso. Viene rilevato dal controllo pre-aggiornamento #38a Per risolvere questo problema, procedi come segue: - Attendi circa 30 secondi l’arresto normale, quindi esegui nuovamente il controllo pre-aggiornamento - Se i processi persistono: - Linux: ’`pkill -u tabrmt-master -f tabrmt-master ; pkill -u tabrmt-agent -f tabrmt-agent`’ (salta quelli che non si applicano a questo nodo) - Windows: ’`Stop-Process -Name tabrmt-master,tabrmt-master-background,tabrmt-agent,tabrmt-agent-background -Force`’ - Esegui nuovamente il controllo pre-aggiornamento per confermare lo stato di pulizia prima di iniziare l’aggiornamento ## Falsi errori durante aggiornamenti nella stessa posizione Se il master e l’agente RMT si trovano entrambi nello stesso computer, il controllo pre-aggiornamento dell’agente (in particolare il controllo #38a) potrebbe rilevare processi master in modo errato. Poiché lo script esegue la scansione di tutti i processi tabrmt-\* anziché filtrare esclusivamente tabrmt-agent-\*, potrebbe attivare uno stato **FAIL** falso. La maggior parte degli ambienti utilizza computer separati e non incontrerà questo problema. Tuttavia, se utilizzi un’installazione nella stessa posizione e ricevi questo errore specifico, puoi tranquillamente ignorare il controllo e procedere con l’installazione utilizzando il comando seguente: `--skip-upgrade-checks` Dettagli tecnici: Causa principale: il controllo #38a abbina nomi di processo molto generici (tabrmt-\*). Ambito: riguarda solo gli aggiornamenti sul posto in cui master e agente condividono la stessa istanza del sistema operativo. Livello di rischio: basso. I processi master non rientrano nell’ambito dell’aggiornamento dell’agente, quindi l’errore non indica un conflitto di sistema effettivo.