Show Menu
TEMAS×

Comprobaciones posteriores a la actualización y resolución de problemas

Comprobaciones posteriores a la actualización

Después de la actualización Realización de una actualización in situ in-situ, se deben ejecutar las siguientes actividades para finalizar la actualización. Se supone que AEM se ha iniciado con la versión 6.4 y que se ha implementado la base de código actualizada.

Verificar registros para actualización correcta

upgrade.log
Anteriormente, la inspección del estado posterior a la actualización de su instancia requería una cuidadosa inspección 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 activarlas.
El objetivo principal de esta función es reducir la necesidad de una interpretación manual o de una 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 en cuanto al éxito o al error identificado de una actualización.
Más concretamente, garantiza que:
  • Los errores de actualización detectados por el marco de actualización se pueden centralizar en un solo informe de actualización;
  • El informe de actualización incluye indicadores sobre la intervención manual necesaria.
Para adaptarse a esto, se han realizado cambios en la forma en que se generan los registros en el upgrade.log archivo.
Este es un informe de muestra que no muestra errores durante la actualización:
Este es un informe de muestra que muestra un paquete que no se instaló durante el proceso de actualización:
error.log
El error.log debe revisarse cuidadosamente durante y después del inicio de AEM mediante el jar de la versión de destino. Cualquier advertencia o error debe revisarse. 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 invoca al principio del archivo. Si se producen errores y advertencias repetidos, consulte a continuación para Analizar problemas con la actualización .

Verificar paquetes OSGi

Vaya a la consola OSGi /system/console/bundles y vea si no se ha iniciado ningún paquete. Si alguno de los paquetes se encuentra en estado de instalación, consulte el error.log para determinar el problema raíz.

Verificar versión Oak

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

Inspeccionar la carpeta PreUpgradeBackup

Durante la actualización, AEM intentará realizar copias de seguridad de las personalizaciones y almacenarlas debajo /var/upgrade/PreUpgradeBackup/<time-stamp-of-upgrade> . Para poder ver esta carpeta en CRXDE Lite, es posible que tenga que activar temporalmente CRXDE Lite .
La carpeta con la marca de hora debe tener una propiedad denominada mergeStatus con un valor de COMPLETED . La carpeta para procesar debe estar vacía y el nodo sobrescrito indica qué nodos se sobrescribieron durante la actualización. El contenido debajo del nodo izquierdo indica el 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á instalada por el paquete de código actualizado), deberá combinarlos manualmente.
Desactive CRXDE Lite después de este ejercicio si se encuentra en un entorno de fase o producción.

Validación inicial de páginas

Realice una validación inicial con varias páginas en AEM. Si actualiza un entorno de creación, abra la página de inicio y la página de bienvenida ( /aem/start.html , /libs/cq/core/content/welcome.html ). Tanto en los entornos de creación como de publicación, se abren unas pocas páginas de aplicación y se realiza una prueba de humo que se representan correctamente. Si se produce algún problema, consulte el error.log para solucionarlo.

Aplicar paquetes de servicios AEM

Aplique los Service Packs relevantes de AEM 6.4 si se han lanzado.

Migración de funciones de AEM

Varias funciones de AEM requieren pasos adicionales tras la actualización. En la página Actualización de código y personalizaciones encontrará una lista completa de estas funciones y pasos para migrarlas a AEM 6.4.

Verificar las configuraciones de mantenimiento programadas

Enable Data Store Garbage Collection

Si utiliza un almacén de datos de archivos, asegúrese de que la tarea Recopilación de elementos no utilizados del almacén de datos está activada y se agrega a la lista Mantenimiento semanal. Las instrucciones se describen aquí .
No se recomienda para instalaciones de almacén de datos personalizado S3 o cuando se utiliza un almacén de datos compartido.

Habilitar limpieza de revisión en línea

Si utiliza MongoMK o el nuevo formato de segmento TarMK, asegúrese de que la tarea Limpieza de revisión esté habilitada y agregada a la lista Mantenimiento diario. Instrucciones descritas aquí .

Ejecutar plan de prueba

Ejecute un plan de prueba detallado según se define en la sección Actualización de código y Personalizaciones en Procedimiento de prueba.

Habilitar agentes de replicación

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 pueden conectarse a las instancias de publicación correspondientes. Consulte Procedimiento de actualización para obtener más información sobre el orden de los eventos.

Habilitar trabajos programados personalizados

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

Análisis De Problemas Con La Actualización

Esta sección contiene algunos escenarios de problemas a los que podría enfrentarse durante el procedimiento de actualización a AEM 6.4.
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 producto.

Creación de la configuración de Dynamic Media Cloud después de actualizar

Después de actualizar a AEM 6.4 desde una versión anterior, es posible que la configuración de Dynamic Media Cloud de ajustes anteriores no sea accesible desde la IU táctil de AEM 6.4. Para resolver este problema, utilice CRXDE Lite para quitar la configuración anterior y, a continuación, cree una nueva configuración de Dynamic Media Cloud. Consulte también Reestructuración del repositorio de Dynamic Media en AEM 6.4 .

Error en la migración del repositorio

La migración de datos de CRX2 a Oak debería ser factible en cualquier escenario que comience con instancias de origen basadas en CQ 5.4. Asegúrese de que sigue 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 hayan comprobado las incoherencias de la instancia antes de iniciar la migración.
Si la migración sigue fallando, puede averiguar cuál es la causa raíz inspeccionando el upgrade.log . Si el problema aún no se conoce, notifíquelo a la Asistencia al cliente.

No Se Ejecutó La Actualización

Antes de iniciar los pasos de preparación, asegúrese de ejecutar primero la instancia de origen 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á. Como alternativa, puede comprobar si el archivo está presente consultando crx-quickstart/conf en la carpeta de instalación de la instancia de origen. Además, al iniciar AEM para iniciar la actualización, debe ejecutarse con el comando java -jar aem-quickstart.jar. Al iniciar desde un script de inicio, AEM no se iniciará en modo de actualización.

Los paquetes y los paquetes no se actualizan

Si los paquetes no se instalan durante la actualización, tampoco se actualizarán los paquetes que contienen. Esta categoría de problemas suele deberse a una configuración incorrecta del almacén de datos. También aparecerán como mensajes ERROR y WARN en 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.

Algunos paquetes de AEM no cambian al estado activo

En caso de que los paquetes no se inicien, debe comprobar si hay dependencias insatisfechas.
En caso de que este problema esté presente pero se base en una instalación de paquete fallida que provocó que los paquetes no se actualizaran, se considerarán incompatibles con la nueva versión. Para obtener más información sobre cómo solucionar este problema, consulte Paquetes y Paquetes que no se actualizan más arriba.
También se recomienda comparar la lista de paquetes de una instancia de AEM 6.4 nueva con la actualizada para detectar los paquetes que no se han actualizado. Esto proporcionará un alcance más cercano de lo que buscar en el error.log .

Paquetes personalizados que no cambian al estado activo

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 generalmente lleva a dependencias insatisfechas.
La API que se eliminó debe marcarse como obsoleta en una de las versiones anteriores. Puede encontrar instrucciones sobre una migración directa del código en este aviso de desaprobación. Adobe tiene como objetivo crear versiones semánticas siempre que sea posible para que las versiones puedan indicar cambios de salto.
También es mejor comprobar si el cambio que ha causado el problema era absolutamente necesario y revertirlo si no lo es. Compruebe también si el aumento de la versión de la exportación de paquetes se ha incrementado más de lo necesario, tras una estricta versión semántica.

Interfaz de usuario de plataforma con errores

En el caso de que ciertas funciones de la interfaz de usuario no funcionen correctamente después de la actualización, primero debe buscar superposiciones personalizadas de la interfaz. Algunas estructuras podrían haber cambiado y la superposición podría necesitar una actualización o estar obsoleta.
A continuación, compruebe si hay errores de JavaScript que se puedan rastrear hasta las extensiones agregadas personalizadas que están vinculadas a bibliotecas de cliente. Lo mismo puede aplicarse a las CSS personalizadas que puedan estar causando problemas en el diseño de AEM.
Finalmente, compruebe si hay una configuración incorrecta con la que Javascript podría no poder lidiar. Este suele ser el caso de extensiones desactivadas incorrectamente.

Componentes personalizados, plantillas o extensiones de interfaz de usuario que funcionan mal

En la mayoría de los casos, las causas de origen 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 aparecer al usar los componentes por primera vez.
La manera de lidiar con el código personalizado erróneo es realizar pruebas de humo para identificar la causa. Una vez que lo encuentre, consulte las recomendaciones en esta sección de # del artículo para ver cómo corregirlas.

Personalizaciones que faltan en etc.

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

Análisis de error.log y upgrade.log

En la mayoría de los casos, es necesario consultar los registros para buscar errores a fin de encontrar la causa de un problema. Sin embargo, en caso de actualizaciones, también es necesario supervisar los problemas de dependencia, ya que los paquetes antiguos podrían no actualizarse 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 se está enfrentando. Puede hacerlo mediante herramientas como grep, mediante:
grep -v UnrelatedErrorString

Es posible que algunos mensajes de error no sean explicativos inmediatamente. En este caso, mirar el contexto en el que se producen también puede ayudar a comprender dónde se creó el error. Puede separar el error mediante:
  • grep -B para agregar líneas antes del error;
o
  • grep -A para agregar líneas después de.
En algunos casos también se pueden encontrar errores en los mensajes WARN, ya que puede haber casos válidos que lleven a este estado y la aplicación no siempre puede decidir si se trata de un error real. Asegúrese de consultar estos mensajes también.

Contactar con la asistencia técnica de Adobe

Si ha seguido los consejos de esta página y sigue teniendo problemas, póngase en contacto con el servicio de asistencia técnica de Adobe. Para proporcionar la mayor 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.