Supervisión y mantenimiento de la instancia de Adobe Experience Manager monitoring-and-maintaining-your-aem-instance

AEM Una vez implementadas las instancias de, debe monitorizar y mantener su funcionamiento, rendimiento e integridad.

Un factor clave aquí es que para reconocer posibles problemas, debe saber cómo se ve y se comporta su sistema en condiciones normales. La mejor manera de conseguir esta capacidad es supervisar el sistema y recopilar información a lo largo del tiempo.

Copias de seguridad backups

Es recomendable realizar copias de seguridad de:

Es probable que su compañía tenga una directiva de copia de seguridad que usted siga. Entre las consideraciones adicionales sobre qué y cuándo realizar copias de seguridad se incluyen las siguientes:

A menudo, se realiza una copia de seguridad completa a intervalos regulares (por ejemplo, diaria, semanal o mensual), con copias de seguridad incrementales intermedias (por ejemplo, por hora, diaria o semanal).

Copia de seguridad de la instalación del software backing-up-your-software-installation

Después de la instalación o cambios significativos en la configuración, cree un copia de seguridad de la instalación del software.

Para llevar a cabo este tarea, haga una copia de seguridad de todo su repositorio y luego:

Copia de seguridad del repositorio backing-up-your-repository

El Copia de seguridad y restauración Esta sección de la documentación de CRX cubre todos los problemas relacionados con las copias de seguridad del repositorio CRX.

Para obtener más información sobre cómo realizar una copia de seguridad en línea "activa", consulte Creación de una copia de seguridad en línea.

Depuración de versiones version-purging

El Purgar versiones está diseñada para depurar las versiones de un nodo o una jerarquía de nodos en el repositorio. Su propósito principal es ayudarle a reducir el tamaño del repositorio eliminando las versiones antiguas de los nodos.

AEM Esta sección trata sobre las operaciones de mantenimiento relacionadas con la función de control de versiones de las versiones de los informes de la aplicación de. El Purgar versión está diseñada para depurar las versiones de un nodo o una jerarquía de nodos en el repositorio. Su propósito principal es ayudarle a reducir el tamaño del repositorio eliminando las versiones antiguas de los nodos.

Información general overview

El Purgar versiones está disponible como tarea de mantenimiento semanal. Antes de usar por primera vez, debe añadirse y luego configurarse. Después, se puede ejecutar bajo petición o de forma semanal.

Depuración de versiones de un sitio Web purging-versions-of-a-web-site

Para purgar versiones de un sitio web, siga estos pasos:

Ejecución en seco: Análisis de la consola analyzing-the-console

La IU clásica proporciona un Ejecución en seco opción de:

El proceso enumera todos los nodos que se han procesado. Durante el proceso, un nodo puede tener uno de los siguientes estados:

Además, la consola proporciona información útil sobre las versiones:

En el ejemplo siguiente:

Trabajar con registros de auditoría y archivos de registro working-with-audit-records-and-log-files

Los registros de auditoría y los archivos de registro relacionados con Adobe Experience Manager AEM () se encuentran en varias ubicaciones. A continuación se proporciona una descripción general de lo que puede encontrar y dónde puede encontrarlo.

Uso de registros working-with-logs

AEM WCM registra registros detallados. Después de desempaquetar e iniciar Quickstart, podrá encontrar los registros en:

Rotación de archivo de registro log-file-rotation

La rotación del archivo de registro hace referencia al proceso que limita el crecimiento del archivo creando un archivo periódicamente. AEM En, un archivo de registro llamado: error.log se gira una vez al día según las reglas dadas:

Búsqueda de los archivos de registro finding-the-log-files

AEM Varios archivos de registro se guardan en el servidor de archivos donde instaló la instalación de la siguiente manera:

Activación del nivel de registro de depuración activating-the-debug-log-level

El nivel de registro predeterminado (Configuración de registro de Apache Sling) es Information, por lo que los mensajes de depuración no se registran.

Para activar el nivel de registro de depuración para un registrador, establezca la propiedad org.apache.sling.commons.log.level para depurar en el repositorio. Por ejemplo, el /libs/sling/config/org.apache.sling.commons.log.LogManager para configurar el Registro global de Apache Sling.

Una línea del archivo de depuración suele comenzar con DEBUG y, a continuación, proporciona el nivel de registro, la acción del instalador y el mensaje de registro. Por ejemplo:

DEBUG 3 WebApp Panel: WebApp successfully deployed

Los niveles de registro son los siguientes:

Crear un archivo de registro personalizado create-a-custom-log-file

En determinadas circunstancias, es posible que desee crear un archivo de registro personalizado con un nivel de registro diferente. En el repositorio, haga lo siguiente:

La consola Felix también proporciona información sobre la compatibilidad de registros de Sling en ../system/console/slinglog; por ejemplo, https://localhost:4502/system/console/slinglog.

Búsqueda de registros de auditoría finding-the-audit-records

Los registros de auditoría se mantienen para proporcionar un registro de quién hizo qué y cuándo. AEM Se generan diferentes registros de auditoría para los eventos WCM y OSGi de la.

AEM Registros de auditoría de WCM mostrados durante la creación de páginas aem-wcm-audit-records-shown-when-page-authoring

AEM Registros de auditoría de WCM dentro del repositorio aem-wcm-auditing-records-within-the-repository

Dentro de /var/audit carpeta, los registros de auditoría se mantienen según el recurso. Puede explorar en profundidad hasta que vea los registros individuales y la información que contienen.

Estas entradas contienen la misma información que se muestra al editar una página.

Registros de auditoría OSGi de la consola web osgi-audit-records-from-the-web-console

Los eventos OSGi también generan registros de auditoría que se pueden ver desde el Estado de configuración pestaña > Archivos de registro AEM en la consola web de la:

Supervisión de los agentes de replicación monitoring-your-replication-agents

Puede supervisar su colas de replicación para detectar cuándo una cola está caída o bloqueada, lo que a su vez podría indicar un problema con una instancia de publicación o un sistema externo:

Para supervisar un agente de replicación:

De nuevo, puede desarrollar una solución para detectar todos los agentes de replicación (ubicados en /etc/replication/author o /etc/replication/publish) y, a continuación, compruebe el estado del agente ( enabled, disabled) y la cola subyacente ( active, idle, blocked).

Monitorización del rendimiento monitoring-performance

Optimización del rendimiento es un proceso interactivo que recibe atención durante el desarrollo. Después de la implementación, se revisa después de intervalos o eventos específicos.

Los métodos utilizados al recopilar información para la optimización también se pueden utilizar para la monitorización continua.

A continuación se enumeran los problemas comunes de rendimiento que se producen, junto con propuestas sobre cómo detectarlos y contrarrestarlos.

Los problemas de rendimiento pueden provenir de varias causas que no tienen nada que ver con su sitio web, incluidas las ralentizaciones temporales en la velocidad de conexión, la carga de la CPU y muchas más.

También puede afectar a todos los visitantes o solo a un subconjunto de ellos.

Toda esta información debe obtenerse, ordenarse y analizarse antes de optimizar el rendimiento general o resolver problemas específicos.

Herramientas para monitorizar y analizar el rendimiento tools-for-monitoring-and-analyzing-performance

A continuación se ofrece una breve descripción general de algunas de las herramientas disponibles para supervisar y analizar el rendimiento.

Algunas de estas herramientas dependen del sistema operativo.

Interpretación de request.log interpreting-the-request-log

AEM Este archivo registra información básica acerca de cada solicitud realizada a la persona que lo ha solicitado De esto se pueden extraer valiosas conclusiones.

El request.log ofrece una forma integrada de obtener información sobre cuánto tiempo tardan las solicitudes. A efectos de desarrollo, resulta útil tail -f el request.log y observe los tiempos de respuesta lentos. Para analizar un request.log, el Adobe recomienda el uso de rlog.jar que permite ordenar y filtrar los tiempos de respuesta.

El Adobe recomienda aislar las páginas "lentas" del request.logy luego ajustarlos individualmente para obtener un mejor rendimiento. Incluya métricas de rendimiento por componente o utilice una herramienta de perfil de rendimiento como [yourkit](https://www.yourkit.com/).

Monitorización del tráfico en el sitio web monitoring-traffic-on-your-website

El registro de solicitudes registra cada solicitud realizada, junto con la respuesta obtenida:

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

Al sumar todas las entradas de GET dentro de períodos específicos (por ejemplo, en varios períodos de 24 horas), puede realizar declaraciones sobre el tráfico promedio en el sitio web.

Monitorización de los tiempos de respuesta con request.log monitoring-response-times-with-the-request-log

Un buen punto de partida para el análisis del rendimiento es el registro de solicitudes:

<cq-installation-dir>/crx-quickstart/logs/request.log

El registro tiene el siguiente aspecto (las líneas se abrevian para simplificar):

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Este registro tiene una línea por solicitud o respuesta:

Mediante pequeños scripts, puede extraer la información necesaria del archivo de registro y combinar las estadísticas que desee. Desde estas estadísticas, puede ver qué páginas o tipos de páginas son lentos y si el rendimiento general es satisfactorio.

Monitorización de los tiempos de respuesta de búsqueda con el request.log monitoring-search-response-times-with-the-request-log

Las solicitudes de búsqueda también se registran en el archivo de registro:

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Por lo tanto, como se ha indicado anteriormente, puede utilizar secuencias de comandos para extraer la información relevante y crear estadísticas.

Sin embargo, una vez que haya determinado el tiempo de respuesta, analice por qué la solicitud está tardando en responder y qué se puede hacer para mejorarla.

Monitorización del número y el impacto de usuarios simultáneos monitoring-the-number-and-impact-of-concurrent-users

De nuevo, la request.log puede utilizarse para controlar la concurrencia y la reacción del sistema a ella.

Se deben realizar pruebas para determinar cuántos usuarios simultáneos puede manejar el sistema antes de que se vea un impacto negativo. De nuevo, se pueden utilizar secuencias de comandos para extraer los resultados del archivo de registro:

31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Uso de log.jar para buscar solicitudes con tiempos de larga duración using-rlog-jar-to-find-requests-with-long-duration-times

AEM La incluye varias herramientas de ayuda en lo siguiente:
<cq-installation-dir>/crx-quickstart/opt/helpers

Una de estas herramientas, rlog.jar, se puede utilizar para ordenar rápidamente request.log de modo que las solicitudes se muestren por duración, desde la más larga a la más corta.

El siguiente comando muestra los posibles argumentos:

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

Por ejemplo, puede ejecutarlo especificando request.log como parámetro y mostrar las diez primeras solicitudes que tienen la duración más larga:

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

Concatenar al individuo request.log archivos si debe realizar esta operación en una muestra de datos de gran tamaño.

Apache Bench apache-bench

Para minimizar el impacto de los casos especiales (como la recolección de basura), se recomienda utilizar una herramienta como apachebench (por ejemplo, ab para obtener más documentación) para ayudar a identificar las fugas de memoria y analizar selectivamente el tiempo de respuesta.

Apache Bench se puede utilizar de la siguiente manera:

$ ab -c 5 -k -n 1000 "https://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

Los números anteriores se toman de un portátil MAcBook Pro estándar (mediados de 2010) que accede a la página de la empresa de Geometrixx AEM, tal como se incluye en una instalación predeterminada de la. La página es sencilla, pero no está optimizada para el rendimiento.

El apachebench también muestra el tiempo por solicitud como media en todas las solicitudes simultáneas; consulte Time per request: 54.595 [ms] (media, en todas las solicitudes simultáneas). Puede cambiar el valor del parámetro de concurrencia -c (número de solicitudes múltiples que se realizan a la vez) para ver cualquier efecto.

Contadores de solicitudes request-counters

La información sobre el tráfico de la solicitud (número de solicitudes durante un período de tiempo específico) le proporciona una indicación de la carga de la instancia. Esta información se puede extraer de request.log, aunque el uso de contadores automatiza la recopilación de datos para que pueda ver lo siguiente:

Para automatizar la recopilación de información, también puede instalar un RequestFilter para incrementar un contador en cada solicitud. Se pueden usar varios contadores para diferentes periodos de tiempo.

La información recopilada se puede utilizar para indicar:

Comentarios del HTML html-comments

Se recomienda que cada proyecto incluya html comments para el rendimiento del servidor. Se pueden encontrar muchos buenos ejemplos públicos. Seleccione una página, abra el origen de la página para verlo y desplácese hasta la parte inferior. Se pueden ver códigos como los siguientes:

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Monitorización del rendimiento con JConsole monitoring-performance-using-jconsole

El comando herramienta jconsole está disponible con el JDK de.

Supervisión del rendimiento mediante (J)VisualVM monitoring-performance-using-j-visualvm

Para JDK 6-8, el comando tool visualvm está disponible. Después de instalar un JDK, puede hacer lo siguiente:

Puede utilizar esta herramienta para generar volcados de hilos y volcados de cabezales de memoria. El equipo de soporte técnico suele solicitar esta información.

Recopilación de información information-collection

Conocer en la medida de lo posible su instalación puede ayudarle a averiguar qué puede haber causado un cambio en el rendimiento y si estos cambios están justificados. Recopile estas métricas a intervalos regulares para poder ver fácilmente cambios significativos.

La siguiente información puede resultar útil:

¿Cuántos autores están trabajando con el sistema? how-many-authors-are-working-with-the-system

Para ver el número de autores que han utilizado el sistema desde la instalación, utilice la línea de comandos:

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Para ver el número de autores que trabajan en una fecha determinada:

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

¿Cuál es el número promedio de activaciones de página por día? what-is-the-average-number-of-page-activations-per-day

Para ver el número total de activaciones de página desde la instalación del servidor, utilice una consulta del repositorio; a través de CRXDE - Herramientas - Consulta:

A continuación, calcule el número de días transcurridos desde la instalación para calcular la media.

¿Cuántas páginas mantiene actualmente en este sistema? how-many-pages-do-you-currently-maintain-on-this-system

Para ver el número de páginas que hay actualmente en el servidor, utilice una consulta del repositorio; a través de CRXDE - Herramientas - Consulta:

Si usa MSM, ¿cuál es el número promedio de despliegues por mes? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Para determinar el número total de despliegues desde la instalación, utilice una consulta del repositorio; a través de CRXDE - Herramientas - Consulta:

Calcule el número de meses transcurridos desde la instalación para calcular la media.

¿Cuál es el número promedio de Live Copies por mes? what-is-the-average-number-of-live-copies-per-month

Para determinar el número total de Live Copies realizadas desde la instalación, utilice una consulta del repositorio; a través de CRXDE - Herramientas - Consulta:

Utilice de nuevo el número de meses transcurridos desde la instalación para calcular la media.

Si utiliza AEM Assets, ¿cuántos recursos mantiene actualmente en Assets? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Para ver cuántos recursos DAM mantiene actualmente, utilice una consulta del repositorio; a través de CRXDE - Herramientas - Consulta:

¿Cuál es el tamaño promedio de los recursos? what-is-the-average-size-of-the-assets

Para determinar el tamaño total de la /var/dam carpeta:

¿Cuántas plantillas se están utilizando actualmente? how-many-templates-are-currently-used

Para ver el número de plantillas que hay actualmente en el servidor, utilice una consulta del repositorio; a través de CRXDE - Herramientas - Consulta:

¿Cuántos componentes se utilizan actualmente? how-many-components-are-currently-used

Para ver el número de componentes que hay actualmente en el servidor, utilice una consulta del repositorio; a través de CRXDE - Herramientas - Consulta:

¿Cuántas solicitudes por hora tiene en el sistema de creación en la hora de mayor actividad? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Para determinar las solicitudes por hora que tiene en el sistema de creación en la hora de mayor actividad:

¿Cuántas solicitudes por hora tiene en el sistema de publicación en las horas de mayor actividad? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Repita el procedimiento anterior en la instancia de publicación.

Análisis de escenarios específicos analyzing-specific-scenarios

A continuación se muestra una lista de sugerencias sobre qué comprobar si comienza a experimentar ciertos problemas de rendimiento. La lista (lamentablemente) no es completa.

CPU al 100% cpu-at

Si la CPU del sistema se ejecuta constantemente al 100%, consulte lo siguiente:

Memoria insuficiente out-of-memory

Aunque estos errores deben detectarse durante el desarrollo y la prueba, algunos escenarios pueden saltarse.

Si el sistema se está quedando sin memoria, este problema se puede ver de varias maneras, incluida la degradación del rendimiento y los mensajes de error, incluido el subtexto:

java.lang.OutOfMemoryError

En estos casos, compruebe:

E/S de disco disk-i-o

Si el sistema se está quedando sin espacio en disco o nota que se ha golpeado el disco, consulte:

Degradación regular del rendimiento regular-performance-degradation

Si ve que el rendimiento de su instancia se deteriora después de cada reinicio (a veces una semana o más tarde), se puede comprobar lo siguiente:

Ajuste de JVM jvm-tuning

La máquina virtual Java™ (JVM) ha mejorado en cuanto a la optimización (especialmente desde Java™ 7). Por lo tanto, a menudo resulta adecuado especificar un tamaño de JVM fijo razonable y utilizar los valores predeterminados.

Si la configuración predeterminada no es adecuada, es importante establecer un método para supervisar y evaluar el rendimiento de GC. Hágalo antes de intentar ajustar la JVM. Este proceso puede incluir factores de monitorización, como el tamaño de la pila, el algoritmo y otros aspectos.

Algunas opciones comunes son:

El registro resultante se puede ingerir mediante un visualizador GC como:

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

O JConsole:

Puede ver cuánta memoria se está utilizando, qué algoritmos de GC se están utilizando, cuánto tardan en ejecutarse y qué efecto tiene este proceso en el rendimiento de la aplicación. Sin él, la sintonización es solo "perillas giratorias aleatoriamente".