Tablero de operaciones operations-dashboard
Introducción introduction
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 asistencia. El panel de operaciones se puede ampliar con tareas personalizadas de mantenimiento y comprobaciones de estado. Además, se puede acceder a los datos del Tablero de operaciones desde herramientas de monitorización externas a través de JMX.
Tablero de operaciones:
- Es un estado del sistema de un solo clic para ayudar a los departamentos de operaciones a obtener eficiencia
- Proporciona información general del estado del sistema en un solo lugar centralizado
- Reduce el tiempo para encontrar, analizar y solucionar problemas
- Proporciona automatización de mantenimiento independiente que ayuda a reducir considerablemente los costos de las operaciones de los proyectos
Se puede acceder a ella yendo a Herramientas - Operaciones en la pantalla de bienvenida de AEM.
Informes de estado health-reports
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 hacer mediante solicitudes OSGI, JMX, HTTP (a través de JSON) o a través de la interfaz de usuario táctil. Ofrece medidas y umbral de ciertos contadores configurables y, en algunos casos, ofrece información sobre cómo resolver el problema.
Tiene varias funciones que se describen a continuación.
Comprobación del estado health-checks
La variable Informes de estado son un sistema de tarjetas que indica buena o mala salud en una zona específica del producto. Estas tarjetas son visualizaciones de Sling Health Checks, que acumulan datos de JMX y otras fuentes y muestran información procesada de nuevo como MBeans. Estos MBeans también se pueden inspeccionar en la variable Consola web JMX, en la sección 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 en la pantalla de bienvenida de AEM 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, WARN y CRÍTICO. Los estados son el resultado de reglas y umbrales, que pueden configurarse pasando el ratón por encima de la tarjeta y luego haciendo clic en el icono de engranaje en la barra de acciones:
Tipos de comprobación de estado health-check-types
Existen dos tipos de controles sanitarios en el AEM 6:
- Comprobaciones de estado individuales
- Comprobaciones de estado compuestas
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 pueden configurarse con reglas o umbrales y pueden proporcionar una o más sugerencias y vínculos para resolver los problemas de salud identificados. Veamos la comprobación "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.
A Comprobación de estado compuesto es una comprobación que agrega información de varias comprobaciones individuales.
Los controles sanitarios compuestos se configuran con ayuda de filtro de etiquetas. En esencia, todas las comprobaciones individuales que tengan la misma etiqueta de filtro se agrupan como una comprobación de estado compuesta. Una comprobación de estado compuesta tendrá un estado correcto solo si todas las comprobaciones individuales agregadas tienen estados OK también.
Cómo crear comprobaciones de estado how-to-create-health-checks
En el Tablero de operaciones puede visualizar el resultado de las comprobaciones de estado individuales y compuestas.
Creación de una comprobación de estado individual creating-an-individual-health-check
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 de comprobación de estado de Sling. Añadirá 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 JMX MBean 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 de componentes del servicio OSGI:
code language-java @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 } }note note NOTE La variable MBEAN_NAMEdefine el nombre del mbean que se generará 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 panel de operaciones. Para este paso, es necesario conocer el nombre de Mbean JMX de la Health Check (la variable
MBEAN_NAME). Para crear una configuración para la comprobación de estado, abra CRXDE y añada un nuevo nodo (de tipo nt:unstructured) en la siguiente ruta:/apps/settings/granite/operations/hcLas siguientes propiedades deben establecerse en el nuevo nodo:
-
Nombre:
sling:resourceType- Tipo:
String - Valor:
granite/operations/components/mbean
- Tipo:
-
Nombre:
resource- Tipo:
String - Valor:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
- Tipo:
note note NOTE La ruta de acceso del recurso anterior se crea de la siguiente manera: si el nombre de la media de la comprobación de estado es "test", añada "test" al final de la ruta /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheckAsí que el camino final será: /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/testnote note NOTE Asegúrese de que la variable /apps/settings/granite/operations/hcpath tiene las siguientes propiedades definidas en true:sling:configCollectionInheritsling:configPropertyInheritEsto indicará al administrador de configuración que combine las nuevas configuraciones con las existentes de /libs. -
Creación de una comprobación de estado compuesta creating-a-composite-health-check
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 verificaciones relacionadas con la seguridad. El primer paso para crear una comprobación compuesta es añadir una nueva configuración OSGI. Para que se muestre en el Tablero de operaciones, es necesario 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. Para ello, acceda 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 presionando 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 Mbean con la nueva configuración.
El propósito de cada propiedad de configuración es el siguiente:
- Nombre (hc.name): Nombre de la comprobación de estado compuesto. Se recomienda un nombre significativo.
- Etiquetas (hc.tags): Las etiquetas de esta comprobación de estado. Si esta comprobación de estado compuesta está pensada para formar parte de otra comprobación de estado compuesta (por ejemplo, en una jerarquía de controles de estado), agregue las etiquetas a las que está relacionada esta combinación.
- Nombre de MBean (hc.mbean.name): El nombre del Mbean que se le dará al JMX MBean de esta comprobación de estado compuesta.
- Filtrar etiquetas (filter.tags): Es una propiedad específica de las comprobaciones de estado compuestas. Estas son las etiquetas que el compuesto debe acumular. La comprobación de estado compuesta agregará bajo su grupo todas las comprobaciones de estado que tengan cualquier etiqueta que coincida con cualquiera de las etiquetas de filtro de esta composición. Por ejemplo, una comprobación de estado compuesta que tenga las etiquetas de filtro prueba y check agregará todos los controles de estado individuales y compuestos que tengan alguno de los prueba y check etiquetas en su propiedad tags (
hc.tags).
note note NOTE Se crea un nuevo Mbean 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 acaba de crearse debe agregarse en los nodos de configuración del panel de operaciones. El procedimiento es el mismo que para los controles sanitarios 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 OSGI.Si, por ejemplo, creó una configuración y estableció la variable hc.mbean.name valor diskusage, los nodos de configuración tendrán este aspecto:
-
Nombre:
Composite Health Check- Tipo:
nt:unstructured
- Tipo:
Con las siguientes propiedades:
-
Nombre:
sling:resourceType- Tipo:
String - Valor:
granite/operations/components/mbean
- Tipo:
-
Nombre:
resource- Tipo:
String - Valor:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
- Tipo:
note note NOTE Si crea comprobaciones de estado individuales que lógicamente pertenecen a una comprobación compuesta que ya está presente en el panel de control de forma predeterminada, se capturarán y agruparán automáticamente en la comprobación compuesta correspondiente. 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 debe hacer es asignarle la variable "seguridad", y está instalada, aparece automáticamente en la comprobación compuesta de comprobaciones de seguridad en el panel de operaciones. -
Comprobaciones de estado proporcionadas con AEM health-checks-provided-with-aem
Monitorización con Nagios monitoring-with-nagios
El panel de comprobación de estado se puede integrar con Nagios a través de los Mbeans de Granite JMX. El siguiente ejemplo 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 monitorización.
-
A continuación, instale Nagios Remote Plugin Execution (NRPE).
note note NOTE Para obtener más información sobre cómo instalar Nagios y NRPE en su sistema, consulte la Documentación de Nagios. -
Agregue una definición de host para el servidor AEM. Esto se puede hacer a través de la interfaz web de Nagios XI, utilizando el Administrador de configuración:
- Abra un explorador y apunte al servidor Nagios.
- Pulse el botón Configurar en el menú superior.
- En el panel izquierdo, presione la tecla Administrador de configuración principal under Configuración avanzada.
- Pulse el botón Hosts enlace en el Monitorización para obtener más información.
- Añada la definición del host:
A continuación se muestra un ejemplo de archivo de configuración de host, en caso de que esté utilizando Nagios Core:
code language-xml 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 AEM.
-
Instale el check_http_json en ambos servidores.
-
Defina un comando genérico de comprobación JSON en ambos servidores:
code language-xml 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 utilizada en el servidor de AEM:
code language-xml 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:
Herramientas de diagnóstico diagnosis-tools
El panel de operaciones 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 están:
- Un analizador de mensajes de registro
- La capacidad de acceder a volcados de memoria y subprocesos
- Solicitudes y analizadores de rendimiento de consultas
Para acceder a la pantalla Herramientas de diagnóstico, vaya a Herramientas - Operaciones - Diagnóstico en 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
Mensajes de registro log-messages
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 apéndice del registro de 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 IU no se cambiará la información que se registra en los archivos de registro tradicionales. Añadir y eliminar registros en esta interfaz de usuario solo afectará al registrador en la 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, quitar o actualizar configuraciones de registrador. Una configuración de registrador está compuesta por un nivel de registro (WARN / INFO / DEBUG) y nombre del filtro. La variable nombre del 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 del nivel especificado, el nombre del filtro debe ser "root". La configuración del nivel de un registrador déclencheur la captura de todos los mensajes con un nivel igual o superior al especificado.
Por ejemplo:
-
Si planea capturar todas las variables ERROR messages : no se requiere ninguna configuración. Todos los mensajes ERROR se capturan de forma predeterminada.
-
Si planea capturar todas las variables ERROR, WARN y INFORMACIÓN messages : 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 (esto capturará todas las variables ERROR, WARN, INFORMACIÓN y DEBUG ), como se muestra en la imagen siguiente.
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
Rendimiento de la solicitud request-performance
La página Rendimiento de la solicitud permite el 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:
- Solicitudes de acceso a recursos en
/content - Solicitudes de acceso a recursos en
/etc/design - Las solicitudes que tengan la variable
".html"Extensión
La página muestra:
- Hora a la que se realizó la solicitud
- La URL y el método de solicitud
- La duración en milisegundos
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.
Rendimiento de consultas query-performance
La página Rendimiento de la Consulta permite el análisis de las consultas más lentas que realiza el sistema. El repositorio proporciona esta información en un Mbean JMX. En Jackrabbit, el com.adobe.granite.QueryStat JMX Mbean proporciona esta información, mientras que en el repositorio Oak, la ofrece org.apache.jackrabbit.oak.QueryStats.
La página muestra:
- Hora a la que se realizó la consulta
- El idioma de la consulta
- El número de veces que se emitió la consulta
- El estado de la consulta
- La duración en milisegundos
Explicar la consulta explain-query
Para cualquier consulta dada, Oak intenta averiguar la mejor manera de ejecutar en función de los índices Oak definidos en el repositorio bajo el 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 está ejecutando una consulta. Se puede acceder a ella yendo a Herramientas - Operaciones - Diagnóstico en la pantalla de bienvenida de AEM y, a continuación, haga clic en Rendimiento de la consulta y cambie a la función Explicar consulta pestaña .
Características
- Admite los lenguajes de consulta Xpath, JCR-SQL y JCR-SQL2
- Informa del tiempo de ejecución real de la consulta proporcionada
- Detecta consultas lentas y advierte sobre consultas que podrían ser lentas
- Informa del índice Oak utilizado para ejecutar la consulta
- Muestra la explicación real del motor de consulta Oak
- Proporciona una lista de clics para cargar de consultas lentas y populares
Una vez que esté en la interfaz de usuario de Explicar consulta, todo lo que debe hacer para utilizarla es introducir la consulta y presionar el botón Explicar botón:
La primera entrada en la sección Explicación de la 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 hacer clic en el botón Incluir tiempo de ejecución antes de ejecutar la consulta también 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 su aplicación o implementación.
Administrador de índices the-index-manager
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 la pantalla de bienvenida, en Herramientas - Operaciones - Diagnóstico y luego haciendo clic en la Administrador de índices botón.
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.
Descargar zip de estado download-status-zip
Esto déclencheur la descarga de un 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 de Sling y estadísticas, lo que puede resultar en un archivo grande. Puede reducir el impacto de los archivos de estado grandes mediante la ventana Download Status ZIP . 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 o volcados de subprocesos) y el número de días de registros incluidos en la descarga en relación con la fecha actual.
Descargar volcados de procesos download-thread-dump
Esto déclencheur 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 clases y el seguimiento de pila.
Descargar volcado de pila download-heap-dump
También puede descargar una instantánea de la pila para analizarla más adelante. Tenga en cuenta que esto déclencheur la descarga de un archivo grande, en el orden de cientos de megabytes.
Tareas de mantenimiento automatizadas automated-maintenance-tasks
La página Tareas de mantenimiento automatizadas es un lugar en el que puede ver y rastrear 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.
Para llegar a la página Mantenimiento en el panel de operaciones, debe ir a Herramientas - Operaciones - Tablero - Mantenimiento en la pantalla de bienvenida de AEM o siga directamente este vínculo:
https://serveraddress:port/libs/granite/operations/content/maintenance.html
Las siguientes tareas están disponibles en el panel de operaciones:
-
La tarea Limpieza de revisión ubicada en la sección Ventana de mantenimiento diario para abrir el Navegador.
-
La tarea Limpieza de binarios de Lucene se encuentra en la sección Ventana de mantenimiento diario para abrir el Navegador.
-
La tarea Workflow purge ubicada en la sección Período de mantenimiento semanal para abrir el Navegador.
-
La variable Colección de residuos del almacén de datos tarea, ubicada en la Período de mantenimiento semanal para abrir el Navegador.
-
La variable Mantenimiento del registro de auditoría tarea, ubicada en la Período de mantenimiento semanal para abrir el Navegador.
-
La variable Mantenimiento de purga de versión tarea, ubicada en la Período de mantenimiento semanal para abrir el Navegador.
El tiempo predeterminado para el período de mantenimiento diario es de 2 a 5 de la mañana. Las tareas configuradas para ejecutarse en la ventana de mantenimiento semanal se ejecutarán entre la 1 y las 2 de la mañana los sábados.
También puede configurar los tiempos presionando el icono del engranaje en cualquiera de las dos tarjetas de mantenimiento:
Limpieza de revisión revision-clean-up
Para obtener más información sobre la realización de la limpieza de revisión para AEM 6.4, consulte este artículo específico.
Limpieza de archivos binarios de Lucene lucene-binaries-cleanup
Con la tarea 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 pérdida binaria de lucene será reclamada diariamente en lugar de la dependencia anterior de un éxito colección de residuos del almacén de datos ejecute.
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:
- La ejecución semanal de la tarea de colección de residuos del almacén de datos se completará más rápidamente
- También puede mejorar ligeramente el rendimiento general AEM
Puede acceder a la tarea Limpieza de binarios de Lucene desde: AEM > Herramientas > Operaciones > Mantenimiento > Ventana de mantenimiento diario > Limpieza de binarios de Lucene.
Recolección de papelera del almacén de datos data-store-garbage-collection
Para obtener más información sobre la colección de residuos del almacén de datos, consulte la página de documentación.
Depuración del flujo de trabajo workflow-purge
Los flujos de trabajo también se pueden eliminar del panel de mantenimiento. Para ejecutar la tarea Depuración del flujo de trabajo, debe:
- Haga clic en el Período de mantenimiento semanal página.
- En la página siguiente, haga clic en la Play en el Depuración del flujo de trabajo tarjeta.
Mantenimiento del registro de auditoría audit-log-maintenance
Para consultar el Mantenimiento del registro de auditoría, consulte la página de documentación independiente.
Depuración de la versión version-purge
Puede programar la tarea de mantenimiento Purga de versión para eliminar automáticamente las versiones antiguas. Como resultado, esto minimiza la necesidad de utilizar manualmente la variable Herramientas de purga de versión. Puede programar y configurar la tarea de purga de versión accediendo a Herramientas > Operaciones > Mantenimiento > Ventana de mantenimiento semanal y siguiendo estos pasos:
-
Haga clic en el Agregar botón.
-
Choose Purga de versión en el menú desplegable.
-
Para configurar la tarea de purga de versión, haga clic en el engranajes en la tarjeta de mantenimiento Purge de la versión recién creada.
Con AEM 6.4, puede detener la tarea de mantenimiento Purga de la versión de la siguiente manera:
- Automáticamente : si la ventana de mantenimiento programado se cierra antes de que se pueda completar la tarea, esta se detiene automáticamente. Se reanudará cuando se abra la siguiente ventana de mantenimiento.
- Manualmente: para detener manualmente la tarea, en la tarjeta de mantenimiento Purga de la versión, haga clic en el botón Stop icono. En la siguiente ejecución, la tarea se reanudará de forma segura.
Tareas de mantenimiento personalizadas custom-maintenance-tasks
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 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:
Aparte de las propiedades de servicio anteriores, la variable process() método de la variable JobConsumer La interfaz de debe implementarse añadiendo el código que debe ejecutarse para la tarea de mantenimiento. El JobExecutionContext se puede utilizar para generar información de estado, comprobar si el usuario ha detenido el trabajo y crear un resultado (éxito o error).
En situaciones en las que una tarea de mantenimiento no se debe ejecutar en todas las instalaciones (por ejemplo, ejecutar solo en la instancia de publicación), puede hacer que el servicio requiera una configuración para estar activo 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 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
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 panel de operaciones y se puede agregar a uno de los programas de mantenimiento disponibles:
Esto agregará el 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.
Información general del sistema system-overview
La variable Tablero Información general del sistema muestra una descripció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.
Cómo acceder how-to-access
Para acceder al tablero Información general del sistema, vaya a Herramientas > Operaciones > Información general del sistema.
Explicación del tablero Información general del sistema system-overview-dashboard-explained
En la tabla siguiente, se describe toda la información mostrada en el Tablero de información general del sistema. Tenga en cuenta que cuando no hay información relevante que mostrar (por ejemplo, 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 JSON resumen de la información del tablero haciendo clic en el Descargar en la esquina superior derecha del tablero. JSON el extremo es /libs/granite/operations/content/systemoverview/export.json y se puede usar en un curl para monitorización externa.