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.

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.