Tareas de mantenimiento en AEM as a Cloud Service maintenance-tasks-in-aem-as-a-cloud-service
Las tareas de mantenimiento son procesos que se ejecutan según una programación para optimizar el repositorio. Con AEM as a Cloud Service, la necesidad de que los clientes configuren las propiedades operativas de las tareas de mantenimiento es mínima. Los clientes pueden enfocar sus recursos en preocupaciones del nivel de la aplicación y dejar que Adobe se encargue de las operaciones de infraestructura.
Configuración de tareas de mantenimiento maintenance-tasks-configuring
En versiones anteriores de AEM, se podían configurar tareas de mantenimiento mediante la tarjeta de mantenimiento (Herramientas > Operaciones > Mantenimiento). La tarjeta de mantenimiento ya no está disponible para AEM as a Cloud Service, por lo que las configuraciones deben enviarse al control de origen e implementarse mediante Cloud Manager. Adobe administra las tareas de mantenimiento que tienen configuraciones que los clientes no pueden configurar (por ejemplo, Recopilación de elementos no utilizados del almacén de datos). Los clientes pueden configurar otras tareas de mantenimiento, como se describe en la tabla siguiente.
En la tabla siguiente se ilustran las tareas de mantenimiento disponibles.
Ubicaciones:
- Diario: /apps/settings/granite/operations/maintenance/granite_daily
- Semanal: /apps/settings/granite/operations/maintenance/granite_weekly
- Mensual: /apps/settings/granite/operations/maintenance/granite_monthly
Muestras de código:
Muestra de código 1 (diario)
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:Folder"
sling:configCollectionInherit="true"
sling:configPropertyInherit="true"
windowSchedule="daily"
windowStartTime="03:00"
windowEndTime="05:00"
/>
Muestra de código 2 (semanal)
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:Folder"
sling:configCollectionInherit="true"
sling:configPropertyInherit="true"
windowEndTime="15:30"
windowSchedule="weekly"
windowScheduleWeekdays="[5,5]"
windowStartTime="14:30"/>
Muestra de código 3 (mensual)
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:Folder"
sling:configCollectionInherit="true"
sling:configPropertyInherit="true"
windowEndTime="15:30"
windowSchedule="monthly"
windowFirstLastStartDay=0
windowScheduleWeekdays="[5,5]"
windowStartTime="14:30"/>
Tareas de mantenimiento de purga de versiones y depuración de registros de auditoría purge-tasks
La depuración de versiones y del registro de auditoría reduce el tamaño del repositorio y, en algunos casos, puede mejorar el rendimiento.
Valores predeterminados defaults
Actualmente, la depuración no está habilitada de forma predeterminada, pero esto cambiará en el futuro. Los entornos que se crearon antes de habilitar la depuración predeterminada tendrán un umbral más conservador para que la depuración no se produzca de forma inesperada. Consulte las secciones Depuración de versiones y Depuración del registro de auditoría a continuación para obtener más detalles sobre la política de depuración predeterminada.
Los valores de depuración predeterminados se pueden sobrescribir declarando un archivo de configuración e implementándolo como se describe a continuación.
Aplicación de una configuración configure-purge
Declare un archivo de configuración e impleméntelo como se describe en los pasos siguientes.
1 Cree un archivo con el nombre mt.yaml o similar.
2 Coloque el archivo en algún lugar bajo una carpeta de nivel superior llamada config o similar, como se describe en Uso de canalizaciones de configuración.
3 - Declarar propiedades en el archivo de configuración, que incluyen:
-
Algunas propiedades encima del nodo de datos. Consulte Uso de canalizaciones de configuración para obtener una descripción. El valor de la propiedad
kinddebe ser MaintenanceTasks y la versión debe establecerse en 1. -
un objeto de datos con
versionPurgeyauditLogPurgeobjetos.
Vea las definiciones y sintaxis de los objetos versionPurge y auditLogPurge a continuación.
La configuración es similar al siguiente ejemplo:
kind: "MaintenanceTasks"
version: "1"
metadata:
envTypes: ["dev"]
data:
versionPurge:
maximumVersions: 15
maximumAgeDays: 20
paths: ["/content"]
minimumVersions: 1
retainLabelledVersions: false
auditLogPurge:
rules:
- replication:
maximumAgeDays: 15
contentPath: "/content"
types: ["Activate", "Deactivate", "Delete", "Test", "Reverse", "Internal Poll"]
- pages:
maximumAgeDays: 15
contentPath: "/content"
types: ["PageCreated", "PageModified", "PageMoved", "PageDeleted", "VersionCreated", "PageRestored", "PageValid", "PageInvalid"]
- dam:
maximumAgeDays: 15
contentPath: "/content"
types: ["ASSET_EXPIRING", "METADATA_UPDATED", "ASSET_EXPIRED", "ASSET_REMOVED", "RESTORED", "ASSET_MOVED", "ASSET_VIEWED", "PROJECT_VIEWED", "PUBLISHED_EXTERNAL", "COLLECTION_VIEWED", "VERSIONED", "ADDED_COMMENT", "RENDITION_UPDATED", "ACCEPTED", "DOWNLOADED", "SUBASSET_UPDATED", "SUBASSET_REMOVED", "ASSET_CREATED", "ASSET_SHARED", "RENDITION_REMOVED", "ASSET_PUBLISHED", "ORIGINAL_UPDATED", "RENDITION_DOWNLOADED", "REJECTED"]
Tenga en cuenta que para que la configuración sea válida:
- todas las propiedades deben estar definidas. No hay valores predeterminados heredados.
- se deben respetar los tipos (enteros, cadenas, booleanos, etc.) de las tablas de propiedades siguientes.
4: cree una canalización de configuración en Cloud Manager, tal como se describe en el artículo canalización de configuración. Las zonas protegidas y los entornos de desarrollo rápido (RDE) no admiten la depuración.
Depuración de la versión version-purge
Valores predeterminados de depuración de versión version-purge-defaults
Actualmente, la depuración no está habilitada de forma predeterminada, pero esto cambiará en el futuro.
Los entornos que se crearon después de habilitar la depuración predeterminada tendrán los siguientes valores predeterminados:
- Se eliminan las versiones con más de 30 días.
- Se conservan las cinco versiones más recientes de los últimos 30 días.
- Independientemente de las reglas anteriores, se conserva la versión más reciente (además del archivo actual).
Los entornos que se crearon antes de habilitar la depuración predeterminada tendrán los valores predeterminados que se enumeran a continuación, pero se recomienda reducir esos valores para optimizar el rendimiento.
- Se eliminan las versiones anteriores a 7 años.
- Se conservan todas las versiones de los últimos 7 años.
- Después de 7 años, se eliminan otras versiones que no sean la más reciente (además del archivo actual).
Propiedades de purga de versiones version-purge-properties
Las propiedades permitidas se enumeran a continuación.
Las columnas que indican default indican los valores predeterminados en el futuro, cuando se apliquen los valores predeterminados; TBD refleja un identificador de entorno que aún no se ha determinado.
Interacciones de propiedades
Los siguientes ejemplos ilustran cómo interactúan las propiedades al combinarse.
Ejemplo:
maximumAgeDays = 30
maximumVersions = 10
minimumVersions = 2
Si hay 11 versiones el día 23, la versión más antigua se purgará la próxima vez que se ejecute la tarea de mantenimiento de purga, ya que la propiedad maximumVersions está establecida en 10.
Si hay 5 versiones en el día 31, solo se purgarán 3, ya que la propiedad minimumVersions está establecida en 2.
Ejemplo:
maximumAgeDays = 30
maximumVersions = 0
minimumVersions = 1
No se purgarán versiones posteriores a los 30 días debido a que la propiedad maximumVersions está establecida en 0.
Se conservará una versión con más de 30 días.
Purga del registro de auditoría audit-purge
Valores predeterminados de purga del registro de auditoría audit-purge-defaults
Actualmente, la depuración no está habilitada de forma predeterminada, pero esto cambiará en el futuro.
Los entornos que se crearon después de habilitar la depuración predeterminada tendrán los siguientes valores predeterminados:
- Se eliminan los registros de replicación, DAM y auditoría de página anteriores a 7 días.
- Se registran todos los eventos posibles.
Los entornos que se crearon antes de habilitar la depuración predeterminada tendrán los valores predeterminados que se enumeran a continuación, pero se recomienda reducir esos valores para optimizar el rendimiento.
- Se eliminan los registros de replicación, DAM y auditoría de página anteriores a 7 años.
- Se registran todos los eventos posibles.
Propiedades de purga del registro de auditoría audit-purge-properties
Las propiedades permitidas se enumeran a continuación.
Las columnas que indican default indican los valores predeterminados en el futuro, cuando se apliquen los valores predeterminados; TBD refleja un identificador de entorno que aún no se ha determinado.