Comprobaciones posteriores a la actualización y solución de problemas post-upgrade-checks-and-troubleshooting

Comprobaciones posteriores a la actualización post-upgrade-checks

Siguiendo las Actualización in situ se deben ejecutar las siguientes actividades para finalizar la actualización. AEM Se supone que se ha iniciado con el JAR 6.5 y que se ha implementado la base de código actualizada.

Verificación de registros para actualización correcta verify-logs-for-upgrade-success

upgrade.log

En el pasado, la inspección del estado posterior a la actualización de la instancia requería una inspección cuidadosa de varios archivos de registro, partes del repositorio y el Launchpad. La generación de un informe posterior a la actualización puede ayudar a detectar actualizaciones defectuosas antes de activarse.

El propósito principal de esta función es reducir la necesidad de interpretación manual o de lógica de análisis compleja en varios extremos necesarios para calificar el éxito de una actualización. La solución tiene como objetivo proporcionar información inequívoca para que los sistemas de automatización externos reaccionen ante el éxito o el fracaso identificado de una actualización.

Más concretamente, garantiza que:

  • Los errores de actualización detectados por el marco de actualización están centralizados en un único informe de actualización;
  • El informe de actualización incluye indicadores sobre la intervención manual necesaria.

Para ello, se han realizado cambios en la forma en que se generan los registros en la upgrade.log archivo.

Este es un informe de ejemplo que muestra que no hay errores durante la actualización:

1487887443006

Este es un informe de ejemplo que muestra un paquete que no se instaló durante el proceso de actualización:

1487887532730

error.log

AEM El error.log debe revisarse cuidadosamente durante y después del inicio de la ejecución de la ejecución de la aplicación utilizando el JAR de la versión de destino. Deben revisarse todas las advertencias o errores. En general, es mejor buscar problemas al principio del registro. Los errores que se producen más adelante en el registro pueden ser en realidad efectos secundarios de una causa raíz que se llama al principio del archivo. Si se producen errores y advertencias repetidos, consulte a continuación para Análisis de problemas con la actualización.

Verificar paquetes OSGi verify-osgi-bundles

Vaya a la consola OSGi /system/console/bundles y compruebe si no se ha iniciado ningún paquete. Si algún paquete está en estado instalado, consulte el error.log para determinar el problema de raíz.

Verificar versión de Oak verify-oak-version

Después de la actualización, debe ver que la versión de Oak se ha actualizado a 1.10.2. Para verificar la versión de Oak, vaya a la consola OSGi y observe la versión asociada con los paquetes Oak: Oak Core, Oak Commons, Oak Segment Tar.

Carpeta PreUpgradeBackup de Inspect inspect-preupgradebackup-folder

AEM Durante la actualización, intenta realizar una copia de seguridad de las personalizaciones y almacenarlas debajo de /var/upgrade/PreUpgradeBackup/<time-stamp-of-upgrade>. Para ver esta carpeta en CRXDE Lite, es posible que tenga que habilitar CRXDE Lite temporalmente.

La carpeta con la marca de tiempo debe tener una propiedad denominada mergeStatus con un valor de COMPLETED. El para procesar debe estar vacía y la variable sobrescrito node indica qué nodos se sobrescribieron durante la actualización. El contenido debajo del nodo de sobras indica contenido que no se pudo combinar de forma segura durante la actualización. Si la implementación depende de cualquiera de los nodos secundarios (y no están ya instalados en el paquete de código actualizado), deben combinarse manualmente.

Deshabilite el CRXDE Lite después de este ejercicio si se encuentra en un entorno de ensayo o producción.

Validación inicial de páginas initial-validation-of-pages

AEM Realice una validación inicial en varias páginas de la lista de distribución de recursos Si actualiza un entorno de autor, abra la página de inicio y la página de bienvenida ( /aem/start.html, /libs/cq/core/content/welcome.html). En los entornos de creación y publicación, abra algunas páginas de aplicación y pruebe a fumar para que se representen correctamente. Si se produce algún problema, consulte la error.log para solucionar problemas.

AEM Aplicar paquetes de servicio apply-aem-service-packs

AEM Aplique cualquier paquete de servicio pertinente de 6.5 de si se ha publicado.

AEM Migración de funciones de migrate-aem-features

AEM Varias funciones de requieren pasos adicionales después de la actualización. AEM Puede encontrar una lista completa de estas funciones y los pasos para migrarlas en la versión 6.5 de en el Actualizar código y personalizaciones página.

Verificar las configuraciones de mantenimiento programadas verify-scheduled-maintenance-configurations

Activar recolección de basura del almacén de datos enable-data-store-garbage-collection

Si utiliza un almacén de datos de archivos, asegúrese de que la tarea de recolección de elementos no utilizados del almacén de datos esté habilitada y agregada a la lista de mantenimiento semanal. Se describen las instrucciones aquí.

NOTE
Esto no se recomienda para instalaciones de almacenes de datos personalizados S3 o cuando se utiliza un almacén de datos compartido.

Activar Limpieza de revisión en línea enable-online-revision-cleanup

Si utiliza MongoMK o el nuevo formato de segmento TarMK, asegúrese de que la tarea Revision Clean Up esté activada y se añada a la lista de mantenimiento diario. Instrucciones descritas aquí.

Ejecutar plan de prueba execute-test-plan

Ejecutar plan de prueba detallado según lo definido Actualizar código y personalizaciones en el Procedimiento de prueba sección.

Habilitar agentes de replicación enable-replication-agents

Una vez que el entorno de publicación se haya actualizado y validado completamente, habilite los agentes de replicación en el entorno de creación. Compruebe que los agentes puedan conectarse a las respectivas instancias de publicación. Consulte U Procedimiento de actualización para obtener más información sobre el orden de los eventos.

Habilitar trabajos programados personalizados enable-custom-scheduled-jobs

Cualquier trabajo programado como parte de la base de código puede habilitarse en este momento.

Análisis De Problemas Con La Actualización analyzing-issues-with-upgrade

AEM Esta sección contiene algunos escenarios de problemas que se pueden presentar a lo largo del procedimiento de actualización a la versión 6.3 de la.

Estos escenarios deberían ayudar a rastrear la causa raíz de los problemas relacionados con la actualización y deberían ayudar a identificar los problemas específicos del proyecto o del producto.

Error de migración de repositorio repository-migration-failing-

La migración de datos de CRX2 a Oak debe ser factible para cualquier escenario que comience con Instancias de origen basadas en CQ 5.4. Asegúrese de seguir exactamente las instrucciones de actualización de este documento, que incluyen la preparación de la repository.xml, asegurándose de que no se inicie ningún autenticador personalizado mediante JAAS y de que se haya comprobado la existencia de incoherencias en la instancia antes de iniciar la migración.

Si la migración sigue fallando, puede averiguar cuál es la causa principal inspeccionando el upgrade.log. Si el problema aún no se conoce, notifíquelo al Servicio de atención al cliente.

La Actualización No Se Ha Ejecutado the-upgrade-did-not-run

Antes de comenzar los pasos de preparación, asegúrese de ejecutar el origen primero, ejecútela con el comando Java™ -jar aem-quickstart.jar. Esto es necesario para asegurarse de que el archivo quickstart.properties se genera correctamente. Si falta, la actualización no funcionará. También puede comprobar si el archivo está presente mirando en crx-quickstart/conf en la carpeta de instalación de la instancia de origen. AEM Además, al iniciar la actualización, se debe ejecutar con el comando Java™ -jar aem-quickstart.jar. AEM El inicio desde una secuencia de comandos de inicio no se iniciará en modo de actualización de la aplicación

Los paquetes no se pueden actualizar packages-and-bundles-fail-to-update-

Si los paquetes no se instalan durante la actualización, los paquetes que contienen tampoco se actualizarán. Esta categoría de problemas se debe a una configuración incorrecta del almacén de datos. También aparecerán como ERROR y ADVERTIR mensajes en el error.log. Dado que en la mayoría de estos casos el inicio de sesión predeterminado puede no funcionar, puede utilizar CRXDE directamente para inspeccionar y encontrar los problemas de configuración.

AEM Algunos paquetes de Bundle no están cambiando al estado activo. some-aem-bundles-are-not-switching-to-the-active-state

Si hay paquetes que no se inician, compruebe si hay dependencias no satisfechas.

En caso de que este problema esté presente, pero se basa en una instalación fallida del paquete que provocó que los paquetes no se actualizaran, se considerarán incompatibles para la nueva versión. Para obtener más información sobre cómo solucionar este problema, consulte Los paquetes no se pueden actualizar arriba.

AEM También se recomienda comparar la lista de paquetes de una instancia nueva de 6.5 con la actualizada para detectar los paquetes que no se actualizaron. Esto proporcionará un ámbito más cercano de lo que se debe buscar en la error.log.

Los paquetes personalizados no cambian al estado activo custom-bundles-not-switching-to-the-active-state

En caso de que los paquetes personalizados no cambien al estado activo, lo más probable es que haya código que no importe la API de cambio. Esto suele dar lugar a dependencias no satisfechas.

La API que se eliminó debe marcarse como obsoleta en una de las versiones anteriores. Puede encontrar instrucciones acerca de una migración directa de su código en este aviso de desuso. El Adobe busca el control de versiones semánticas siempre que sea posible, de modo que las versiones puedan indicar cambios importantes.

También es mejor comprobar si el cambio que ha causado el problema era necesario y revertirlo si no lo es. Compruebe también si el aumento de versión del paquete de exportación se ha aumentado más de lo necesario, siguiendo un control de versiones semántico estricto.

IU de Platform con funcionamiento incorrecto malfunctioning-platform-ui

Si hay alguna funcionalidad de la interfaz de usuario que no funciona correctamente después de la actualización, primero debe comprobar las superposiciones personalizadas de la interfaz. Es posible que algunas estructuras hayan cambiado y que la superposición necesite una actualización o esté obsoleta.

A continuación, compruebe si hay algún error de JavaScript del que se pueda hacer un seguimiento en las extensiones agregadas personalizadas vinculadas a las bibliotecas de cliente. AEM Lo mismo puede aplicarse a los CSS personalizados que pueden estar causando problemas al diseño de la.

Finalmente, compruebe si hay alguna configuración incorrecta con la que JavaScript podría no ser capaz de lidiar. Este suele ser el caso de las extensiones desactivadas incorrectamente.

Componentes personalizados, plantillas o extensiones de IU que no funcionan correctamente malfunctioning-custom-components-templates-or-ui-extensions

Normalmente, las causas raíz de estos problemas son las mismas que para los paquetes que no se inician o los paquetes que no se instalan, con la única diferencia de que los problemas empiezan a producirse al utilizar los componentes por primera vez.

La manera de lidiar con el código personalizado erróneo es realizar primero pruebas de humo para identificar la causa. Una vez encontrado, consulte las recomendaciones de esta sección [vincular] del artículo para ver cómo corregirlos.

Faltan personalizaciones en /etc missing-customizations-under-etc

/apps y /libs se gestionan bien mediante la actualización, pero los cambios en /etc es posible que deba restaurarse manualmente desde /var/upgrade/PreUpgradeBackup después de la actualización. Asegúrese de comprobar esta ubicación para cualquier contenido que deba combinarse manualmente.

Análisis de error.log y upgrade.log analyzing-the-error.log-and-upgrade.log

En la mayoría de los casos, es necesario consultar los registros para detectar errores y encontrar la causa del problema. Sin embargo, con las actualizaciones, también es necesario monitorizar los problemas de dependencia, ya que es posible que los paquetes antiguos no se actualicen correctamente.

La mejor manera de hacerlo es eliminar el error.log eliminando todos los mensajes que se espera que no estén relacionados con el problema que está enfrentando. Puede hacerlo mediante una herramienta como grep, usando:

grep -v UnrelatedErrorString

Algunos mensajes de error pueden no ser inmediatamente explicativos. En este caso, observar el contexto en el que se producen también puede ayudar a comprender dónde se creó el error. Puede separar el error mediante lo siguiente:

  • grep -B para añadir líneas antes del error;

o

  • grep -A para añadir líneas después de.

En algunos casos, también se pueden encontrar mensajes WARN, ya que puede haber casos válidos que conduzcan a este estado y la aplicación no siempre puede decidir si se trata de un error real. Asegúrese de consultar también estos mensajes.

Contactar con el servicio de soporte técnico de Adobe contacting-adobe-support

Si ha seguido los consejos de esta página y sigue teniendo problemas, póngase en contacto con el servicio de asistencia al Adobe. Para proporcionar la mayor cantidad de información posible al ingeniero de soporte técnico que trabaja en su caso, asegúrese de incluir el archivo upgrade.log de su actualización.

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2