AEM AEM El tablero de operaciones en la 6 ayuda a los operadores de sistemas a monitorizar el estado del sistema de un vistazo de manera rápida y con un solo vistazo. AEM También proporciona información de diagnóstico generada automáticamente sobre aspectos relevantes de la implementación y le permite configurar y ejecutar la automatización de mantenimiento independiente para reducir significativamente las operaciones del proyecto y los casos de soporte. El tablero de operaciones se puede ampliar con comprobaciones de estado y tareas de mantenimiento personalizadas. Además, se puede acceder a los datos del tablero de operaciones desde herramientas de monitorización externas a través de JMX.
El tablero de operaciones:
Se puede acceder a ella accediendo a Herramientas - Operaciones AEM en la pantalla de bienvenida de la.
Para poder acceder al tablero 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 usuarios, grupos y derechos de acceso.
AEM El sistema de informes de estado proporciona información sobre el estado de una instancia de a través de las comprobaciones de estado de Sling. Esta operación se realiza mediante solicitudes OSGI, JMX, HTTP (mediante JSON) o a través de la interfaz de usuario táctil. Ofrece mediciones y umbrales de ciertos contadores configurables y, a veces, ofrece información sobre cómo resolver el problema.
Tiene varias características que se describen a continuación.
El Informes de estado son un sistema de tarjetas que indican una buena o mala salud sobre un área específica del producto. Estas tarjetas son visualizaciones de las comprobaciones de estado de Sling, que agregan datos de JMX y otras fuentes y exponen de nuevo la información procesada como MBeans. Estos MBean también se pueden inspeccionar en el Consola web JMX, en org.apache.sling.healthCheck dominio.
Se puede acceder a la interfaz de informes de estado a través de la Herramientas - Operaciones - Informes de estado AEM en la pantalla de bienvenida de la o directamente a través de la siguiente URL:
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
El sistema de tarjetas expone tres estados posibles: OK, ADVERTIR y CRÍTICO. 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 de la barra de acciones:
AEM Existen dos tipos de controles de estado en el 6:
Un Comprobación de estado individual es una única comprobación de estado que corresponde a una tarjeta de estado. Las comprobaciones de estado individuales se pueden configurar con reglas o umbrales y pueden proporcionar una o más sugerencias y vínculos para resolver los problemas de estado identificados. Veamos la comprobación "Registrar errores" como ejemplo: si hay entradas de ERROR en los registros de instancias, búsquelas en la página de detalles de la comprobación de estado. En la parte superior de la página, puede ver un vínculo al analizador "Mensaje de registro" en la sección Herramientas de diagnóstico, que le permite analizar estos errores con más detalle y reconfigurar los registradores.
A Comprobación de 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 filtrar etiquetas. En esencia, todas las comprobaciones individuales que tienen la misma etiqueta de filtro se agrupan como una comprobación de estado compuesta. Una comprobación de estado compuesta tiene el estado OK sólo si todas las comprobaciones únicas que agrega tienen también el estado OK.
En el tablero 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, cree un componente OSGI que implemente la interfaz Sling HealthCheck. Añada este componente dentro de un paquete. Las propiedades del componente identifican completamente la comprobación de estado. Una vez instalado el componente, se crea automáticamente un MBean 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 Comprobación de estado de Sling, escrito con anotaciones del componente 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
}
}
El MBEAN_NAME
define el nombre del mbean que se genera para esta comprobación de estado.
Después de crear una comprobación de estado, se debe crear un nuevo nodo de configuración para que sea accesible en la interfaz del tablero de operaciones. Para este paso, es necesario conocer el nombre del MBean JMX de la comprobación de estado (la variable MBEAN_NAME
property). Para crear una configuración para la comprobación de estado, abra CRXDE y agregue un nodo (de tipo nt:unstructured) 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 del recurso anterior se crea de la siguiente manera: si el nombre de mbean de la comprobación de estado es "test", agregue "test" al final de la ruta /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
Por lo tanto, el camino final es el siguiente:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
Asegúrese de que la variable /apps/settings/granite/operations/hc
La ruta tiene las siguientes propiedades definidas como true:
sling:configCollectionInherit
sling:configPropertyInherit
Este proceso indica al administrador de configuración que combine las nuevas configuraciones con las existentes de /libs
.
La función de una comprobación de estado compuesta es agregar varias comprobaciones de estado individuales que compartan un conjunto de características comunes. Por ejemplo, la comprobación de estado compuesta de seguridad agrupa todas las comprobaciones de estado individuales que realizan comprobaciones relacionadas con la seguridad. El primer paso para crear una comprobación compuesta es añadir una configuración OSGI. Para que se muestre en el tablero de operaciones, se debe agregar un nuevo nodo de configuración de la misma manera que una simple comprobación.
Vaya al Administrador de configuración web en la consola OSGI. Acceso https://serveraddress:port/system/console/configMgr
Busque la entrada llamada Comprobación de estado compuesto de Apache Sling. Cuando lo encuentre, verá que ya hay dos configuraciones disponibles: una para las comprobaciones del sistema y otra para las comprobaciones de seguridad.
Cree una configuración pulsando el botón "+" en el lado derecho de la configuración. Aparece una nueva ventana, como se muestra a continuación:
Cree una configuración y guárdela. Se crea un Mbean con la nueva configuración.
El propósito de cada propiedad de configuración es el siguiente:
hc.tags
).Se crea un nuevo MBean JMX para cada nueva configuración de la comprobación de estado compuesta de Apache Sling.**
Por último, la entrada de la comprobación de estado compuesta que se ha creado debe agregarse en los nodos de configuración del tablero de operaciones. El procedimiento es el mismo que con las comprobaciones de estado individuales: un nodo de tipo nt:unstructured debe crearse en /apps/settings/granite/operations/hc
. La propiedad resource del nodo se define mediante el valor de hc.media.name en la configuración de OSGI.
Por ejemplo, si ha creado una configuración de y ha establecido hc.mbean.name valor hasta diskusage Sin embargo, los nodos de configuración tienen el siguiente 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 capturan automáticamente y se agrupan en la comprobación compuesta correspondiente. Como tal, no es necesario crear un nodo de configuración para estas comprobaciones.
Por ejemplo, si crea una comprobación de estado de seguridad individual, asígnele el valor "seguridad", y está instalada. Aparece automáticamente bajo la comprobación compuesta Comprobaciones de seguridad en el tablero de operaciones.
Nombre de zHealthcheck | Descripción |
Rendimiento de consultas | Esta comprobación de estado se ha simplificado AEM en 6 4, y ahora comprueba el recién refactorizado El MBean para esta comprobación de estado es org.apache.sling.healthCheck:name=queriesStatus,type=HealthCheck. |
Longitud de la cola de observación | Longitud de la cola de observación se repite en todos los oyentes de eventos y observadores de fondo y compara su
AEM La longitud máxima de cada cola proviene de configuraciones independientes (Oak y) y no se puede configurar a partir de esta comprobación de estado. El MBean para esta comprobación de estado es org.apache.sling.healthCheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck. |
Límites de recorrido de la consulta | Límites transversales de consulta comprueba los
El Mbean 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 document nodestore. Devuelve el siguiente estado:
El Mbean para esta comprobación de estado es org.apache.sling.healthCheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck. |
Índices asíncronos | Comprobación de los índices asíncronos:
Los umbrales de estado Crítico y Avisar son configurables. El Mbean para esta comprobación de estado es org.apache.sling.healthCheck:name=asyncIndexHealthCheck,type=HealthCheck. Nota: AEM AEM Esta comprobación de estado está disponible con la versión 6.4 y se ha trasladado a la versión 6.3.0.1 de la versión 6.3 de la versión. |
Índices grandes de Lucene | Esta comprobación utiliza los datos expuestos por el
Los umbrales se pueden configurar y el MBean para la comprobación de estado es org.apache.sling.healthCheck:name=largeIndexHealthCheck,type=HealthCheck. Nota: AEM AEM Esta comprobación está disponible con la versión 6.4 y se ha trasladado a la versión 6.3.2.0 de la versión 6.3 de la versión, en la que se ha realizado un cambio de versión. |
Mantenimiento del sistema | Mantenimiento del sistema es una comprobación compuesta que devuelve el estado OK si todas las tareas de mantenimiento se están ejecutando según lo configurado. Tenga en cuenta que:
El MBean para esta comprobación de estado es org.apache.sling.healthCheck:name=systemcheck,type=HealthCheck. |
Cola de replicación | Esta comprobación recorre en iteración los agentes de replicación y observa sus colas. Para el elemento en la parte superior de la cola, la comprobación determina cuántas veces el agente ha reintentado la replicación. Si el agente reintentó la replicación más que el valor del El MBean para esta comprobación de estado es org.apache.sling.healthCheck:name=replicationQueue,type=HealthCheck. |
Trabajos de Sling |
Sling Jobs comprueba el número de trabajos en cola en JobManager, 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 para esta comprobación de estado es org.apache.sling.healthCheck:name=slingJobs,type=HealthCheck. |
Rendimiento de solicitudes | Esta comprobación determina lo siguiente
El MBean para 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 para esta comprobación de estado es org.apache.sling.healthCheck:name=logErrorHealthCheck,type=HealthCheck. |
Espacio en disco | La comprobación Espacio en disco busca en
Ambos umbrales se pueden configurar. La marca de verificación solo funciona en instancias con un almacén de segmentos. El MBean para 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 en ejecución durante más de 60 segundos. El umbral de duración aceptable es configurable. El MBean para 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 solucionan diferentes problemas de la lista de comprobación de seguridad disponible en Página de documentación de lista de comprobación de seguridad. La comprobación resulta útil como prueba de humo de seguridad cuando se inicia la instancia. El MBean para esta comprobación de estado es org.apache.sling.healthCheck:name=securitycheck,type=HealthCheck |
Paquetes activos | Paquetes activos comprueba el estado de todos los paquetes y:
El parámetro de lista de omisión se puede configurar. El MBean para esta comprobación de estado es org.apache.sling.healthCheck:name=inactiveBundles,type=HealthCheck. |
Comprobación de caché de código | Una comprobación de estado que comprueba varias condiciones de JVM que pueden almacenar en déclencheur un error de CodeCache presente en Java™ 7:
El El MBean para 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 recursos en la ruta
El MBean para esta comprobación de estado es org.apache.sling.healthCheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck. |
AEM De forma predeterminada, para una instancia de predeterminada, las comprobaciones de estado se ejecutan cada 60 segundos.
Puede configurar las variables Periodo con el Configuración de OSGi Configuración de comprobación de estado de consulta (com.adobe.granite.queries.impl.hc.QueryHealthCheckMetrics).
El panel de comprobación de estado se puede integrar con Nagios a través de los Mbeans JMX de Granite. AEM El siguiente ejemplo ilustra cómo agregar una comprobación que muestra la memoria utilizada en el servidor que ejecuta el servicio de memoria de la aplicación de la plataforma de datos de la plataforma de datos de la plataforma de datos de la plataforma de.
Configure e instale Nagios en el servidor de monitorización.
A continuación, instale Nagios Remote Plugin Executor (NRPE).
Para obtener más información sobre cómo instalar Nagios y NRPE en su sistema, consulte la Documentación de Nagios.
AEM Añada una definición de host para el servidor de. Puede realizar esta tarea a través de la interfaz web de Nagios XI, utilizando el Administrador de configuración:
A continuación se muestra un ejemplo de un 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
}
AEM Instale Nagios y NRPE en el servidor de la.
Instale el 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$'
}
AEM Añada un servicio para la memoria utilizada en el servidor de la:
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 el panel de Nagios para el servicio recién creado:
El tablero de operaciones también proporciona acceso a las herramientas de diagnóstico, que pueden ayudar a encontrar y solucionar las causas básicas de las advertencias procedentes del tablero de comprobación de estado, así como a proporcionar información de depuración importante para los operadores del sistema.
Entre sus características más importantes se encuentran:
Puede acceder a la pantalla Herramientas de diagnóstico accediendo a Herramientas - Operaciones - Diagnóstico AEM en la pantalla de bienvenida de la. 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 mensajes de registro muestra todos los mensajes de ERROR de forma predeterminada. Si desea que se muestren más mensajes de registro, configure 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 cambia la información que se registra en los archivos de registro tradicionales. Añadir y eliminar registradores en esta interfaz de usuario solo afecta al registrador de memoria. Además, el cambio de las configuraciones del registrador se refleja en el futuro del en el registrador de memoria. Las entradas que ya están registradas y ya no son relevantes no se eliminan, pero entradas similares no se registran en el futuro.
Puede configurar lo que se registra proporcionando configuraciones del registrador desde el botón del engranaje superior izquierdo de la interfaz de usuario. Aquí puede agregar, quitar o actualizar las configuraciones del registrador. Una configuración de registrador está compuesta por un nivel de registro (WARN / INFO / DEBUG) y una nombre de filtro. El nombre de filtro tiene la función de filtrar el origen de los mensajes de registro que se registran. Alternativamente, si un registrador debe capturar todos los mensajes de registro para el nivel especificado, el nombre del filtro debe ser "raíz". Déclencheur Al establecer el nivel de un registrador, se capturan todos los mensajes con un nivel igual o superior al especificado.
Por ejemplo:
Si planea capturar todas las ERROR mensajes: no se requiere configuración. Todos los mensajes ERROR se capturan de forma predeterminada.
Si planea capturar todas las ERROR, ADVERTIR y INFORMACIÓN mensajes: el nombre del registrador debe establecerse en: "raíz", 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 configurarse como: "com.adobe.granite". Y el nivel del registrador establecido en: DEPURAR (al hacerlo, se capturan todas las ERROR, ADVERTIR, INFORMACIÓN, y DEPURAR mensajes), como se muestra en la siguiente imagen.
No puede establecer un nombre de registrador para capturar solo los mensajes de ERROR a través de un filtro especificado. De forma predeterminada, se capturan todos los mensajes de ERROR.
La interfaz de usuario de mensajes de registro no refleja el registro de errores real. A menos que esté configurando otros tipos de mensajes de registro en la interfaz de usuario de, solo verá mensajes de 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 a la inversa. Por lo tanto, aunque el registro de errores puede capturar mensajes INFO, es posible que no los vea en la interfaz de usuario de mensajes de registro. Además, a través de la IU es posible capturar mensajes de DEPURACIÓN de ciertos paquetes sin que afecte al registro de errores. Para obtener más información sobre cómo configurar los archivos de registro, consulte Registro.
AEM Con 6,4 Por lo tanto, las tareas de mantenimiento se registran de forma predeterminada en un formato enriquecido más informativo a nivel INFO. Este flujo de trabajo ofrece una mejor visibilidad del estado de las tareas de mantenimiento.
Si utiliza herramientas de terceros (como Splunk) para monitorizar y reaccionar ante la actividad de la tarea de mantenimiento, puede utilizar las siguientes instrucciones 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 analizar las solicitudes de página más lentas procesadas. En esta página solo se registran solicitudes de contenido. Más específicamente, se capturan las siguientes solicitudes:
/content
/etc/design
".html"
extensiónSe muestra la página:
De forma predeterminada, se capturan las 20 solicitudes de página más lentas, pero el límite se puede modificar en el Administrador de configuración.
La página Rendimiento de la Consulta permite analizar las consultas más lentas realizadas por el sistema. El repositorio proporciona esta información en un Mbean JMX. En Jackrabbit, la com.adobe.granite.QueryStat
JMX Mbean proporciona esta información, mientras que en el repositorio Oak, la ofrece org.apache.jackrabbit.oak.QueryStats.
Se muestra la página:
Para cualquier consulta determinada, Oak intenta averiguar la mejor manera de ejecutar en función de los índices de Oak definidos en el repositorio en oak:index nodo. Según la consulta, Oak puede elegir diferentes índices. Comprender cómo Oak está ejecutando una consulta es el primer paso para optimizarla.
Explicar consulta es una herramienta que explica cómo Oak ejecuta una consulta. Se puede acceder a ella accediendo a Herramientas - Operaciones - Diagnóstico AEM en la pantalla de bienvenida de la. A continuación, haga clic en Rendimiento de consultas y cambie a la Explicar consulta pestaña.
Características
Una vez que esté en la interfaz de usuario de Explicar consulta, introduzca la consulta y pulse el botón Explicar botón:
La primera entrada de la sección Explicación de la consulta es la explicación real. La explicación muestra el tipo de índice que se utilizó para ejecutar la consulta.
La segunda entrada es el plan de ejecución.
Marcando el Incluir tiempo de ejecución antes de ejecutar la consulta también muestra la cantidad de tiempo que se ejecutó la consulta. El Incluir recuento de nodos informa del recuento de nodos. El informe permite obtener más información que se puede utilizar para optimizar los índices de la aplicación o 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 desde pantalla de bienvenida, en Herramientas - Operaciones - de diagnóstico y, a continuación, haciendo clic en Administrador de índices botón.
También se puede acceder a ella directamente desde esta dirección URL: https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
La interfaz de usuario se puede utilizar para filtrar índices en la tabla escribiendo los criterios de filtro en el cuadro de búsqueda en la esquina superior izquierda de la pantalla.
Esta acción almacena en déclencheur la descarga de un archivo zip que contiene información útil sobre el estado y la configuración del sistema. El archivo contiene configuraciones de instancia, una lista de paquetes, OSGI, métricas y estadísticas de Sling, que pueden dar como resultado un archivo grande. Puede reducir el impacto de los archivos de estado grandes mediante el ZIP de estado de descarga ventana. Se puede acceder a la ventana desde:AEM > Herramientas > Operaciones > Diagnóstico > ZIP de estado de descarga.
Desde esta ventana, puede seleccionar qué desea exportar (archivos de registro o volcados de procesos) y el número de días de registros incluidos en la descarga en relación con la fecha actual.
Esta acción almacena en déclencheur la descarga de un zip que contiene información sobre los hilos presentes en el sistema. Se proporciona información sobre cada subproceso, como su estado, el cargador de clases y el stacktrace.
Puede descargar una instantánea del montón para analizarla más adelante. Esta acción déclencheur la descarga de un archivo grande (de cientos de megabytes).
La página Tareas de mantenimiento automatizadas es un lugar en el que puede ver y realizar un seguimiento de las 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.
AEM Para llegar a la página de mantenimiento en el tablero de operaciones, en la pantalla de bienvenida de la, vaya a Herramientas - Operaciones - Panel de control - Mantenimiento, o siga directamente este enlace:
https://serveraddress:port/libs/granite/operations/content/maintenance.html
Las siguientes tareas están disponibles en el tablero de operaciones:
El horario predeterminado para la ventana de mantenimiento diario es de 2:00 a.m. a 5:00 a.m. Las tareas configuradas para ejecutarse en la ventana de mantenimiento semanal se ejecutan entre la 1 y las 2 de la madrugada los sábados.
También puede configurar los horarios pulsando el icono de engranaje en cualquiera de las dos tarjetas de mantenimiento:
AEM A partir de la versión 6.1 de, las ventanas de mantenimiento existentes también se pueden configurar para que se ejecuten mensualmente.
Para obtener más información sobre la limpieza de revisión, consulte este artículo dedicado.
Mediante la tarea Limpieza de binarios de Lucene, puede depurar los binarios de Lucene y reducir el requisito de tamaño del almacén de datos en ejecución. La pérdida binaria de Lucene se recupera diariamente en lugar de la dependencia anterior de un recolección de basura del almacén de datos correr.
Aunque la tarea de mantenimiento se desarrolló para reducir la basura de revisiones relacionada con Lucene, hay mejoras generales de eficiencia al ejecutar la tarea:
Puede acceder a la tarea 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 recolección de basura del almacén de datos, consulte la página de documentación.
Los flujos de trabajo también se pueden eliminar del Panel de mantenimiento. Para ejecutar la tarea Depuración del flujo de trabajo, haga lo siguiente:
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 planificar la tarea de mantenimiento Depuración de versiones para que se eliminen automáticamente las versiones antiguas. Esta acción minimiza la necesidad de utilizar manualmente el Herramientas de depuración de versiones. Puede programar y configurar la tarea Depuración de versiones accediendo a Herramientas > Operaciones > Mantenimiento > Ventana de mantenimiento semanal y siguiendo estos pasos:
Clic Añadir.
Elegir Depuración de versión en el menú desplegable.
Para configurar la tarea Depuración de versión, haga clic en engranajes en la tarjeta de mantenimiento Depuración de versiones recién creada.
AEM Con 6,4, puede detener la tarea de mantenimiento Depuración de versiones de la siguiente manera:
Detener la tarea de mantenimiento significa suspender su ejecución sin perder el seguimiento del trabajo ya 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 haya una cantidad limitada de tráfico.
Las tareas de mantenimiento personalizadas se pueden implementar como servicios OSGi. Como la infraestructura de tareas de mantenimiento se basa en la gestión de trabajos de Apache Sling, una tarea de mantenimiento debe implementar la interfaz de 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 muestra a continuación:
Nombre de propiedad de servicio |
Descripción | Ejemplo |
Tipo |
granite.maintenance.isStoppable | Atributo booleano que define si el usuario puede detener la tarea. Si una tarea declara que se puede detener, debe comprobar durante su ejecución si se ha detenido y, a continuación, actuar en consecuencia. El valor predeterminado es false. | true | 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 se encuentra en ninguna ventana de programación activa, una comprobación de estado informará de este error. El valor predeterminado es false. | true | Opcional |
granite.maintenance.name | Un nombre único para la tarea: el nombre se utiliza para hacer referencia a la tarea y es solo un nombre simple. | MyMaintenanceTask | Requerido |
granite.maintenance.title | Título mostrado para esta tarea | Mi tarea de mantenimiento especial | Requerido |
job.topics | Tema único de la tarea de mantenimiento. La administración de trabajos de Apache Sling inicia 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 comenzar con com/adobe/granite/maintenance/job/ |
com/adobe/granite/maintenance/job/MyMaintenanceTask | Requerido |
Aparte de las propiedades de servicio anteriores, la variable process()
método del JobConsumer
La interfaz de debe implementarse añadiendo el código que debe ejecutarse para la tarea de mantenimiento. El proporcionado JobExecutionContext
se puede utilizar para generar información de estado, comprobar si el usuario detiene el trabajo y crear un resultado (correcto o fallido).
En situaciones en las que una tarea de mantenimiento no debe ejecutarse en todas las instalaciones (por ejemplo, ejecutarse solo en la instancia de publicación), puede hacer que el servicio requiera que una configuración esté activa añadiendo @Component(policy=ConfigurationPolicy.REQUIRE)
. A continuación, puede marcar la configuración correspondiente como dependiente del modo de ejecución en el repositorio. Para obtener más información, consulte Configurar 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
|
experiencemanager-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 del tablero de operaciones. Puede añadirlo a uno de los programas de mantenimiento disponibles:
Esta acción añade un recurso correspondiente en /apps/granite/operations/config/maintenance/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 Tablero de información general del sistema AEM muestra una descripción general de alto nivel de la configuración, el hardware y el estado de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de la instancia de. El estado del sistema es transparente y toda la información se agrega en un solo tablero.
También puede vea este vídeo para obtener una introducción al Panel de información general del sistema.
Para acceder al Panel de información general del sistema, vaya a Herramientas > Operaciones > Información general del sistema.
En la tabla siguiente se describe toda la información mostrada en el tablero de información general del sistema. Cuando no hay información relevante que mostrar (por ejemplo, la copia de seguridad no está en curso, no hay comprobaciones de estado críticas), la sección correspondiente muestra el mensaje "Sin entradas".
También puede descargar una JSON
archivo que resume la información del tablero haciendo clic en Descargar en la esquina superior derecha del panel. El JSON
el punto final es /libs/granite/operations/content/systemoverview/export.json
y se puede utilizar en un curl
para monitorización externa.
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 Distribución |
Agentes de replicación |
|
Indicado visualmente:
|
Página 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 momento. |
No interpretado:
|
Página Errores de flujo de trabajo |
Trabajos de 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 obtienen de IndexInfoService. |
N/D | N/D |
Copia de seguridad | Muestra "Copia de seguridad en línea en curso" si es así. | N/D | N/D |
Indexación | Muestra:
Si hay un subproceso de indexación o consulta en el volcado de hilos. |
N/D | N/D |