Salesforce Docs Portal

Solucionar erros após a atualização

As seções a seguir detalham problemas frequentemente identificados por verificações pós-atualização ou observados imediatamente após uma atualização.

Para obter informações sobre as verificações pré e pós-atualização, consulte a seção Referência da atualização.

Serviços que não estão em execução

A interface de usuário da Web do RMT está inacessível e o comando rmtadmin status indica que os serviços necessários foram interrompidos.

Ele é detectado pelas verificações pós-atualização Nº 1, Nº 2, Nº 16

Para corrigir isso, use as seguintes etapas:

No Linux, use o comando a seguir:

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

No Windows, use o comando a seguir:

Start-Service TableauResourceMonitoringTool

Verifique os logs de serviço no diretório de logs para verificar se há erros de inicialização.

O PostgreSQL não aceita conexões

Quando a interface do usuário da Web mostra erros de banco de dados e os dados não estão sendo armazenados.

Ele é detectado pelas verificações pós-atualização Nº 5c e Nº 6

Para corrigir isso, verifique o seguinte:

  • Verifique se o serviço do PostgreSQL está em execução

  • Verifique os logs do PostgreSQL no diretório de dados para ver se há erros de inicialização

  • Verifique se a porta do banco de dados (padrão 5555) não está bloqueada por outro processo

O RabbitMQ não responde

Quando os agentes aparecem como desconectados e nenhum novo dado de monitoramento é exibido.

Ele é detectado pelas verificações pós-atualização Nº 5b, Nº 7 e Nº 9

Para corrigir isso, verifique o seguinte:

  • O RabbitMQ pode levar de 30 a 60 segundos para inicializar totalmente após a atualização, aguarde e verifique novamente

  • Verifique se o processo Erlang/beam está em execução

  • Verifique se há alertas de recursos do RabbitMQ (espaço em disco < 10 GB bloqueia todas as publicações de mensagens)

  • Verifique se o arquivo do cookie do Erlang existe e tem as permissões corretas

Lista de pendências da fila de mensagens

Os dados aparecem atrasados na interface do usuário da Web do RMT e os painéis mostram métricas obsoletas.

Ele é detectado pela verificação pós-atualização Nº 8.

Ter um backlog imediatamente após a atualização é normal, pois os agentes se reconectam e reenviam dados em buffer. Para corrigir isso, faça o seguinte:

  • Monitore com “rmtadmin status”; o backlog deve ser zerado dentro de 15 a 30 minutos

  • Se o backlog persistir, verifique se todos os serviços agentes estão em execução e conectados

Os serviços RMT Server não consomem (dados não processados após a atualização)

Com todos os relatórios de serviços do RMT em execução, a verificação pós-atualização passa serviços/portas/conectividade, mas a interface do usuário na Web não mostra novos dados e os agentes aparecem como “Problema de conexão”. “rmtadmin status” mostra uma ou mais filas com mensagens acumuladas, mas um número de consumidores igual a **0**.

Isso ocorre quando os trabalhadores em segundo plano do RMT Server são iniciados, mas não conseguem revincular seus canais de consumidor do RabbitMQ após uma atualização in-loco. Os agentes publicam com sucesso, as mensagens se acumulam no RabbitMQ e nada entra no banco de dados.

Isso é detectado pela verificação pós-atualização Nº 8a

Para corrigir isso, faça o seguinte:

  • Reinicie o master: `rmtadmin restart”

  • Aguarde mais ou menos 60 segundos, depois execute novamente “rmtadmin status” — as filas encalhadas agora devem mostrar “Consumidores = 1” e a lista de pendências deve se esgotar em poucos minutos

  • Se as filas ainda mostrarem “Consumers = 0” após a reinicialização, inspecione o registro em segundo plano em busca de exceções de vinculação ao consumidor:

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

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

  • Pesquise no registro por “exception”, “channel”ou “binding failed”

Incompatibilidade do modo FIPS

Quando os serviços não são iniciados com erros criptográficos ou TLS.

Ele é detectado pela verificação pós-atualização Nº 11

Para corrigir isso, faça o seguinte:

  • Verifique se a configuração do FIPS no sistema operacional corresponde à configuração do RMT (“isFIPSEnabled” em setup.json)

  • Linux: verifique “`/proc/sys/crypto/fips_enabled”

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

Corrupção do arquivo de configuração

Os serviços não iniciam por causa de erros de análise de JSON.

Ele é detectado pela verificação pós-atualização Nº 3

Para corrigir isso, faça o seguinte:

  • Valide o arquivo de configuração: “python3 -c "import json; json.load(open('config.json'))"`”

  • Restaure a partir do backup pré-atualização (recomendado antes de cada atualização)

Certificado SSL expirou ou vai expirar

Quando o navegador da Web mostra avisos de certificado e os agentes não conseguem se conectar com erros de TLS.

Ele é detectado pelas verificações pós-atualização Nº 10 e Nº 13

Para corrigir isso, faça o seguinte:

  • Renove o certificado HTTPS e atualize-o usando `rmtadmin set-ssl-certificate`

  • Para certificados RabbitMQ, substitua os arquivos PEM no diretório de certificados e reinicie o serviço

Exaustão do espaço em disco

Quando os serviços falham ou geram erros ao gravar dados e erros de banco de dados em logs.

Ele é detectado pelas verificações pós-atualização Nº 14 e pré-atualização Nº 2 e Nº 2b

Para corrigir o erro, faça o seguinte:

  • Libere espaço em disco ou expanda o volume

  • Execute a limpeza do banco de dados: certifique-se de que “db:cleanup:type” esteja definido como “Limpar” (não “Nenhum”) no config.json

  • Arquivar ou excluir arquivos de log antigos

Erros FATAL ou CRITICAL nos logs

Comportamento inesperado ou instabilidade do serviço após a atualização.

Ele é detectado pela verificação pós-atualização Nº 15

Para corrigir isso, faça o seguinte:

  • Os erros de “broker inalcançável” imediatamente após a atualização são geralmente transitórios. Verifique se o RabbitMQ está em execução agora

  • Para outros erros FATAL, revise a entrada de registro completa e entre em contato com Tableau Suporte com o arquivo de log

Desconexões de agente após a atualização do RMT Server

Os agentes aparecem como desconectados na interface do usuário da Web do RMT; nenhum dado de monitoramento de nós específicos do Tableau Server.

É detectado por verificações de pré-atualização Nº 36b, Nº 36c e Nº 36d

Os agentes se reconectam automaticamente após a conclusão da atualização do RMT Server. Aguarde de 5 a 10 minutos para que isso seja corrigido. Caso contrário, verifique o seguinte:

  • Verifique se o serviço do Agent está em execução em cada host do Agent

  • Se os agentes estiverem executando uma versão muito mais antiga, atualize-os para corresponder à versão do RMT Server

  • Verifique a conectividade de rede (AMQP porta 5672) entre os hosts Agent e RMT Server

Regressão de versão conhecida e inválida

Quando recursos específicos são quebrados devido a um defeito conhecido na versão instalada.

Ele é detectado pela verificação pré-atualização Nº 36a

Para corrigir isso, faça o seguinte:

  • Atualize para a próxima versão do patch (por exemplo, de 2025.3.0 a 2025.3.1+)

  • Entre em contato com o suporte do Tableau caso precise patches específicos de versão

Limpeza de Hangfire quebrada (W-19380780)

O banco de dados cresce continuamente e o esquema hangfire é anormalmente grande ( > 1 GB).

Ele é detectado por verificações pré-atualização Nº 21d, Nº 21g

Para corrigir isso, faça o seguinte:

  • A atualização para uma versão fixa corrige a volatilidade da função delete_hash()

  • Linhas órfãs no esquema hangfire podem exigir limpeza manual. Entre em contato com o Suporte do Tableau.

Limpeza do banco de dados desabilitada

O tamanho do banco de dados sem limite cresce com o tempo e a atualização se torna lenta.

Ele é detectado pelo Nº 21c de verificação pré-atualização

Para corrigir isso, faça o seguinte:

  • Defina db:cleanup:type como Purge em config.json

  • Reduza db:cleanup:afterDays para 30 a 90 dias (padrão: 14)

  • Reinicie o serviço RMT Director para que a alteração entre em vigor.

Problemas de permissões de arquivo

Os serviços falham ao iniciar ou não é possível ler os logs de configuração/gravação.

Ele é detectado pelas verificações pós-atualização Nº 4 e pré-atualização Nº 11 e Nº 16

Para corrigir isso, verifique o seguinte:

  • Linux: verifique a propriedade e a associação do grupo de diretórios de configuração, log e dados

  • Windows: verifique se a conta de serviço tem acesso de leitura/gravação aos diretórios de instalação

  • Entre em contato com o suporte do Tableau se os problemas de permissão persistirem após uma nova instalação

Processos do RMT encalhados após a parada do rmtadmin

Após a execução do rmtadmin stop de acordo com o procedimento de atualização documentado, um ou mais processos tabrmt-master, tabrmt-master-background tabrmt-agent ou tabrmt-agent-background ainda estão em execução. Se a atualização continuar nesse estado, o instalador poderá falhar no meio da execução com erros de arquivo em uso.

Ele é detectado pela verificação pré-atualização Nº 38a

Para corrigir isso, faça o seguinte:

  • Aguarde mais ou menos 30 segundos para um desligamento normal e execute novamente a verificação pré-atualização

  • Se os processos persistirem:

  • Linux: “pkill -u tabrmt-master -f tabrmt-master ; pkill -u tabrmt-agent -f tabrmt-agent” (ignore as que não se aplicam a este nó)

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

  • Execute novamente a verificação pré-atualização para confirmar um estado limpo antes de iniciar a atualização

 

Falhas falsas durante atualizações colocalizadas

Se o Master e o Agent do RMT estiverem colocalizados na mesma máquina, a verificação de pré-atualização do Agent (especificamente a verificação Nº 38a) poderá detectar incorretamente os processos Master. Como o script verifica todos os processos tabrmt-*, em vez de filtrar estritamente tabrmt-agent-*, ele pode disparar um falso status FAIL.

A maioria dos ambientes usa máquinas separadas e não encontrará esse problema. No entanto, se você estiver usando uma instalação colocalizada e receber essa falha específica, poderá ignorar com segurança a verificação e prosseguir com a instalação usando o seguinte comando:

--skip-upgrade-checks

Detalhes técnicos:

Causa raiz: verifique se Nº 38a corresponde a nomes de processo muito amplos (tabrmt-*).

Escopo: afeta apenas atualizações in-loco em que o Master e Agent compartilham a mesma instância de sistema operacional.

Nível de risco: baixo. Os processos mestre estão fora do escopo da atualização do Agent, portanto, a falha não indica um conflito real do sistema.