Dans AEM 6, le tableau de bord des opérations permet aux opérateurs système de surveiller d’un simple coup d’œil l’intégrité du système AEM. Il contient également des informations de diagnostic générées automatiquement concernant des aspects pertinents d’AEM et permet de configurer et d’exécuter une automatisation de maintenance autonome afin de réduire de façon significative les coûts de fonctionnement du projet et les dossiers de support. Le tableau de bord des opérations peut être étendu en y intégrant des contrôles de l’intégrité et des tâches de maintenance personnalisés. En outre, les données du tableau de bord des opérations sont accessibles à l’aide des outils de surveillance externes par le biais de JMX.
Le tableau de bord des opérations :
Il est accessible en sélectionnant Outils – Opérations dans l’écran d’accueil d’AEM.
Pour accéder au tableau de bord des opérations, l’utilisateur connecté doit faire partie du groupe « Opérateurs ». Pour plus d’informations, consultez la documentation relative à l’Administration des utilisateurs, des groupes et des droits d’accès.
Le système de rapports d’intégrité fournit des informations sur l’intégrité d’une instance AEM par le biais de contrôles d’intégrité Sling. Cela peut être effectué à l’aide de demandes OSGi, JMX, HTTP (via JSON) ou par le biais de l’interface utilisateur tactile. Il propose des mesures et un seuil pour certains compteurs configurables et, dans certains cas, contient des informations sur la résolution du problème.
Il comporte différentes fonctionnalités, décrites ci-dessous.
Les rapports d’intégrité sont un système de cartes indiquant une intégrité satisfaisante ou non en ce qui concerne une zone spécifique du produit. Ces cartes sont des visualisations des contrôles d’intégrité Sling, qui agrègent les données de JMX et d’autres sources, et présentent de nouveau les informations traitées sous forme de MBeans. Ces MBeans peuvent également être vérifiés dans la console web JMX, sous le domaine org.apache.sling.healthcheck.
Les rapports d’intégrité sont accessibles en sélectionnant le menu Outils – Opérations – Rapports d’intégrité dans l’écran d’accueil d’AEM ou directement par le biais de l’adresse URL suivante :
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
Le système de cartes comporte trois statuts possibles : OK, AVERTISSEMENT et CRITIQUE. Les statuts sont le résultat des règles et des seuils, qui peuvent être configurés en passant le curseur de la souris sur la carte, puis en cliquant sur l’icône d’engrenage de la barre d’actions :
Dans AEM 6, il existe deux types de contrôle de l’intégrité :
Un contrôle de l’intégrité individuel est un contrôle de l’intégrité unique, qui correspond à une carte d’état. Des contrôles de l’intégrité individuels peuvent être configurés avec des règles ou des seuils et peuvent fournir un ou plusieurs conseils et liens pour résoudre des problèmes d’intégrité identifiés. Prenons le contrôle « Erreurs de journal » comme exemple : s’il existe des entrées ERREUR dans les journaux des instances, elles seront répertoriées dans la page Détails du contrôle de l’intégrité. Dans la partie supérieure de la page, un lien vers l’analyseur « Message du journal » dans la section Outils de diagnostic permet d’analyser ces erreurs plus en détail et de reconfigurer les enregistreurs.
Un contrôle de l’intégrité composite est un contrôle qui regroupe des informations de différents contrôles individuels.
Les contrôles de l’intégrité composites sont configurés à l’aide de balises de filtrage. En substance, tous les contrôles individuels possédant la même balise de filtrage sont regroupés sous le contrôle de l’intégrité composite. le statut d’un contrôle de l’intégrité composite est « OK » seulement si le statut de tous les contrôles individuels est également « OK ».
Dans le tableau de bord des opérations, vous pouvez visualiser le résultat des contrôles de l’intégrité individuels et composites.
La création d’un contrôle de l’intégrité individuel comprend deux étapes : mise en œuvre d’un contrôle de l’intégrité Sling et ajout d’une entrée pour le contrôle de l’intégrité dans les nœuds de la configuration du tableau de bord.
Pour créer un contrôle de l’intégrité Sling, vous devez créer un composant OSGi mettant en œuvre l’interface Sling HealthCheck. Vous ajoutez ce composant dans un lot. Les propriétés du composant identifient entièrement le contrôle de l’intégrité. Une fois le composant installé, un MBean JMX est automatiquement créé pour le contrôle de l’intégrité. Pour plus d’informations, voir la documentation sur les contrôles de l’intégrité Sling.
Exemple de composant de contrôle de l’intégrité Sling, écrit avec des annotations de composant de service 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 propriété MBEAN_NAME
définit le nom du MBean généré pour ce contrôle de l’intégrité.
Après avoir créé un contrôle de l’intégrité, un nouveau nœud de configuration doit être créé afin de le mettre à disposition dans l’interface du tableau de bord des opérations. Pour cette étape, il est nécessaire de connaître le nom du MBean JMX du contrôle de l’intégrité (la propriété MBEAN_NAME
). Pour créer une configuration pour le contrôle de l’intégrité, ouvrez CRXDE et ajoutez un nouveau nœud (de type nt:unstructured) sous le chemin d’accès suivant : /apps/settings/granite/operations/hc
.
Les propriétés ci-dessous doivent être définies sur le nouveau nœud :
Nom : sling:resourceType
String
granite/operations/components/mbean
Nom : resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
Le chemin d’accès à la ressource ci-dessus est créé comme suit : si le nom du MBean du contrôle de l’intégrité est « test », ajoutez « test » à la fin du chemin d’accès /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
.
Le chemin d’accès final est donc :
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
Assurez-vous que les propriétés ci-dessous du chemin d’accès /apps/settings/granite/operations/hc
sont définies sur true :
sling:configCollectionInherit
sling:configPropertyInherit
Cela indique au gestionnaire de configuration de fusionner les nouvelles configurations avec les configurations existantes de /libs
.
Un contrôle de l’intégrité composite vise à agréger différents contrôles de l’intégrité partageant un ensemble de fonctionnalités communes. Par exemple, un contrôle de l’intégrité composite de sécurité regroupe tous les contrôles de l’intégrité individuels liés à la sécurité. Pour créer un contrôle composite, la première étape consiste à ajouter une nouvelle configuration OSGi. Pour qu’il s’affiche dans le tableau de bord des opérations, un nouveau nœud de configuration doit être ajouté comme pour un contrôle unique.
Accédez au gestionnaire de configuration web dans la console OSGi. Vous pouvez effectuer cette opération à en accédant à https://serveraddress:port/system/console/configMgr
.
Recherchez l’entrée Apache Sling Composite Health Check. Une fois que vous l’avez trouvée, deux configurations sont déjà disponibles : une pour les contrôles système et une autre pour les contrôles de sécurité.
Créez une configuration en cliquant sur le bouton « + » dans la partie droite de la configuration. Une nouvelle fenêtre s’affiche, comme illustré ci-dessous :
Créez une configuration et enregistrez-la. Un MBean est créé avec la nouvelle configuration.
L’objectif de chaque propriété de configuration est le suivant :
hc.tags
).Un nouveau MBean JMX est créé pour chaque nouvelle configuration du contrôle de l’intégrité composite Apache Sling.**
Enfin, l’entrée du contrôle de l’intégrité composite qui vient d’être créé doit être ajoutée aux nœuds de configuration du tableau de bord des opérations. La procédure est identique à celle des contrôles de l’intégrité individuels : un nœud de type nt:unstructured doit être créé sous /apps/settings/granite/operations/hc
. La propriété de ressource du nœud est définie par la valeur de hc.mean.name dans la configuration OSGi.
Par exemple, si vous avez créé une configuration et défini la valeur hc.mbean.name sur diskusage, les nœuds de configuration se présentent comme suit :
Nom : Composite Health Check
nt:unstructured
Avec les propriétés suivantes :
Nom : sling:resourceType
String
granite/operations/components/mbean
Nom : resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
Si vous créez des contrôles de l’intégrité individuels, qui font partie logiquement d’un contrôle composite déjà présent dans le tableau de bord par défaut, ils sont enregistrés et regroupés automatiquement sous le contrôle composite correspondant. Pour cette raison, il n’est pas nécessaire de créer un nœud de configuration pour ces contrôles.
Par exemple, si vous créez un contrôle de l’intégrité individuel de sécurité, il suffit d’affecter la balise « security », et elle s’installe et s’affiche automatiquement sous le contrôle composite de sécurité dans le tableau de bord des opérations.
Nom du contrôle de l’intégrité | Description |
Performances des requêtes | Ce contrôle de l’intégrité a été simplifié dans AEM 6.4 et contrôle maintenant le MBean Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck. |
Longueur de la file d’attente d’observation | La longueur de la file d’attente d’observation effectue une itération sur tous les programmes d’écoute d’événement et les observateurs en arrière-plan, compare la valeur
La longueur maximale de chaque file d’attente provient de configurations distinctes (Oak et AEM) et n’est pas configurable à partir de ce contrôle de l’intégrité. Le MBean pour ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck. |
Limites de requête transversales | Le contrôle Limites de requête transversales contrôle le MBean
Le MBean pour ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=queryTraversalLimitsBundle,type=HealthCheck. |
Horloges synchronisées | Ce contrôle est pertinent uniquement pour les clusters d’entrepôt de nœuds de documents. Il renvoie l’état suivant :
Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck. |
Index asynchrones | Le contrôle « Index asynchrones » :
Les seuils des états Critique et Avertissement sont configurables. Le MBean pour ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=asyncIndexHealthCheck,type=HealthCheck. Remarque : Ce contrôle de l’intégrité est disponible avec AEM 6.4 et a été rétroporté dans AEM 6.3.0.1. |
Index Lucene volumineux | Ce contrôle utilise les données exposées par le MBean
Les seuils sont configurables et le MBean du contrôle de l’intégrité est org.apache.sling.healthcheck:name=largeIndexHealthCheck,type=HealthCheck. Remarque : Ce contrôle est disponible avec AEM 6.4 et a été rétroporté dans AEM 6.3.2.0. |
Maintenance du système | La maintenance du système est un contrôle composite, qui renvoie l’état « OK » si toutes les tâches de maintenance sont exécutées selon la configuration. Gardez à l’esprit que :
Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=systemchecks,type=HealthCheck. |
File d’attente de réplication | Ce contrôle effectue une itération sur les agents de réplication et examine leurs files d’attente. Pour l’élément en haut de la file d’attente, le contrôle examine le nombre de fois où l’agent a tenté une réplication. Si l’agent a tenté une réplication plus de fois que défini par la valeur du paramètre Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck. |
Tâches Sling |
Le contrôle Tâches Sling vérifie le nombre de tâches dans la file d’attente du gestionnaire de tâches, le compare au seuil
maxNumQueueJobs et :
Seul le nombre maximal du paramètre de tâches en file d’attente est configurable (1 000 par défaut). Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=slingJobs,type=HealthCheck. |
Performances des demandes | Ce contrôle cherche l’indicateur Sling
Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck. |
Erreurs de journal | Ce contrôle renvoie l’état « Avertissement » si le journal comporte des erreurs. Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck. |
Espace disque | Le contrôle Espace disque observe le MBean
Les deux seuils sont configurables. Le contrôle fonctionne uniquement sur les instances comportant un entrepôt de segments. Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=DiskSpaceHealthCheck,type=HealthCheck. |
Vérification de l’intégrité de l’outil de planification | Ce contrôle renvoie un avertissement si l’instance possède des tâches Quartz en cours d’exécution depuis plus de 60 secondes. Le seuil de durée acceptable est configurable. Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheck. |
Contrôles de sécurité | Le contrôle de sécurité est un contrôle composite, qui agrège les résultats de différents contrôles liés à la sécurité. Chacun de ces contrôles d’intégrité prennent en compte différentes préoccupations de la liste de contrôle de sécurité, disponibles dans la page de documentation Liste de contrôle de sécurité. Ils sont utiles comme test de vérification de la sécurité lorsque l’instance est démarrée. Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=securitychecks,type=HealthCheck. |
Lots actifs | Les lots actifs contrôlent l’état de tous les lots et :
Le paramètre de la liste Ignorer est configurable. Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck. |
Contrôle du cache du code | Il s’agit d’un contrôle de l’intégrité, qui vérifie plusieurs conditions JVM pouvant déclencher l’apparition d’un bogue de CodeCache dans Java 7 :
Le seuil Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=codeCacheHealthCheck,type=HealthCheck. |
Erreurs de chemin de recherche des ressources | Vérifie s’il existe des ressources dans le chemin d’accès
Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck. |
Le tableau de bord des contrôles de l’intégrité peut être intégré à Nagios par le biais des MBeans JMX Granite. L’exemple ci-dessous indique comment ajouter un contrôle qui affiche la mémoire utilisée sur le serveur qui exécute AEM.
Configurez et installez Nagios sur le serveur de surveillance.
Installez ensuite Nagios Remote Plugin Executor (NRPE).
Pour plus d’informations sur l’installation de Nagios et de NRPE sur votre système, consultez la documentation de Nagios.
Ajoutez une définition de l’hôte pour le serveur AEM. Cette opération peut être effectuée par le biais de l’interface web de Nagios XI, en utilisant le gestionnaire de configuration :
Voici un exemple de fichier de configuration de l’hôte si vous utilisez 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
}
Installez Nagios et NRPE sur le serveur AEM.
Installez le module externe check_http_json sur les deux serveurs.
Définissez une commande de contrôle JSON générique sur les deux serveurs :
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$'
}
Ajoutez un service pour la mémoire utilisée sur le serveur 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>
}
Reportez-vous au tableau de bord Nagios du service que vous venez de créer :
Le tableau de bord des opérations permet également d’accéder aux outils de diagnostic, qui peuvent vous aider à identifier et à résoudre les causes principales des avertissements figurant dans le tableau de bord des contrôles de l’intégrité et fournissent en outre des informations de débogage importantes pour les opérateurs système.
Ses fonctionnalités les plus importantes sont les suivantes :
Pour accéder à l’écran Outils de diagnostic, sélectionnez Outils > Opérations > Diagnostic dans l’écran d’accueil d’AEM. Vous pouvez également accéder à l’écran en accédant directement à l’URL suivante : https://serveraddress:port/libs/granite/operations/content/diagnosis.html
.
Par défaut, l’interface utilisateur des messages du journal affiche tous les messages ERREUR. Si vous souhaitez afficher davantage de messages du journal, vous devez configurer un enregistreur avec le niveau de journalisation approprié.
Les messages du journal utilisent un appender de journal en mémoire et ne sont donc pas liés aux fichiers journaux. En outre, la modification des niveaux de journal dans cette interface utilisateur ne modifie pas les informations consignées dans les fichiers journaux traditionnels. L’ajout et la suppression d’enregistreurs dans cette interface utilisateur affectent uniquement l’enregistreur dans la mémoire. Notez par ailleurs que la modification des configurations de l’enregistreur se répercutera ultérieurement dans l’enregistreur en mémoire : les entrées déjà journalisées et qui ne sont plus pertinentes ne sont pas supprimées, mais des entrées similaires ne seront pas journalisées à l’avenir.
Vous pouvez configurer les éléments journalisés en fournissant des configurations d’enregistreur en cliquant sur l’icône d’engrenage dans la partie supérieure gauche de l’interface utilisateur. Vous pouvez y ajouter, supprimer ou mettre à jour des configurations d’enregistreur. Une configuration d’enregistreur se compose d’un niveau de journal (AVERTISSEMENT/INFO/DÉBOGAGE) et d’un nom de filtre. Le nom du filtre est chargé de filtrer la source des messages du journal consignés. Si un enregistreur doit enregistrer tous les messages du journal pour un niveau spécifié, le nom du filtre doit être « root ». La définition du niveau d’un enregistreur déclenche l’enregistrement de tous les messages dont le niveau est supérieur ou égal au niveau spécifié.
Exemples :
Si vous envisagez d’enregistrer tous les messages ERREUR, aucune configuration n’est nécessaire. Tous les messages ERREUR sont capturés par défaut.
Si vous envisagez d’enregistrer tous les messages ERREUR, AVERTISSEMENT et INFO, le nom de l’enregistreur doit être défini sur « root » et le niveau de l’enregistreur sur INFO.
Si vous envisagez d’enregistrer tous les messages issus d’un module particulier (par exemple, com.adobe.granite), le nom de l’enregistreur doit être défini sur « com.adobe.granite » et le niveau de l’enregistreur sur DÉBOGAGE (ce qui capturera tous les messages ERREUR, AVERTISSEMENT, INFO et DÉBOGAGE), comme illustré dans l’image ci-dessous.
Vous ne pouvez pas définir un nom d’enregistreur de manière à consigner uniquement les messages ERREUR par le biais d’un filtre spécifié. Par défaut, tous les messages ERREUR sont capturés.
L’interface utilisateur des messages du journal ne reflète pas le journal d’erreurs réel. À moins que vous n’ayez configuré d’autres types de messages du journal dans l’interface utilisateur, seuls les messages d’erreur s’affichent. Pour savoir comment afficher des messages spécifiques du journal, consultez les instructions ci-dessus.
Les paramètres de la page de diagnostic n’ont aucune incidence sur les éléments consignés dans les fichiers journaux et inversement. Ainsi, même si le journal d’erreurs peut capturer des messages INFO, il est possible qu’ils ne s’affichent pas dans l’interface utilisateur des messages du journal. Par ailleurs, par le biais de l’interface utilisateur, il est possible de capturer des messages DÉBOGAGE provenant de certains modules sans que cela affecte le journal des erreurs. Pour plus d’informations sur la configuration des fichiers journaux, consultez la section Journalisation.
Dans AEM 6.4, les tâches de maintenance sont journalisées prêtes à l’emploi dans un format d’information enrichi au niveau INFO. L’état des tâches de maintenance est ainsi plus lisible.
Si vous utilisez des outils tiers (comme Splunk) pour surveiller l’activité des tâches de maintenance et y réagir, vous pouvez utiliser les instructions de journal suivantes :
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
La page Performances des demandes permet d’analyser les demandes de page les plus lentes traitées. Seules les demandes de contenu sont enregistrées dans cette page. Plus spécifiquement, les demandes enregistrées sont les suivantes :
/content
/etc/design
".html"
La page affiche les informations suivantes :
Par défaut, les 20 demandes de page les plus lentes sont enregistrées, mais la limite peut être modifiée dans le gestionnaire de configuration.
La page Performance des requêtes permet d’analyser les requêtes les plus lentes exécutées par le système. Ces informations sont fournies par le référentiel dans un MBean JMX. Ces informations sont fournies par le MBean JMX com.adobe.granite.QueryStat
dans Jackrabbit et par org.apache.jackrabbit.oak.QueryStats.
dans le référentiel Oak.
La page affiche les informations suivantes :
Oak tente de déterminer la meilleure façon d’exécuter une requête donnée d’après les index Oak définis dans le référentiel sous le nœud oak:index. En fonction de la requête, Oak peut sélectionner différents index. La première étape d’optimisation de la requête consiste à comprendre la façon dont Oak exécute une requête.
L’outil Expliquer la requête explique la façon dont Oak exécute une requête. Pour y accéder, sélectionnez Outils > Opérations > Diagnostic dans l’écran d’accueil d’AEM, puis cliquez sur Performances des requêtes et accédez à l’onglet Expliquer la requête.
Fonctionnalités
Dans l’interface utilisateur de l’outil Expliquer la requête, entrez la requête et appuyez sur le bouton Expliquer :
La première entrée de la section Explication de la requête est l’explication réelle. L’explication indique le type d’index utilisé pour exécuter la requête.
La seconde entrée est le plan d’exécution.
Si vous activez la case à cocher Inclure le délai d’exécution avant d’exécuter la requête, le délai d’exécution de la requête s’affiche également, ce qui permet d’utiliser davantage d’informations afin d’optimiser les index pour l’application ou le déploiement.
Le gestionnaire d’index vise à faciliter la gestion des index, notamment leur tenue à jour ou l’affichage de leur statut.
Pour y accéder, sélectionnez Outil - Opérations - Diagnostic dans l’écran d’accueil, puis cliquez sur le bouton Gestionnaire d’index.
Il est également accessible directement à cette adresse : https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
.
L’interface utilisateur peut être utilisée pour filtrer les index dans le tableau en entrant les critères de filtre dans la zone de recherche située dans le coin supérieur gauche de l’écran.
Cette option permet de télécharger un fichier ZIP contenant des informations utiles sur l’état et la configuration du système. L’archive contient des configurations d’instance, une liste de lots, OSGi, des indicateurs Sling et des statistiques. Le fichier qui en résulte peut être volumineux. Vous pouvez réduire l’impact des fichiers d’état volumineux à l’aide de la fenêtre Télécharger le ZIP d’état. Pour y accéder, sélectionnez AEM > Outils > Opérations > Diagnostic > Télécharger le fichier de statut au format ZIP.
Dans cette fenêtre, vous pouvez sélectionner les éléments à exporter (fichiers journaux et image mémoire des threads) ainsi que le nombre de jours à prendre en compte dans le téléchargement par rapport à la date actuelle.
Cette option déclenche le téléchargement d’un fichier ZIP contenant des informations sur les threads présents sur le système. Des informations sur chaque thread sont fournies (état, chargeur de classes et trace de pile, notamment).
Vous avez également la possibilité de télécharger un instantané du segment de mémoire afin de l’analyser ultérieurement. Remarque : le fichier téléchargé est volumineux, de l’ordre de centaines de mégaoctets.
Depuis la page Tâches de maintenance automatisées, affichez et suivez les tâches de maintenance recommandées planifiées pour une exécution périodique. Les tâches sont intégrées au système de contrôle de l’intégrité. Elles peuvent également être exécutées manuellement à partir de l’interface.
Pour accéder à la page Maintenance du tableau de bord des opérations, sélectionnez Outils > Opérations > Tableau de bord > Maintenance dans l’écran d’accueil d’AEM ou cliquez directement sur ce lien :
https://serveraddress:port/libs/granite/operations/content/maintenance.html
Les tâches ci-dessous sont disponibles dans le tableau de bord des opérations :
La tâche Nettoyage des révisions, située sous Période de maintenance quotidienne .
La tâche Nettoyage des binaires Lucene, située sous Période de maintenance quotidienne .
La tâche Purge du workflow , située sous la tâche Période de maintenance hebdomadaire .
Tâche Nettoyage de la mémoire d’entrepôt de données dans le menu Période de maintenance hebdomadaire
Tâche Maintenance des journaux d’audit dans le menu Période de maintenance hebdomadaire
Tâche Maintenance de la purge des versions dans le menu Période de maintenance hebdomadaire
La synchronisation par défaut pour la période de maintenance quotidienne a lieu de 2 h à 5 h du matin. Les tâches configurées pour s’exécuter pendant la période de maintenance hebdomadaire sont exécutées entre 1 h et 2 h du matin le samedi.
Vous pouvez également configurer des synchronisations en appuyant sur l’icône d’engrenage sur l’une des deux cartes de maintenance :
Depuis AEM 6.1, il est également possible de configurer les périodes de maintenance existantes pour qu’elles s’exécutent tous les mois.
Pour plus d’informations sur l’exécution du nettoyage de la révision pour AEM 6.4, consultez cet article.
Utilisez la tâche Nettoyage des binaires Lucene pour purger les fichiers binaires Lucene et réduire la taille nécessaire pour l’exécution de l’entrepôt de données. En effet, le taux de perte des fichiers binaires Lucene est redéclaré tous les jours, à la place de l’ancienne dépendance, lors d’une exécution réussie du nettoyage de l’entrepôt de données.
La tâche de maintenance a été conçue en vue de réduire les objets inutilisés dans les révisions liés à Lucene, mais elle présente en outre des avantages d’ordre général en termes d’efficacité :
Pour accéder à la tâche Nettoyage des binaires Lucene, sélectionnez AEM > Outils > Opérations > Maintenance > Période de maintenance quotidienne > Nettoyage des binaires Lucene.
Pour plus d’informations sur ce sujet, consultez cette page de la documentation.
Il est possible également de purger les workflows à partir du tableau de bord de maintenance. Pour exécuter la tâche de purge du workflow, procédez comme suit :
Pour plus d’informations sur la maintenance du workflow, consultez cette page.
Pour en savoir plus sur la maintenance des journaux d’audit, consultez cette page de la documentation.
Vous pouvez planifier la tâche de maintenance Purge de version pour supprimer automatiquement les anciennes versions. Vous aurez ainsi moins besoin d’utiliser manuellement les outils de purge de version. Pour planifier et configurer la tâche Purge de version, sélectionnez Outils > Opérations > Maintenance > Période de maintenance hebdomadaire et procédez comme suit :
Cliquez sur le bouton Ajouter.
Sélectionnez Purge de version dans le menu déroulant.
Pour configurer la tâche Purge de version, cliquez sur l’icône d’engrenage sur la carte de maintenance Purge de version qui vient d’être créée.
Dans AEM 6.4, vous pouvez arrêter la tâche de maintenance Purge de version comme suit :
L’arrêt de la tâche de maintenance consiste à suspendre son exécution sans perdre la trace de la tâche déjà en cours.
Pour optimiser la taille du référentiel, vous devez exécuter la tâche Purge de version fréquemment. La tâche doit être planifiée en dehors des heures de bureau lorsque le trafic est limité.
Les tâches de maintenance personnalisées peuvent être mises en œuvre sous forme de services OSGi. Lorsque l’infrastructure des tâches de maintenance repose sur le traitement des tâches Apache Sling, une tâche de maintenance doit mettre en œuvre l’interface Java [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html)
. De plus, pour être détectée comme tâche de maintenance, elle doit déclarer différentes propriétés d’enregistrement de service, comme indiqué ci-dessous :
Nom de la propriété du service |
Description | Exemple |
Type |
granite.maintenance.isStoppable | Attribut booléen définissant si la tâche peut être arrêtée par l’utilisateur. Si une tâche indique qu’elle peut être arrêtée, elle doit vérifier pendant son exécution si elle a été arrêtée, puis agir en conséquence. La valeur par défaut est false. | true | Facultative |
granite.maintenance.mandatory | Attribut booléen définissant si une tâche est obligatoire et doit être exécutée périodiquement. Si une tâche est obligatoire, mais qu’elle ne se trouve pas actuellement dans une fenêtre de planification active, un contrôle de l’intégrité signale qu’il s’agit d’une erreur. La valeur par défaut est false. | true | Facultative |
granite.maintenance.name | Nom unique de la tâche : il est utilisé pour référencer la tâche. Il s’agit généralement d’un nom simple. | MyMaintenanceTask | Requise |
granite.maintenance.title | Titre affiché pour cette tâche | Ma tâche de maintenance spéciale | Requise |
job.topics | Il s’agit d’une rubrique unique à la tâche de maintenance. Le traitement des tâches Apache Sling démarre une tâche avec précisément cette rubrique afin d’exécuter la tâche de maintenance ; lorsque la tâche est enregistrée pour cette rubrique, elle est exécutée. La rubrique doit commencer par com/adobe/granite/maintenance/job/. |
com/adobe/granite/maintenance/job/MyMaintenanceTask | Requise |
En dehors des propriétés de service ci-dessus, la méthode process()
de l’interface JobConsumer
doit être mise en œuvre en ajoutant le code à exécuter pour la tâche de maintenance. L’élément JobExecutionContext
fourni peut être utilisé pour générer les informations de statut. Vérifiez si la tâche est interrompue par l’utilisateur et produit un résultat (réussite ou échec).
Dans les cas où une tâche de maintenance ne doit pas être exécutée sur toutes les installations (si vous l’exécutez uniquement sur l’instance de publication, par exemple), vous pouvez faire en sorte que le service doive être configuré de manière à être actif en ajoutant @Component(policy=ConfigurationPolicy.REQUIRE)
. Vous pouvez alors marquer la configuration correspondante comme étant dépendante du mode d’exécution dans le référentiel. Pour plus d’informations, consultez la section Configuration d’OSGi.
Vous trouverez ci-dessous un exemple de tâche de maintenance personnalisée, qui supprime des fichiers dans un répertoire temporaire configurable, modifié dans les dernières 24 heures :
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
Une fois le service déployé, il est exposé dans le tableau de bord des opérations et peut être ajouté à l’une des planifications de maintenance disponibles :
Une ressource correspondant sera ajoutée à l’adresse /apps/granite/operations/config/maintenance/schedule
/taskname
. Si la tâche dépend du mode d’exécution, la propriété granite.operations.conditions.runmode doit être définie sur ce nœud avec les valeurs des modes d’exécution qui doivent être actives pour cette tâche de maintenance.
Le tableau de bord de présentation du système présente en détail la configuration, le matériel et l’intégrité de l’instance AEM. En d’autres termes, le statut d’intégrité du système est transparent et toutes les informations sont agrégées dans un tableau de bord unique.
Vous pouvez également visionner cette vidéo pour découvrir une présentation du tableau de bord de présentation du système.
Pour accéder au tableau de bord de présentation du système, sélectionnez Outils > Opérations > Présentation du système.
Le tableau ci-dessous décrit toutes les informations affichées dans le tableau de bord de présentation du système. Gardez à l’esprit que lorsqu’il n’y a pas de données à afficher (par exemple, aucune sauvegarde n’est en cours ou aucun contrôle de l’intégrité n’a l’état « Critique »), la section correspondante affiche le message « Aucune entrée ».
Vous pouvez également télécharger un fichier JSON
qui récapitule les informations du tableau de bord en cliquant sur le bouton Télécharger dans le coin supérieur droit du tableau de bord. Le point d’entrée JSON
est /libs/granite/operations/content/systemoverview/export.json
et il peut être utilisé dans un script curl
pour la surveillance externe.
Section | Informations affichées | Statut « Critique » | Est lié à |
Contrôles de l’intégrité |
|
Indication visuelle :
|
|
Tâches de maintenance |
|
Indication visuelle :
|
|
Système |
|
S/O | S/O |
Instance |
|
S/O | S/O |
Référentiel |
|
S/O | S/O |
Agents de distribution |
|
Indication visuelle :
|
Page de distribution |
Agents de réplication |
|
Indication visuelle :
|
Page de réplication |
Workflows |
Pour chacun des états présentés ci-dessus, une requête est exécutée, avec une limite de 400 millisecondes. À 400 millisecondes, le nombre d’entrées obtenues jusqu’à ce point s’affiche. |
Non interprété :
|
Page Échecs de workflow |
Tâches Sling | Nombre de tâches Sling : nombre de tâches ayant un état déterminé (le cas échéant) :
|
Non interprété :
|
S/O |
Nombre de nœuds estimés | Nombre estimé :
Le nombre total de nœuds est dérivé de nodeCounterMBean ; les autres statistiques proviennent d’IndexInfoService. |
S/O | S/O |
Sauvegarde | Affiche « Sauvegarde en ligne en cours », le cas échéant. | S/O | S/O |
Indexation | Affiche :
Si un thread d’indexation ou de requête est présent dans l’image mémoire des threads. |
S/O | S/O |