Supervisión y mantenimiento de la instancia de AEM monitoring-and-maintaining-your-aem-instance

Una vez que las instancias de AEM se hayan implementado, se necesitarán ciertas tareas para supervisar y mantener su funcionamiento, rendimiento e integridad.

Un factor clave aquí es que para reconocer los problemas potenciales necesita saber cómo se ven y comportan sus sistemas en condiciones normales. Para ello, es mejor supervisar el sistema y recopilar información durante un período de tiempo.

Copias de seguridad backups

Se recomienda realizar copias de seguridad de:

Su empresa probablemente tendrá una política de backup que deberá seguir, consideraciones adicionales sobre qué hacer una copia de seguridad y cuándo incluirlas:

A menudo se realiza una copia de seguridad completa a intervalos regulares (por ejemplo, a diario, semanal o mensual), con backups incrementales intermedios (por ejemplo, por hora, diariamente o semanalmente).

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, realice una copia de seguridad de la instalación del software.

Para ello, debe hacer una copia de seguridad de todo el repositorio y luego:

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

La variable Copia de seguridad y restauració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 hacer una copia de seguridad "en caliente" en línea, consulte Creación de una copia de seguridad en línea.

Depuración de versiones version-purging

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

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

Información general overview

La variable Purgar versiones está disponible en la Herramientas consola under Versiones o directamente en:

https://<server>:<port>/etc/versioning/purge.html

Ruta de inicio Una ruta absoluta en la que se debe realizar la depuración. Para seleccionar la Ruta de inicio, haga clic en el navegador de árbol del repositorio.

Recursivo Al depurar datos, puede elegir entre realizar la operación en un nodo o en una jerarquía completa seleccionando Recursivo. En el último caso, la ruta dada define el nodo raíz de la jerarquía.

Máximas versiones que mantener Número máximo de versiones que se deben mantener para un nodo. Cuando este número supera este valor, se depuran las versiones más antiguas.

Edad máxima de la versión La edad máxima de la versión de un nodo. Cuando la antigüedad de una versión supera este valor, se depura.

Ensayo Como la eliminación de versiones del contenido es definitiva y no se puede revertir sin restaurar una copia de seguridad, la herramienta Purge Versions proporciona un modo de ejecución en seco que le permite obtener una vista previa de las versiones depuradas. Para iniciar una ejecución en seco del proceso de depuración, haga clic en Ensayo.

Purga Inicie la depuración de las versiones en el nodo definido por la ruta de inicio.

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

Para purgar versiones de un sitio web, siga este procedimiento:

Análisis de la consola analyzing-the-console

La variable Ensayo y Purga los procesos enumeran 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 siguiente ejemplo:

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

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

Uso de registros working-with-logs

AEM WCM registra registros detallados. Después de desempaquetar e iniciar QuickStart, puede encontrar los registros en:

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

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

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

En el servidor de archivos donde instaló AEM se guardan varios archivos de registro:

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 Información, 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, en /libs/sling/config/org.apache.sling.commons.log.LogManager para configurar la variable registro global de Apache Sling.

Una línea en el archivo de depuración normalmente comienza 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. Puede hacerlo en el repositorio:

La consola Felix también proporciona información sobre la compatibilidad con el registro de Sling en ../system/console/slinglog; por ejemplo http://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. Se generan diferentes registros de auditoría tanto para AEM eventos WCM como OSGi.

AEM registros de auditoría de WCM que se muestran al crear páginas aem-wcm-audit-records-shown-when-page-authoring

AEM WCM Auditing records 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 de OSGi de la consola web osgi-audit-records-from-the-web-console

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

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

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

Para monitorizar un agente de replicación:

Una vez más, 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, suele revisarse 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 deberse a una serie de causas que no tienen nada que ver con su sitio web, incluidas las desaceleraciones 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 poder 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 monitorizar y analizar el rendimiento.

Algunos de ellos dependerán del sistema operativo.

Interpretación del archivo request.log interpreting-the-request-log

Este archivo registra información básica sobre cada solicitud realizada a AEM. De estas valiosas conclusiones se pueden extraer.

La variable request.log ofrece una forma integrada de obtener una visión de cuánto tardan las solicitudes. Para fines de desarrollo, resulta útil tail -f el request.log y observe los tiempos de respuesta lentos. Para analizar un tamaño mayor request.log le recomendamos que uso de rlog.jar que le permite ordenar y filtrar los tiempos de respuesta.

Se recomienda aislar las páginas "lentas" del request.logy, a continuación, ajustarlos de forma individual para obtener un mejor rendimiento. Esto generalmente se hace incluyendo métricas de rendimiento por componente o utilizando 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 realizada:

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

Al totalizar todas las entradas de GET dentro de un periodo específico (por ejemplo, en varios períodos de 24 horas), puede realizar declaraciones sobre el tráfico promedio en su 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 de 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 por simplicidad):

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:

Con secuencias de comandos pequeñas, puede extraer la información necesaria del archivo de registro y ensamblar las estadísticas que desee. A partir de estos datos, 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 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, es posible que tenga que analizar por qué la solicitud está tardando su tiempo y qué se puede hacer para mejorar la respuesta.

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

Una vez más, el request.log puede utilizarse para controlar la concurrencia y la reacción del sistema ante ella.

Se deben realizar pruebas para determinar cuántos usuarios simultáneos puede gestionar el sistema antes de que se vea un impacto negativo. De nuevo, se pueden utilizar secuencias de comandos para extraer 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 rlog.jar para encontrar solicitudes con largos tiempos de duración using-rlog-jar-to-find-requests-with-long-duration-times

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

Uno de ellos, rlog.jar, se puede usar para ordenar rápidamente request.log de modo que las solicitudes se muestren por duración, desde el más largo hasta el más corto.

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 muestran las 10 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

Es posible que necesite concatenar al individuo request.log si necesita realizar esta operación en una muestra de datos de gran tamaño.

Apache Bench apache-bench

Para minimizar el impacto de casos especiales (como la colección de residuos, etc.), se recomienda utilizar una herramienta como apachebench (consulte, por ejemplo, ab para obtener más documentación) para ayudar a identificar 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 "http://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 empresa de geometrixx, tal como se incluye en una instalación AEM predeterminada. La página es muy sencilla, pero no está optimizada para el rendimiento.

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

Contadores de solicitudes request-counters

La información sobre el tráfico de solicitudes (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 automatizará la recopilación de datos para que pueda ver:

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 puede utilizarse para indicar:

Comentarios del HTML html-comments

Se recomienda que todos los proyectos incluyan 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 verla y desplácese hasta la parte inferior; se verá código como el siguiente:

</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.

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

Desde JDK 1.6, el comando herramienta jvisualvm está disponible. Después de instalar JDK 1.6, puede:

Puede utilizar esta herramienta para generar volcados de subprocesos y volcados de cabezales de memoria. El equipo de asistencia técnica suele solicitar esta información.

Recopilación de información information-collection

Conocer en la medida de lo posible sobre la instalación puede ayudarle a rastrear qué puede haber causado un cambio en el rendimiento y si estos cambios están justificados. Estas métricas deben recopilarse a intervalos regulares para poder ver fácilmente los cambios más importantes.

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 que han transcurrido 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 de repositorio; a través de CRXDE - Herramientas - Consulta:

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

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

Calcule el número de meses que han transcurrido 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:

Vuelva a utilizar el número de meses que han transcurrido 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 de 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 variable /var/dam carpeta:

¿Cuántas plantillas se utilizan actualmente? how-many-templates-are-currently-used

Para ver el número de plantillas que hay actualmente en el servidor, utilice una consulta de 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 de repositorio; a través de CRXDE - Herramientas - Consulta:

¿Cuántas solicitudes por hora hay en el sistema de creación en tiempo de espera? 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 el momento de mayor actividad:

¿Cuántas solicitudes por hora tiene en el sistema de publicación en tiempo de pico? 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

La siguiente es una lista de sugerencias sobre qué comprobar si comienza a experimentar determinados problemas de rendimiento. La lista no es (lamentablemente) totalmente completa.

CPU al 100% cpu-at

Si la CPU de su sistema está funcionando constantemente al 100%, consulte:

Memoria insuficiente out-of-memory

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

Si el sistema se está quedando sin memoria, esto puede verse 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 observa que se está iniciando el almacenamiento en disco, consulte:

Degradación del rendimiento normal 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 después), se puede comprobar lo siguiente:

Ajuste de JVM jvm-tuning

La máquina virtual Java (JVM) ha mejorado significativamente con respecto al ajuste (especialmente desde Java 7). Debido a esto, especificar un tamaño razonable de JVM fijo y utilizar los valores predeterminados a menudo será adecuado.

Si los ajustes predeterminados no son adecuados, es importante establecer un método para supervisar y evaluar el rendimiento de GC antes de intentar ajustar el JVM; esto puede implicar factores de monitorización como, por ejemplo, tamaño de pila, 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:

Esto le ayudará a ver cuánta memoria se está utilizando, qué algoritmos GC se están utilizando, cuánto tiempo tardan en ejecutarse y qué efecto tiene en el rendimiento de la aplicación. Sin esto, sintonizar es sólo "mandos de ajuste aleatorio".