Verificações pós-atualização e solução de problemas

Verificações pós-atualização

Na sequência da Atualização no local as atividades a seguir devem ser executadas para finalizar a atualização. Pressupõe-se que o AEM tenha sido iniciado com o jar 6.5 e que a base de código atualizada tenha sido implantada.

Verificar logs para Êxito na Atualização

upgrade.log

Anteriormente, a inspeção do estado pós-atualização da instância exigia uma inspeção cuidadosa de vários arquivos de log, partes do repositório e a barra inicial. Gerar um relatório pós-atualização pode ajudar a detectar atualizações com defeito antes de entrar em funcionamento.

O principal objetivo desse recurso é reduzir a necessidade de interpretação manual ou lógica de análise complexa entre vários endpoints necessários para qualificar o sucesso de uma atualização. A solução tem como objetivo fornecer informações inequívocas para que os sistemas de automação externos reajam ao sucesso ou à falha identificada de uma atualização.

Mais especificamente, garante que:

  • As falhas de atualização detectadas pela estrutura de atualização são centralizadas em um único relatório de atualização;
  • O relatório de atualização inclui indicadores sobre a intervenção manual necessária.

Para acomodar isso, foram feitas alterações na maneira como os logs são gerados no upgrade.log arquivo.

Este é um exemplo de relatório que não mostra erros durante a atualização:

1487887443006

Este é um exemplo de relatório que mostra um pacote que não foi instalado durante o processo de atualização:

1487887532730

error.log

O error.log deve ser cuidadosamente revisado durante e após a inicialização do AEM usando o jar da versão de destino. Quaisquer avisos ou erros devem ser revisados. Em geral, é melhor procurar problemas no início do log. Os erros que ocorrem posteriormente no log podem ser, na verdade, efeitos colaterais de uma causa raiz que é chamada no início do arquivo. Se ocorrerem erros e avisos repetidos, veja abaixo para Análise de problemas com a atualização.

Verificar pacotes OSGi

Navegue até o console OSGi /system/console/bundles e verifique se algum pacote não foi iniciado. Se algum pacote estiver no estado instalado, consulte o error.log para determinar o problema raiz.

Verificar versão do Oak

Após a atualização, você deve ver que a versão do Oak foi atualizada para 1.10.2. Para verificar a versão do Oak, navegue até o console OSGi e verifique a versão associada aos pacotes Oak: Oak Core, Oak Commons, Oak Segment Tar.

Pasta PreUpgradeBackup do Inspect

Durante a atualização, o AEM tenta fazer backup das personalizações e as armazena abaixo de /var/upgrade/PreUpgradeBackup/<time-stamp-of-upgrade>. Para exibir esta pasta no CRXDE Lite, talvez seja necessário habilitar CRXDE Lite temporariamente.

A pasta com o carimbo de data/hora deve ter uma propriedade chamada mergeStatus com um valor de COMPLETED. A variável para processar a pasta deve estar vazia e a variável substituído indica quais nós foram substituídos durante a atualização. O conteúdo abaixo do nó restante indica conteúdo que não pôde ser mesclado com segurança durante a atualização. Se a implementação depender de qualquer um dos nós secundários (e ainda não instalados pelo pacote de código atualizado), eles precisarão ser mesclados manualmente.

Desative o CRXDE Lite após este exercício se estiver em um ambiente de Preparo ou Produção.

Validação inicial das páginas

Executar uma validação inicial em várias páginas no AEM. Se estiver atualizando um ambiente de Autor, abra a página Iniciar e a página de Boas-vindas ( /aem/start.html, /libs/cq/core/content/welcome.html). Nos ambientes Autor e Publicação, abra algumas páginas de aplicativo e teste de fumaça que eles renderizam corretamente. Em caso de problemas, consulte o error.log para solucionar problemas.

Aplicar Service Packs do AEM

Aplique quaisquer Service Packs AEM 6.5 relevantes caso eles tenham sido lançados.

Migrar recursos do AEM

Vários recursos no AEM exigem etapas adicionais após a atualização. Uma lista completa desses recursos e etapas para migrá-los no AEM 6.5 pode ser encontrada no site Atualização de código e personalizações página.

Verificar configurações de manutenção programada

Habilitar coleta de lixo do armazenamento de dados

Se estiver usando um Armazenamento de dados de arquivo, verifique se a tarefa Coleta de lixo do armazenamento de dados está ativada e adicionada à lista de Manutenção semanal. As instruções estão descritas aqui.

OBSERVAÇÃO

Isso não é recomendado para instalações de armazenamento de dados personalizado S3 ou ao usar um armazenamento de dados compartilhado.

Ativar limpeza de revisão online

Se estiver usando MongoMK ou o novo formato de segmento TarMK, verifique se a tarefa Revision Clean Up está ativada e adicionada à lista Daily Maintenance (Manutenção diária). Instruções descritas aqui.

Executar plano de teste

Executar plano de teste detalhado em relação ao conforme definido Atualização de código e personalizações no Procedimento de teste seção.

Habilitar agentes de replicação

Depois que o ambiente de publicação for totalmente atualizado e validado, ative os agentes de replicação no Ambiente de autor. Verifique se os agentes podem se conectar às respectivas instâncias de Publicação. Consulte U Procedimento de atualização para obter mais detalhes sobre a ordem dos eventos.

Habilitar os trabalhos agendados personalizados

Todos os trabalhos agendados como parte da base de código podem ser ativados neste ponto.

Análise De Problemas Com A Atualização

Esta seção contém alguns cenários de problemas que podem ocorrer durante o procedimento de atualização para AEM 6.3.

Esses cenários devem ajudar a rastrear a causa raiz de problemas relacionados à atualização e devem ajudar a identificar problemas específicos do projeto ou do produto.

Falha na migração do repositório

A migração de dados do CRX2 para o Oak deve ser viável para qualquer cenário que comece com Instâncias de origem com base no CQ 5.4. Siga exatamente as instruções de atualização neste documento, que incluem a preparação do repository.xml, certificando-se de que nenhum autenticador personalizado seja iniciado por meio do JAAS e que a instância tenha sido verificada em busca de inconsistências antes de iniciar a migração.

Se a migração ainda falhar, você poderá descobrir qual é a causa raiz, inspecionando o upgrade.log. Se o problema ainda não for conhecido, relate-o ao Suporte ao Cliente.

A Atualização Não Foi Executada

Antes de iniciar as etapas de preparação, execute o origem primeiro, executando-a com o comando Java™ -jar aem-quickstart.jar. Isso é necessário para garantir que o arquivo quickstart.properties seja gerado corretamente. Se estiver ausente, a atualização não funcionará. Como alternativa, verifique se o arquivo está presente na seção crx-quickstart/conf na pasta de instalação da instância de origem. Além disso, ao iniciar o AEM para iniciar a atualização, ele deve ser executado com o comando Java™ -jar aem-quickstart.jar. A inicialização a partir de um script de inicialização não iniciará o AEM no modo de atualização.

Falha ao atualizar pacotes e pacotes

Se os pacotes não forem instalados durante a atualização, os pacotes que eles contêm também não serão atualizados. Essa categoria de problemas é causada por uma configuração incorreta do armazenamento de dados. Eles também aparecerão como ERRO e AVISO mensagens no error.log. Como na maioria desses casos o logon padrão pode falhar, você pode usar o CRXDE diretamente para inspecionar e encontrar os problemas de configuração.

Alguns pacotes de AEM não estão mudando para o estado ativo

Se houver pacotes não inicializando, verifique se há dependências não satisfeitas.

Caso esse problema esteja presente, mas se baseie em uma instalação de pacote com falha que resultou na não atualização de pacotes, eles serão considerados incompatíveis para a nova versão. Para obter mais informações sobre como solucionar esse problema, consulte Falha ao atualizar pacotes e pacotes acima.

Também é recomendável comparar a lista de pacotes de uma instância atualizada do AEM 6.5 com a atualizada para detectar os pacotes que não foram atualizados. Isso fornecerá um escopo mais próximo do que procurar no error.log.

Pacotes personalizados não estão alternando para o estado ativo

Caso seus pacotes personalizados não estejam alternando para o estado ativo, é provável que haja um código que não esteja importando a API de alteração. Isso levará, na maioria das vezes, a dependências insatisfeitas.

A API removida deve ser marcada como obsoleta em uma das versões anteriores. Você pode encontrar instruções sobre uma migração direta do seu código neste aviso de desativação. O Adobe visa o controle de versão semântico sempre que possível, para que as versões possam indicar alterações de quebra.

Também é melhor verificar se a alteração que causou o problema foi necessária e, caso contrário, revertê-la. Verifique também se o aumento da versão da exportação de pacotes foi aumentado mais do que o necessário, após o controle de versão semântico rigoroso.

Interface de plataforma defeituosa

Se houver determinada funcionalidade da interface do usuário que não esteja funcionando corretamente após a atualização, verifique primeiro se há sobreposições personalizadas da interface. Algumas estruturas podem ter sido alteradas e a sobreposição pode precisar de uma atualização ou está obsoleta.

Em seguida, verifique se há erros de JavaScript que possam ser rastreados até extensões personalizadas adicionadas que estejam vinculadas às bibliotecas do cliente. O mesmo pode se aplicar ao CSS personalizado que pode estar causando problemas no layout do AEM.

Por fim, verifique se há erros de configuração com os quais o JavaScript talvez não consiga lidar. Geralmente, isso ocorre com extensões desativadas incorretamente.

Componentes personalizados com defeito, Modelos ou Extensões de UI

Normalmente, as causas básicas desses problemas são as mesmas dos pacotes que não são iniciados ou dos pacotes que não estão sendo instalados, com a única diferença de que os problemas começam a ocorrer ao usar os componentes pela primeira vez.

A maneira de lidar com um código personalizado incorreto é primeiro executar testes de fumaça para identificar a causa. Depois de encontrá-lo, verifique as recomendações neste [link] seção do artigo para saber como corrigi-los.

Personalizações ausentes em /etc

/apps e /libs são bem tratados pela atualização, mas as alterações em /etc pode ser necessário restaurar manualmente a partir de /var/upgrade/PreUpgradeBackup após a atualização. Verifique neste local se há conteúdo que precise ser mesclado manualmente.

Análise de error.log e upgrade.log

Na maioria das situações, os registros precisam ser consultados para que os erros localizem a causa de um problema. No entanto, com as atualizações, também é necessário monitorar problemas de dependência, pois os pacotes antigos podem não ser atualizados corretamente.

A melhor maneira de fazer isso é remover o error.log, removendo todas as mensagens que provavelmente não estão relacionadas ao problema que você está enfrentando. Você pode fazer isso por meio de uma ferramenta como o grep, usando:

grep -v UnrelatedErrorString

Algumas mensagens de erro podem não ser explicativas imediatamente. Nesse caso, observar o contexto em que eles ocorrem também pode ajudar a entender onde o erro foi criado. É possível separar o erro usando:

  • grep -B para adicionar linhas antes do erro;

ou

  • grep -A para adicionar linhas depois de.

Em alguns casos, mensagens de AVISO também podem ser encontradas, pois pode haver casos válidos que levam a esse estado e o aplicativo nem sempre pode decidir se esse é um erro real. Consulte também estas mensagens.

Contato com o suporte da Adobe

Se você seguiu as instruções desta página e ainda está vendo problemas, entre em contato com o Suporte da Adobe. Para fornecer o máximo possível de informações ao engenheiro de suporte que trabalha no seu caso, inclua o arquivo upgrade.log da sua atualização.

Nesta página