--- schema_version: "1" id: 76dc296624f9808fce2b564e7c04e57bdead213ece47b9961dee97272843d68f title: Solucionar erros após a atualização collection: tableau version: next locale: pt-br portal_url: https://docs.salesforce.com/tableau/next/pt-br/server-linux/rmt-troubleshoot-upgrade.md canonical_url: https://help.tableau.com/v0.0/server-linux/pt-br/rmt-troubleshoot-upgrade.htm source_site: help.tableau.com content_type: documentation content_hash: 5e975069fd25124090912dd00ac90a4b5458f5ddea62d9de7bf982babde1efbc description: Troubleshoot errors encountered after upgrading the Resource Monitoring Tool. --- [Pular para o conteúdo principal](#main-content) # 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](https://help.tableau.com/v0.0/server-linux/pt-br/rmt-admin-upgrade-reference.htm). ## 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.