El Panel de Operaciones de AEM 6 ayuda a los operadores de sistemas a supervisar AEM estado del sistema de un vistazo. También proporciona información de diagnóstico generada automáticamente sobre aspectos relevantes de la AEM y permite configurar y ejecutar la automatización de mantenimiento independiente para reducir significativamente las operaciones de los proyectos y los casos de apoyo. El Panel de operaciones puede ampliarse con tareas de mantenimiento y comprobaciones de estado personalizadas. Además, se puede acceder a los datos del Panel de operaciones desde herramientas de supervisión externas a través de JMX.
El Panel de Operaciones:
Se puede acceder a ella si ingresa a Herramientas - Operaciones desde la pantalla de bienvenida de AEM.
Para poder acceder al Panel de operaciones, el usuario que ha iniciado sesión debe formar parte del grupo de usuarios "Operadores". Para obtener más información, consulte la documentación sobre Administración de derechos de usuario, grupo y acceso.
El sistema de informes de estado proporciona información sobre el estado de una instancia de AEM a través de Sling Health Checks. Esto se puede realizar mediante solicitudes OSGI, JMX, HTTP (a través de JSON) o mediante la IU táctil. Oferta las medidas y el umbral de ciertos contadores configurables y, en algunos casos, oferta información sobre cómo resolver el problema.
Tiene varias características, que se describen a continuación.
Los Informes de estado son un sistema de tarjetas que indica el buen o mal estado con respecto a un área de producto específica. Estas tarjetas son visualizaciones de Sling Health Checks, que acumulada datos de JMX y otras fuentes y expone información procesada nuevamente como MBeans. Estos MBeans también se pueden inspeccionar en la consola web JMX, bajo el dominio org.apache.sling.healthCheck.
Se puede acceder a la interfaz de Informes de estado a través del menú Herramientas - Operaciones - Informes de estado en la pantalla de bienvenida de AEM o directamente a través de la siguiente dirección URL:
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
El sistema de tarjetas expone tres estados posibles: OK, WARN y CRITICAL. Los estados son el resultado de reglas y umbrales, que se pueden configurar pasando el ratón sobre la tarjeta y haciendo clic en el icono de engranaje en la barra de acciones:
Existen dos tipos de controles de salud en el AEM 6:
Una comprobación de estado individual es una única comprobación de estado que corresponde a una tarjeta de estado. Las comprobaciones de estado individuales pueden configurarse con reglas o umbrales y pueden proporcionar una o más sugerencias y vínculos para resolver problemas de salud identificados. Veamos la casilla "Errores de registro" como ejemplo: si hay entradas ERROR en los registros de instancia, las encontrará en la página de detalles de la comprobación de estado. En la parte superior de la página verá un vínculo al analizador de "Mensaje de registro" en la sección Herramientas de diagnóstico, que le permitirá analizar estos errores con más detalle y reconfigurar los registradores.
Una Comprobación del estado compuesto es una comprobación que agrega información de varias comprobaciones individuales.
Las comprobaciones de estado compuestas se configuran con la ayuda de etiquetas de filtro. En esencia, todas las comprobaciones individuales que tengan la misma etiqueta de filtro se agruparán como una comprobación de estado compuesta. Una comprobación de estado compuesta solo tendrá un estado correcto si todas las comprobaciones únicas que agrega también tienen el estado correcto.
En el Panel de operaciones puede visualizar el resultado de las comprobaciones de estado individuales y compuestas.
La creación de una comprobación de estado individual implica dos pasos: implementar una comprobación de estado de Sling y agregar una entrada para la comprobación de estado en los nodos de configuración del Panel.
Para crear una comprobación de estado de Sling, debe crear un componente OSGI que implemente la interfaz Sling HealthCheck. Deberá agregar este componente dentro de un paquete. Las propiedades del componente identificarán completamente la comprobación de estado. Una vez instalado el componente, se creará automáticamente un MBean de JMX para la comprobación de estado. Consulte la Documentación de comprobación de estado de Sling para obtener más información.
Ejemplo de un componente de comprobación de estado de Sling, escrito con anotaciones del componente de servicio OSGI:
@Component(service = HealthCheck.class,
property = {
HealthCheck.NAME + "=Example Check",
HealthCheck.TAGS + "=example",
HealthCheck.TAGS + "=test",
HealthCheck.MBEAN_NAME + "=exampleHealthCheckMBean"
})
public class ExampleHealthCheck implements HealthCheck {
@Override
public Result execute() {
// health check code
}
}
La propiedad MBEAN_NAME
define el nombre del grano que se generará para esta comprobación de estado.
Después de crear una comprobación de estado, es necesario crear un nuevo nodo de configuración para que sea accesible en la interfaz de Panel de operaciones. Para este paso, es necesario conocer el nombre del grano JMX de la Health Check (propiedad MBEAN_NAME
). Para crear una configuración para la comprobación de estado, abra CRXDE y agregue un nuevo nodo (de tipo nt:unestructure) en la siguiente ruta: /apps/settings/granite/operations/hc
Las siguientes propiedades deben establecerse en el nuevo nodo:
Nombre: sling:resourceType
String
granite/operations/components/mbean
Nombre: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
La ruta de acceso del recurso anterior se crea de la siguiente manera: si el nombre del grano de su Health Check es "test", agregue "test" al final de la ruta /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
Así que el camino final será:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
Asegúrese de que la ruta /apps/settings/granite/operations/hc
tiene las siguientes propiedades establecidas en true:
sling:configCollectionInherit
sling:configPropertyInherit
Esto indicará al administrador de configuración que combine las nuevas configuraciones con las existentes de /libs
.
La función de la comprobación de estado compuesta consiste en acumulado de varias comprobaciones de estado individuales que compartan un conjunto de funciones comunes. Por ejemplo: la comprobación de estado compuesta de seguridad agrupa todas las comprobaciones de estado individuales que realizan verificaciones relacionadas con la seguridad. El primer paso para crear una comprobación compuesta es agregar una nueva configuración OSGI. Para que se muestre en el Panel de operaciones, se debe agregar un nuevo nodo de configuración, de la misma manera que lo hicimos para una simple comprobación.
Vaya al Administrador de configuración web en la consola OSGI. Puede hacerlo accediendo a https://serveraddress:port/system/console/configMgr
Busque la entrada denominada Comprobación del estado compuesto de Apache Sling. Después de encontrarlo, observe que ya hay dos configuraciones disponibles: una para las comprobaciones del sistema y otra para las comprobaciones de seguridad.
Cree una nueva configuración pulsando el botón "+" en el lado derecho de la configuración. Aparecerá una nueva ventana, como se muestra a continuación:
Cree una configuración y guárdela. Se creará un grano con la nueva configuración.
El propósito de cada propiedad de configuración es el siguiente:
hc.tags
).Se crea un nuevo grano JMX para cada nueva configuración de la comprobación de estado compuesta de Apache Sling.**
Finalmente, la entrada de la comprobación de estado compuesta que se acaba de crear debe agregarse en los nodos de configuración de Panel de operaciones. El procedimiento es el mismo que para los controles sanitarios individuales: se debe crear un nodo de tipo nt:unestructure en /apps/settings/granite/operations/hc
. La propiedad resource del nodo se definirá por el valor de hc.media.name en la configuración OSGI.
Si, por ejemplo, creó una configuración y estableció el valor hc.mbean.name en diskusage, los nodos de configuración tendrán este aspecto:
Nombre: Composite Health Check
nt:unstructured
Con las siguientes propiedades:
Nombre: sling:resourceType
String
granite/operations/components/mbean
Nombre: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
Si crea comprobaciones de estado individuales que pertenecen lógicamente a una comprobación compuesta que ya está presente en el Panel de forma predeterminada, se capturarán y agruparán automáticamente en la correspondiente comprobación compuesta. Debido a esto, no es necesario crear un nuevo nodo de configuración para estas comprobaciones.
Por ejemplo, si crea una comprobación de estado de seguridad individual, todo lo que necesita hacer es asignarle la etiqueta "seguridad" y se instalará, automáticamente aparecerá bajo la comprobación compuesta de comprobaciones de seguridad en el Panel de operaciones.
zHealthcheck Name | Descripción |
Rendimiento de consultas | Esta comprobación de estado se simplificó en AEM 6.4 y ahora comprueba el El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=queryStatus,type=HealthCheck. |
Longitud de la cola de observación | La longitud de la cola de observación se repite en todos los oyentes de Evento y observadores en segundo plano, compara su
La longitud máxima de cada cola proviene de configuraciones separadas (Oak y AEM), y no se puede configurar desde esta comprobación de estado. El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck. |
Límites de recorrido de la consulta | Límites de recorrido de consulta comprueba los atributos
El grano para esta comprobación de estado es org.apache.sling.healthcheck:name=queryTraversalLimitsBundle,type=HealthCheck. |
Relojes sincronizados | Esta comprobación solo es relevante para clústeres de nodos de documento. Devuelve el siguiente estado:
El grano para esta comprobación de estado es org.apache.sling.santhcheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck. |
Índices asíncronos | Comprobación de índices asincrónicos:
Se pueden configurar los umbrales de estado Crítico y Advertir. El grano para esta comprobación de estado es org.apache.sling.healthcheck:name=asyncIndexHealthCheck,type=HealthCheck. Nota: Esta comprobación de estado está disponible con AEM 6.4 y se ha rebasado a AEM 6.3.0.1. |
Índices grandes de Lucene | Esta comprobación utiliza los datos expuestos por los
Los umbrales se pueden configurar y el MBean para la comprobación de estado es org.apache.sling.healthcheck:name=largeIndexHealthCheck,type=HealthCheck. Nota: Esta comprobación está disponible con AEM 6.4 y ha sido retroportada a AEM 6.3.2.0. |
Mantenimiento del sistema | El mantenimiento del sistema es una comprobación compuesta que devuelve el valor OK si todas las tareas de mantenimiento se están ejecutando según la configuración. Tenga en cuenta que:
El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=systemcheck,type=HealthCheck. |
Cola de replicación | Esta comprobación repite los agentes de replicación y observa las colas. Para el elemento en la parte superior de la cola, la comprobación observa cuántas veces el agente volvió a intentar la replicación. Si el agente reintentó la replicación más que el valor del parámetro El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=ReplicationQueue,type=HealthCheck. |
Trabajos sling |
Sling Jobs comprueba el número de trabajos en cola en JobManager y lo compara con el
maxNumQueueJobs umbral y:
Solo se puede configurar el número máximo de trabajos en cola y tiene el valor predeterminado de 1000. El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=slingJobs,type=HealthCheck. |
Rendimiento de solicitudes | Esta comprobación observa la
El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=RequestsStatus,type=HealthCheck. |
Errores de registro | Esta comprobación devuelve el estado de advertencia si hay errores en el registro. El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck. |
Espacio en disco | La comprobación Espacio en disco observa los
Ambos umbrales son configurables. La comprobación solo funciona en instancias con un almacén de segmentos. El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=DiskSpaceHealthCheck,type=HealthCheck. |
Programador de comprobación de estado | Esta comprobación devuelve una advertencia si la instancia tiene trabajos de Quartz ejecutándose durante más de 60 segundos. Se puede configurar el umbral de duración aceptable. El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheck. |
Comprobaciones de seguridad | La comprobación de seguridad es un compuesto que agrega los resultados de varias comprobaciones relacionadas con la seguridad. Estas comprobaciones de estado individuales abordan diferentes preocupaciones de la lista de comprobación de seguridad disponible en la página de documentación de la lista de comprobación de seguridad. La comprobación es útil como prueba de humo de seguridad cuando se inicia la instancia. El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=security check,type=HealthCheck |
Paquetes activos | Active Bundles comprueba el estado de todos los paquetes y:
El parámetro de lista ignore es configurable. El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck. |
Comprobación de caché de código | Es una comprobación de estado que comprueba varias condiciones de JVM que pueden activar un error de CodeCache presente en Java 7:
El umbral El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=codeCacheHealthCheck,type=HealthCheck. |
Errores de ruta de búsqueda de medios | Comprueba si hay algún recurso en la ruta
El MBean de esta comprobación de estado es org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck. |
El Panel Health Check se puede integrar con Nagios a través de los granitos JMX. El ejemplo siguiente ilustra cómo agregar una comprobación que muestre la memoria usada en el servidor que ejecuta AEM.
Configure e instale Nagios en el servidor de supervisión.
A continuación, instale el ejecutor del complemento remoto de Nagios (NRPE).
Para obtener más información sobre cómo instalar Nagios y NRPE en su sistema, consulte la Documentación de Nagios.
Añada una definición de host para el servidor AEM. Esto se puede realizar mediante la interfaz web de Nagios XI, mediante el Administrador de configuración:
A continuación se muestra un ejemplo de archivo de configuración de host, en caso de que utilice Nagios Core:
define host {
address 192.168.0.5
max_check_attempts 3
check_period 24x7
check-command check-host-alive
contacts admin
notification_interval 60
notification_period 24x7
}
Instale Nagios y NRPE en el servidor de AEM.
Instale el complemento check_http_json en ambos servidores.
Defina un comando de comprobación JSON genérico en ambos servidores:
define command{
command_name check_http_json-int
command_line /usr/lib/nagios/plugins/check_http_json --user "$ARG1$" --pass "$ARG2$" -u 'https://$HOSTNAME$:$ARG3$/$ARG4$' -e '$ARG5$' -w '$ARG6$' -c '$ARG7$'
}
Añada un servicio para la memoria usada en el servidor AEM:
define service {
use generic-service
host_name my.remote.host
service_description AEM Author Used Memory
check_command check_http_json-int!<cq-user>!<cq-password>!<cq-port>!system/sling/monitoring/mbeans/java/lang/Memory.infinity.json!{noname}.mbean:attributes.HeapMemoryUsage.mbean:attributes.used.mbean:value!<warn-threshold-in-bytes>!<critical-threshold-in-bytes>
}
Compruebe su panel Nagios para ver el servicio recién creado:
El Panel Operación también proporciona acceso a las Herramientas de diagnóstico que pueden ayudar a encontrar y solucionar las causas profundas de las advertencias procedentes del Panel de comprobación de estado, así como proporcionar información de depuración importante para los operadores del sistema.
Entre sus características más importantes se encuentran:
Para acceder a la pantalla Herramientas de diagnóstico, vaya a Herramientas - Operaciones - Diagnóstico desde la pantalla de bienvenida de AEM. También puede acceder a la pantalla accediendo directamente a la siguiente URL: https://serveraddress:port/libs/granite/operations/content/diagnosis.html
La interfaz de usuario de los mensajes de registro mostrará todos los mensajes ERROR de forma predeterminada. Si desea que se muestren más mensajes de registro, debe configurar un registrador con el nivel de registro adecuado.
Los mensajes de registro utilizan un anexador de registro en memoria y, por lo tanto, no están relacionados con los archivos de registro. Otra consecuencia es que al cambiar los niveles de registro en esta interfaz de usuario no se cambiará la información que se registra en los archivos de registro tradicionales. Añadir y eliminar los inicios de sesión en esta interfaz de usuario solo afectará al registrador en memoria. Además, tenga en cuenta que el cambio de las configuraciones del registrador se reflejará en el futuro del registrador de memoria: las entradas que ya están registradas y que ya no son relevantes no se eliminan, pero las entradas similares no se registrarán en el futuro.
Puede configurar lo que se registra proporcionando configuraciones de registrador desde el botón de engranaje superior izquierdo en la interfaz de usuario. Allí puede agregar, eliminar o actualizar configuraciones de registrador. Una configuración de registrador está compuesta por un nivel de registro (WARN / INFO / DEBUG) y un nombre de filtro. El nombre del filtro tiene la función de filtrar el origen de los mensajes de registro que se registran. Como alternativa, si un registrador debe capturar todos los mensajes de registro para el nivel especificado, el nombre del filtro debe ser "raíz". La configuración del nivel de un registrador activará la captura de todos los mensajes con un nivel igual o superior al especificado.
Ejemplos:
Si planea capturar todos los mensajes ERROR, no se requiere ninguna configuración. Todos los mensajes ERROR se capturan de forma predeterminada.
Si planea capturar todos los mensajes ERROR, WARN y INFO - el nombre del registrador debe establecerse en: "root" y el nivel del registrador a: INFORMACIÓN.
Si planea capturar todos los mensajes procedentes de un paquete determinado (por ejemplo, com.adobe.granite), el nombre del registrador debe establecerse en: "com.adobe.granite" y el nivel del registrador a: DEBUG (capturará todos los mensajes ERROR, WARN, INFO y DEBUG), como se muestra en la siguiente imagen.
No se puede establecer un nombre de registrador para capturar solo los mensajes ERROR mediante un filtro especificado. De forma predeterminada, se capturan todos los mensajes ERROR.
La interfaz de usuario de los mensajes de registro no refleja el registro de errores real. A menos que configure otros tipos de mensajes de registro en la interfaz de usuario, solo verá mensajes ERROR. Para ver cómo mostrar mensajes de registro específicos, consulte las instrucciones anteriores.
La configuración de la página de diagnóstico no influye en lo que se registra en los archivos de registro y viceversa. Por lo tanto, aunque el registro de errores puede captar mensajes INFO, es posible que no los vea en la interfaz de usuario de los mensajes de registro. Además, a través de la interfaz de usuario es posible capturar mensajes DEBUG de ciertos paquetes sin que esto afecte al registro de errores. Para obtener más información sobre cómo configurar los archivos de registro, consulte Registro.
Con AEM 6.4, las tareas de mantenimiento se desconectan de la caja en un formato más informativo y enriquecido a nivel de la información. Esto permite una mejor visibilidad en el estado de las tareas de mantenimiento.
Si utiliza herramientas de terceros (como Splunk) para supervisar y reaccionar ante la actividad de tarea de mantenimiento, puede utilizar las siguientes sentencias de registro:
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
La página Rendimiento de la solicitud permite la análisis de las solicitudes de página más lentas procesadas. Solo se registrarán solicitudes de contenido en esta página. Más específicamente, se capturarán las siguientes solicitudes:
/content
/etc/design
".html"
La página muestra:
De forma predeterminada, se capturan las 20 solicitudes de página más lentas, pero el límite se puede modificar en Configuration Manager.
La página Rendimiento de Consulta permite la análisis de las consultas más lentas que realiza el sistema. Esta información la proporciona el repositorio en un grano JMX. En Jackrabbit, el com.adobe.granite.QueryStat
grano JMX proporciona esta información, mientras que en el repositorio Oak se ofrece mediante org.apache.jackrabbit.oak.QueryStats.
La página muestra:
Para cualquier consulta dada, Oak intenta averiguar la mejor manera de ejecutar según los índices Oak definidos en el repositorio bajo el nodo oak:index. Según la consulta, Oak puede elegir diferentes índices. Comprender cómo Oak está ejecutando una consulta es el primer paso para optimizar la consulta.
La Consulta Explicar es una herramienta que explica cómo Oak está ejecutando una consulta. Se puede acceder a ella si ingresa a Herramientas - Operaciones - Diagnóstico desde la pantalla de bienvenida de AEM, luego hace clic en Rendimiento de Consulta y pasa a la ficha Explicar Consulta.
Características
Una vez que esté en la interfaz de usuario de la Consulta Explicar, todo lo que debe hacer para utilizarla es entrar en la consulta y pulsar el botón Explicar:
La primera entrada de la sección Explicación de Consulta es la explicación real. La explicación mostrará el tipo de índice que se utilizó para ejecutar la consulta.
La segunda entrada es el plan de ejecución.
Al pulsar el cuadro Incluir tiempo de ejecución antes de ejecutar la consulta también se mostrará la cantidad de tiempo en que se ejecutó la consulta, lo que permite obtener más información que se puede utilizar para optimizar los índices de la aplicación o la implementación.
El propósito del Administrador de índices es facilitar la administración de índices, como el mantenimiento de índices o la visualización de su estado.
Se puede acceder a ella si ingresa a Herramientas - Operaciones - Diagnóstico desde la pantalla de bienvenida y luego hace clic en el botón Administrador de índices.
También se puede acceder directamente a ella en esta dirección URL: https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
La IU se puede utilizar para filtrar índices de la tabla escribiendo los criterios de filtro en el cuadro de búsqueda situado en la esquina superior izquierda de la pantalla.
Esto activará la descarga de un zip que contiene información útil sobre el estado y la configuración del sistema. El archivo contiene configuraciones de instancias, una lista de paquetes, OSGI, métricas de Sling y estadísticas, lo que puede resultar en un archivo grande. Puede reducir el impacto de los archivos de estado de gran tamaño mediante la ventana ZIP de estado de descarga. Se puede acceder a la ventana desde:AEM > Herramientas > Operaciones > Diagnóstico > Descargar ZIP de estado.
Desde esta ventana puede seleccionar qué exportar (archivos de registro y/o archivos de subproceso) y el número de días de registros incluidos en la descarga en relación con la fecha actual.
Esto activará la descarga de un zip que contiene información sobre los subprocesos presentes en el sistema. Se proporciona información sobre cada subproceso, como su estado, el cargador de clase y el seguimiento de pila.
También puede descargar una instantánea del montón para analizarla más adelante. Tenga en cuenta que esto activará la descarga de un archivo grande, en el orden de cientos de megabytes.
La página Tareas de mantenimiento automatizadas es un lugar donde puede realizar la vista y el seguimiento de tareas de mantenimiento recomendadas programadas para su ejecución periódica. Las tareas están integradas con el sistema de comprobación de estado. Las tareas también se pueden ejecutar manualmente desde la interfaz.
Para llegar a la página Mantenimiento en el Panel de operaciones, debe ir a Herramientas - Operaciones - Panel - Mantenimiento desde la pantalla de bienvenida de AEM o seguir directamente este vínculo:
https://serveraddress:port/libs/granite/operations/content/maintenance.html
Las siguientes tareas están disponibles en el Panel de operaciones:
El tiempo predeterminado para la ventana de mantenimiento diario es de 2 a 5 AM. Las tareas configuradas para ejecutarse en la ventana de mantenimiento semanal se ejecutarán entre 1 y 2 AM los sábados.
También puede configurar los horarios pulsando el icono de engranaje en cualquiera de las dos tarjetas de mantenimiento:
Desde AEM 6.1, las ventanas de mantenimiento existentes también se pueden configurar para ejecutarse mensualmente.
Para obtener más información sobre cómo realizar Revision Clean Up, consulte este artículo dedicado.
Mediante la tarea de limpieza de binarios de Lucene, puede purgar los binarios de lucene y reducir el requisito de tamaño del almacén de datos en ejecución. Esto se debe a que la reproducción binaria de lucene se recobrará diariamente en lugar de la dependencia anterior de una ejecución correcta de recopilación de elementos no utilizados del almacén de datos.
Aunque la tarea de mantenimiento se desarrolló para reducir la basura de revisión relacionada con Lucene, hay mejoras generales de eficiencia al ejecutar la tarea:
Puede acceder a la tarea de limpieza de binarios de Lucene desde: AEM > Herramientas > Operaciones > Mantenimiento > Ventana de mantenimiento diario > Limpieza de binarios de Lucene.
Para obtener más información sobre la recopilación de elementos no utilizados del almacén de datos, consulte la página de documentación dedicada.
Los flujos de trabajo también se pueden purgar del Panel de mantenimiento. Para ejecutar la tarea Depuración del flujo de trabajo, debe:
Para obtener información más detallada sobre el mantenimiento del flujo de trabajo, consulte esta página.
Para el mantenimiento del registro de auditoría, consulte la página de documentación independiente.
Puede programar la tarea de mantenimiento Depuración de versiones para que elimine automáticamente las versiones anteriores. Como resultado, esto minimiza la necesidad de utilizar manualmente las herramientas de depuración de versiones. Puede programar y configurar la tarea de depuración de versiones accediendo a Herramientas > Operaciones > Mantenimiento > Ventana de mantenimiento semanal y siguiendo estos pasos:
Haga clic en el botón Añadir.
Elija Depuración de versión en el menú desplegable.
Para configurar la tarea Purgar versión, haga clic en el icono engranajes en la tarjeta de mantenimiento Versión Purgar recientemente creada.
Con AEM 6.4, puede detener la tarea de mantenimiento de la depuración de versiones de la siguiente manera:
Detener la tarea de mantenimiento significa suspender su ejecución sin perder la pista del trabajo que ya está en curso.
Para optimizar el tamaño del repositorio, debe ejecutar la tarea de depuración de versiones con frecuencia. La tarea debe programarse fuera del horario laboral cuando hay una cantidad limitada de tráfico.
Las tareas de mantenimiento personalizadas se pueden implementar como servicios OSGi. Dado que la infraestructura de tarea de mantenimiento se basa en el manejo de trabajos de Apache Sling, una tarea de mantenimiento debe implementar la interfaz java [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html)
. Además, debe declarar varias propiedades de registro de servicio para que se detecten como una tarea de mantenimiento, como se indica a continuación:
Nombre de propiedad del servicio |
Descripción | Ejemplo |
Tipo |
granite.maintenance.isStoppable | Atributo booleano que define si el usuario puede detener la tarea. Si una tarea declara que puede suspenderse, debe comprobar durante su ejecución si se ha detenido y, a continuación, actuar en consecuencia. El valor predeterminado es false. | verdadero | Opcional |
granite.maintenance.mandatory | Atributo booleano que define si una tarea es obligatoria y debe ejecutarse periódicamente. Si una tarea es obligatoria pero actualmente no está en ninguna ventana de programación activa, una comprobación de estado informará de esto como un error. El valor predeterminado es false. | verdadero | Opcional |
granite.maintenance.name | Un nombre único para la tarea: se utiliza para hacer referencia a la tarea. Normalmente es un nombre simple. | MyMaintenanceTask | Requerido |
granite.maintenance.title | Se muestra un título para esta tarea | Mi Tarea de mantenimiento especial | Requerido |
job.topics | Este es un tema único de la tarea de mantenimiento. El manejo de trabajos de Apache Sling inicio un trabajo con exactamente este tema para ejecutar la tarea de mantenimiento y, a medida que la tarea se registra para este tema, se ejecuta. El tema debe estar en inicio con com/adobe/granite/mantenimiento/job/ |
com/adobe/granite/Maintenance/job/MyMaintenanceTask | Requerido |
Aparte de las propiedades de servicio anteriores, el método process()
de la interfaz JobConsumer
debe implementarse agregando el código que debe ejecutarse para la tarea de mantenimiento. El JobExecutionContext
proporcionado se puede utilizar para generar información de estado, comprobar si el usuario ha detenido el trabajo y crear un resultado (correcto o fallido).
En situaciones en las que una tarea de mantenimiento no se debe ejecutar en todas las instalaciones (por ejemplo, solo se debe ejecutar en la instancia de publicación), puede hacer que el servicio requiera una configuración para estar activo agregando @Component(policy=ConfigurationPolicy.REQUIRE)
. Luego puede marcar la configuración de acuerdo como dependiente del modo de ejecución en el repositorio. Para obtener más información, consulte Configuración de OSGi.
A continuación se muestra un ejemplo de una tarea de mantenimiento personalizada que elimina archivos de un directorio temporal configurable que se han modificado en las últimas 24 horas:
src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
|
experience emanager-java-maintenancetask-sample- src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
Una vez implementado el servicio, se expone a la interfaz de usuario de Panel de operaciones. Puede agregarlo a una de las programaciones de mantenimiento disponibles:
Esto agregará un recurso correspondiente en /apps/granite/operations/config/mantenimiento/schedule
/taskname
. Si la tarea depende del modo de ejecución, la propiedad granite.operations.conditions.runmode debe configurarse en ese nodo con los valores de los modos de ejecución que deben estar activos para esta tarea de mantenimiento.
El Panel Información general del sistema muestra una visión general de alto nivel de la configuración, el hardware y el estado de la instancia de AEM. Esto significa que el estado de salud del sistema es transparente y toda la información se agrega en un solo panel.
También puede ver este vídeo para obtener una introducción al Panel Información general del sistema.
Para acceder al Panel Información general del sistema, vaya a Herramientas > Operaciones > Información general del sistema.
En la tabla siguiente se describen todas las informaciones que se muestran en el Panel Información general del sistema. Tenga en cuenta que cuando no hay información relevante que mostrar (por ejemplo, cuando la copia de seguridad no está en curso, no hay comprobaciones de estado que sean críticas), la sección correspondiente mostrará el mensaje "Sin entradas".
También puede descargar un archivo JSON
que resume la información del panel haciendo clic en el botón Descargar en la esquina superior derecha del panel. El punto final JSON
es /libs/granite/operations/content/systemoverview/export.json
y se puede utilizar en una secuencia de comandos curl
para monitoreo externo.
Sección | Qué información se muestra | Cuándo es crítico | Vínculos a |
Comprobación del estado |
|
Indicado visualmente:
|
|
Tareas de mantenimiento |
|
Indicado visualmente:
|
|
Sistema |
|
N/D | N/D |
Instancia |
|
N/D | N/D |
Repositorio |
|
N/D | N/D |
Agentes de distribución |
|
Indicado visualmente:
|
Página de distribución |
Agentes de replicación |
|
Indicado visualmente:
|
Página de replicación |
Flujos de trabajo |
Para cada uno de los estados presentados arriba se realiza una consulta, con un límite de 400 milisegundos. A los 400 milisegundos, se muestra el número de entradas obtenidas hasta ese punto. |
No interpretado:
|
Página Errores de flujo de trabajo |
Trabajos sling | Recuentos de trabajos de Sling: número de trabajos en un estado determinado (si los hay):
|
No interpretado:
|
N/D |
Número aproximado de nodos | Número estimado de:
El número total de nodos se obtiene de nodeCounterMBean, mientras que el resto de las estadísticas se obtiene de IndexInfoService. |
N/D | N/D |
Copia de seguridad | Muestra "Copia de seguridad en línea en curso" si este es el caso. | N/D | N/D |
Indexación | Muestra:
Si hay un subproceso de indexación o consulta en el volcado de subprocesos. |
N/D | N/D |