Tableau de bord des opérations

Présentation

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 fournit également des informations de diagnostic générées automatiquement sur les aspects pertinents de l'AEM et permet de configurer et d'exécuter une automatisation de maintenance autonome afin de réduire considérablement les opérations de projet et les cas 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 :

• est un état du système accessible en un clic, qui aide les services Opérations à optimiser leur efficacité ;
• fournit une vue d’ensemble des contrôles de l’intégrité du système à un emplacement centralisé unique ;
• réduit le délai pour trouver, analyser et corriger des problèmes ;
• permet une automatisation de la maintenance autonome, qui contribue à réduire considérablement les coûts de fonctionnement de votre projet.

It can be accessed by going to Tools - Operations from the AEM Welcome screen.

Rapports d’intégrité

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.

Contrôles de l’intégrité

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.

The Health Reports interface can be accessed through the Tools - Operations - Health Reports menu on the AEM Welcome screen, or directly through the following URL:

https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html

Le système de cartes comporte trois états possibles : OK, AVERTISSEMENT et CRITIQUE. Les états 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 :

Types de contrôle de l’intégrité

Dans AEM 6, il existe deux types de contrôle de l’intégrité :

1. Contrôles de l’intégrité individuels
2. Contrôles de l’intégrité composites

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. L’état d’un contrôle de l’intégrité composite est « OK » seulement si l’état de tous les contrôles individuels est également « OK ».

Procédure de création de contrôles de l’intégrité

Dans le tableau de bord des opérations, vous pouvez visualiser le résultat des contrôles de l’intégrité individuels et composites.

Création d’un contrôle de l’intégrité individuel

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.

1. 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     
       }
    }
   

   Remarque

   La propriété MBEAN_NAME définit le nom du MBean généré pour ce contrôle de l’intégrité.

2. 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). To create a configuration for the Health Check, open CRXDE and add a new node (of type nt:unstructured) under the following path: /apps/settings/granite/operations/hc

   Les propriétés ci-dessous doivent être définies sur le nouveau nœud :

   • Nom: sling:resourceType

     • Type: String
     • Valeur: granite/operations/components/mbean

   • Nom: resource

     • Type: String
     • Valeur: /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
   Remarque

   The resource path above is created as follows: if the mbean name of your Health Check is "test", add "test" to the end of the path /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

   Remarque

   Make sure that the /apps/settings/granite/operations/hc path has the following properties set to true:

   sling:configCollectionInherit

   sling:configPropertyInherit

   Cela indique au gestionnaire de configuration de fusionner les nouvelles configurations avec les configurations existantes de /libs.

Création d’un contrôle de l’intégrité composite

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.

1. Accédez au gestionnaire de configuration web dans la console OSGi. You can do this by accessing https://serveraddress:port/system/console/configMgr

2. 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é.

3. 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 :

   

4. 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 :

   • Nom (hc.name) : nom du contrôle de l’intégrité composite. Il est recommandé d’utiliser un nom éloquent.
   • Balises (hc.tags) : balises de ce contrôle de l’intégrité. Si ce contrôle de l’intégrité composite est conçu pour faire partie d’un autre contrôle de l’intégrité composite (comme dans une hiérarchie de contrôles de l’intégrité), ajoutez les balises auxquelles ce contrôle composite est lié.
   • Nom du MBean (hc.mbean.name) : nom du MBean qui sera attribué au MBean JMX de ce contrôle de l’intégrité composite.
   • Balises de filtrage (filter.tags) : il s’agit d’une propriété spécifique aux contrôles de l’intégrité composites. Ce sont les balises que le contrôle composite doit agréger. Le contrôle de l’intégrité composite agrège, sous son groupe, tous les contrôles de l’intégrité possédant une balise correspondant aux balises de filtrage de ce contrôle composite. Par exemple, un contrôle de l’intégrité composite possédant les balises de filtrage test et check agrège tous les contrôles de l’intégrité individuels et composites possédant la balise test ou check dans leur propriété de balise ( hc.tags).
   Remarque

   Un nouveau MBean JMX est créé pour chaque nouvelle configuration du contrôle de l’intégrité composite Apache Sling.**

5. 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. The procedure for this is the same as with individual health checks: a node of type nt:unstructured needs to be created under /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

     • Type: nt:unstructured

   Avec les propriétés suivantes :

   • Nom: sling:resourceType

     • Type: String
     • Valeur: granite/operations/components/mbean

   • Nom: resource

     • Type: String
     • Valeur: /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
   Remarque

   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 il est installé et s’affiche automatiquement sous le contrôle composite de sécurité dans le tableau de bord des opérations.

Contrôles de l’intégrité fournis avec AEM

Nom du contrôle de l’intégrité	Description
Performances des requêtes	This health check was simplified in AEM 6.4, and now checks the recently-refactored Oak QueryStats MBean, more specifically the SlowQueries attribute. Si les statistiques contiennent des requêtes lentes, le contrôle de l’intégrité renvoie un avertissement. Autrement, il renvoie l’état « OK ». The MBean for this health check is org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck.
Longueur de la file d’attente d’observation	Observation Queue Length iterates over all Event Listeners and Background Observers, compares their queueSize to their maxQueueSize and: returns Critical status if the queueSize value exceeds the maxQueueSize value (that is when events would be dropped) returns Warn if the queueSize value is over the maxQueueSize * WARN_THRESHOLD (the default value is 0.75) 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é. The MBean for this health check is org.apache.sling.healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck.
Limites de requête transversales	Query Traversal Limits checks the QueryEngineSettings MBean, more specifically the LimitInMemory and LimitReads attributes, and returns the following status: renvoie l’état Avertir si l’une des limites est égale ou supérieure à la valeur Integer.MAX_VALUE « Avertissement » si l’une des limites est inférieure à 10 000 (paramètre recommandé d’Oak) ; returns the Critical status if the QueryEngineSettings or any of the limits cannot be retrieved The Mbean for this health check is org.apache.sling.healthcheck:name=queryTraversalLimitsBundle,type=HealthCheck.
Horloges synchronisées	This check is relevant only for document nodestore clusters. Il renvoie l’état suivant : « Avertissement » lorsque les horloges des instances sont désynchronisées et dépassent un seuil inférieur prédéfini ; « Critique » lorsque les horloges des instances sont désynchronisées et dépassent un seuil supérieur prédéfini ; The Mbean for this health check is org.apache.sling.healthcheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck.
Index asynchrones	Le contrôle « Index asynchrones » : renvoie « Critique » si au moins une piste d’indexation échoue ; checks the lastIndexedTime for all indexing lanes and: renvoie l'état critique s'il y a plus de 2 heures renvoie l'état d'avertissement s'il y a entre 2 heures et 45 minutes renvoie l'état OK s'il y a moins de 45 minutes renvoie « OK » si aucune de ces conditions n’est remplie. Les seuils des états Critique et Avertissement sont configurables. The Mbean for this health check is org.apache.sling.healthcheck:name=asyncIndexHealthCheck,type=HealthCheck. Remarque : Cette vérification de l'état de santé est disponible avec AEM 6.4 et a été reportée à AEM 6.3.0.1.
Index Lucene volumineux	This check uses the data exposed by the Lucene Index Statistics MBean to identify large indexes and returns: « Avertissement » s’il y a un index comportant plus de 1 milliard de documents ; « Critique » s’il y a un index comportant plus de 1,5 milliard de documents. The thresholds are configurable and the MBean for the health check is 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 : chaque tâche de maintenance est accompagnée d'un contrôle d'intégrité associé si une tâche n’est pas ajoutée à une période de maintenance, son contrôle de l’intégrité renvoie l’état « Critique » ; vous devez configurer les tâches de maintenance du journal d’audit et de purge des workflows ou les supprimer des fenêtres de maintenance. Si ces tâches ne sont pas configurées, elles échouent lors de la première tentative d’exécution et le contrôle « Maintenance système » renvoie l’état « Critique ». Avec AEM 6.4, il existe également un contrôle pour la tâche Maintenance des fichiers binaires Lucene. Dans AEM 6.2 et version inférieure, le contrôle de la maintenance système renvoie un état « Avertissement » après le démarrage, car les tâches ne sont jamais exécutées. À compter de la version 6.3, il renvoie l’état « OK » si la première période de maintenance n’a pas encore été atteinte. The MBean for this health check is 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 numberOfRetriesAllowed, il renvoie un avertissement. The numberOfRetriesAllowed parameter is configurable. The MBean for this health check is org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck.
Tâches Sling	Sling Jobs checks the number of jobs queued in the JobManager, compares it to the maxNumQueueJobs threshold, and: returns Critical if more than the maxNumQueueJobs are in the queue renvoie « Critique » si des tâches actives sont en cours d’exécution depuis plus de 1 h ; renvoie « Critique » s’il y a des tâches en file d’attente et que la dernière tâche terminée remonte à plus de 1 h. Seul le nombre maximal du paramètre de tâches en file d’attente est configurable (1 000 par défaut). The MBean for this health check is org.apache.sling.healthcheck:name=slingJobs,type=HealthCheck.
Performances des demandes	This check looks at the granite.request.metrics.timer Sling metric and: renvoie « Critique » si la valeur du 75e percentile dépasse le seuil critique (la valeur par défaut est de 500 millisecondes) ; renvoie « Avertissement » si la valeur du 75e percentile dépasse le seuil d’avertissement (la valeur par défaut est de 200 millisecondes). The MBean for this health check is org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck.
Erreurs de journal	Ce contrôle renvoie l’état « Avertissement » si le journal comporte des erreurs. The MBean for this health check is org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck.
Espace disque	The Disk Space check looks at the FileStoreStats MBean, retrieves the size of the Node Store and the amount of usable disk space on the Node Store partition, and: renvoie « Avertissement » si le rapport espace disque utilisable/taille du référentiel est inférieur au seuil d’avertissement (10 par défaut) ; renvoie « Critique » si le rapport espace disque utilisable/taille du référentiel est inférieur au seuil critique (2 par défaut). Les deux seuils sont configurables. Le contrôle fonctionne uniquement sur les instances comportant un entrepôt de segments. The MBean for this health check is 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. The MBean for this health check is 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é. These individual health checks address different concerns from the security checklist available at the Security Checklist documentation page. La vérification est utile comme test de fumée de sécurité au démarrage de l'instance. The MBean for this health check is org.apache.sling.healthcheck:name=securitychecks,type=HealthCheck
Lots actifs	Les lots actifs contrôlent l’état de tous les lots et : renvoient l’état « Avertissement » si l’un des lots n’est pas actif ou (à commencer par une activation différée) ; ignorent l’état des lots dans la liste Ignorer. Le paramètre de la liste Ignorer est configurable. The MBean for this health check is 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 : il renvoie l’état « Avertissement » si l’instance est exécutée sur Java 7, avec la purge du cache du code activée ; il renvoie l’état « Avertissement » si l’instance est exécutée sur Java 7 et que la taille du cache du code est inférieure à un seuil minimal (la valeur par défaut est 90 Mo). The minimum.code.cache.size threshold is configurable. For more information about the bug, check this page. 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	Checks if there are any resources in the path /apps/foundation/components/primary and: renvoie Avertir s'il y a des noeuds enfants sous /apps/foundation/components/primary Le MBean de ce contrôle de l’intégrité est org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck.

Surveillance à l’aide de Nagios

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.

1. Configurez et installez Nagios sur le serveur de surveillance.

2. Installez ensuite Nagios Remote Plugin Executor (NRPE).

   Remarque

   Pour plus d’informations sur l’installation de Nagios et de NRPE sur votre système, consultez la documentation de Nagios.

3. 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 :

   1. Ouvrez un navigateur et pointez vers le serveur Nagios.
   2. Appuyez sur le bouton Configure dans le menu supérieur.
   3. Dans le volet de gauche, appuyez sur Core Config Manager sous Advanced Configuration.
   4. Press the Hosts link under the Monitoring section.
   5. Ajoutez la définition de l’hôte :

   

   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
   }
   

4. Installez Nagios et NRPE sur le serveur AEM.

5. Installez le module externe check_http_json sur les deux serveurs.

6. 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$'
   
   }
   

7. 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>
   
       }
   

8. Reportez-vous au tableau de bord Nagios du service que vous venez de créer :

   

Outils de diagnostic

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 :

• Analyseur de messages du journal
• Possibilité d’accéder aux images mémoire des segments de mémoire et des threads
• Demandes et analyseurs de performances des requêtes

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

Messages du journal

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. Une autre conséquence est que la modification des niveaux de journalisation dans cette interface utilisateur ne modifiera pas les informations qui sont enregistré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.

Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>

Performances des demandes

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 :

1. Requests accessing resources under /content
2. Requests accessing resources under /etc/design
3. Requests having the ".html" extension

La page affiche les informations suivantes :

• Heure de la demande
• Adresse URL et méthode de la demande
• Durée en millisecondes

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.

Performances des requêtes

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 :

• Heure de la requête
• Langage de la requête
• Nombre de fois où la requête a été exécutée
• Instruction de la requête
• Durée en millisecondes

Expliquer la requête

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

• Prend en charge les langages de requête Xpath, JCR-SQL et JCR-SQL2.
• Indique le temps d’exécution réel de la requête spécifiée.
• Détecte les requêtes lentes et avertit au sujet des requêtes pouvant être potentiellement lentes.
• Indique l’index Oak utilisé pour exécuter la requête.
• Affiche l’explication du moteur Oak Query.
• Fournit la liste des éléments à charger des requêtes lentes et populaires.

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.

Gestionnaire d’index

Le gestionnaire d’index vise à faciliter la gestion des index, notamment leur tenue à jour ou l’affichage de leur statut.

It can be accessed by going to Tools - Operations - Diagnosis from the Welcome Screen, and then clicking the Index Manager button.

It can also be accessed directly at this URL: 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.

Télécharger le ZIP d’état

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, des mesures OSGI, Sling et des statistiques, ce qui peut générer un fichier volumineux. Vous pouvez réduire l'impact des fichiers d'état volumineux en utilisant la fenêtre ZIP d'état de téléchargement. The window can be accessed from: AEM > Tools > Operations > Diagnosis > Download Status ZIP.

Dans cette fenêtre, vous pouvez sélectionner les éléments à exporter (fichiers journaux et/ou image mémoire des threads) ainsi que le nombre de jours à prendre en compte dans le téléchargement par rapport à la date actuelle.

Télécharger l’image mémoire des threads

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).

Télécharger l’image mémoire des segments de mémoire

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.

Tâches de maintenance automatisées

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 :

1. The Revision Clean Up task, located under the Daily Maintenance Window menu.

2. The Lucene Binaries Cleanup task, located under the Daily Maintenance Window menu.

3. The Workflow purge task, located under the Weekly Maintenance Window menu.

4. The Data Store Garbage Collection task, located under the Weekly Maintenance Window menu.

5. The Audit Log Maintenance task, located under the Weekly Maintenance Window menu.

6. The Version Purge Maintenance task, located under the Weekly Maintenance Window menu.

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 :

Nettoyage de la révision

Pour plus d’informations sur l’exécution du nettoyage de la révision pour AEM 6.4, consultez cet article.

Nettoyage des binaires Lucene

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. This is because the lucene's binary churn will be re-claimed daily instead of the earlier dependency on a successful data store garbage collection run.

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é :

• L’exécution hebdomadaire de la tâche de nettoyage d’un entrepôt de données se terminera plus rapidement.
• Il peut également légèrement améliorer les performances AEM globales

You can access the Lucene Binaries Cleanup task from: AEM > Tools > Operations > Maintenance > Daily Maintenance Window > Lucene Binaries Cleanup.

Nettoyage de la mémoire d’entrepôt de données

Pour plus d’informations sur ce sujet, consultez cette page de la documentation.

Purge du workflow

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 :

1. Cliquez sur la page Période de maintenance hebdomadaire.
2. Dans la page suivante, cliquez sur le bouton Lire dans la carte Purge du workflow.

Maintenance des journaux d’audit

Pour en savoir plus sur la maintenance des journaux d’audit, consultez cette page de la documentation.

Purge de version

Vous pouvez planifier la tâche de maintenance Purge de version pour supprimer automatiquement les anciennes versions. As a result, this minimizes the need to manually use the Version Purge tools. You can schedule and configure the Version Purge task by accessing Tools > Operations > Maintenance > Weekly Maintenance Window and following these steps:

1. Click the Add button.

2. Choose Version Purge from the drop-down menu.

   

3. To configure the Version Purge task, click on the gears icon on the newly created Version Purge maintenance card.

   

Dans AEM 6.4, vous pouvez arrêter la tâche de maintenance Purge de version comme suit :

• Automatiquement : si la période de maintenance planifiée se termine avant que la tâche ne puisse se terminer, celle-ci s’arrête automatiquement. Elle reprend lorsque commence la période de maintenance suivante.
• Manually - To manually stop the task, on the Version Purge maintenance card, click the Stop icon. La tâche reprend en toute sécurité lors de la prochaine exécution.

Tâches de maintenance personnalisées

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 l'utilisateur peut arrêter la tâche. 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	Facultatif
granite.maintenance.mandatory	Attribut booléen définissant si une tâche est obligatoire et doit être exécutée régulièrement. 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	Facultatif
granite.maintenance.name	Nom unique de la tâche : il est utilisé pour faire référence à la tâche. Il s’agit généralement d’un nom simple.	MyMaintenanceTask	Requis
granite.maintenance.title	Titre affiché pour cette tâche	Ma Tâche de maintenance spéciale	Requis
job.topics	Il s'agit d'un sujet unique de la tâche de maintenance. Le traitement des tâches Apache Sling démarre une tâche avec cette rubrique exactement 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 être début avec com/adobe/granite/maintenance/job/	com/adobe/granite/maintenance/job/MyMaintenanceTask	Requis

Apart from the above service properties, the process() method of the JobConsumer interface needs to be implemented by adding the code that should be executed for the maintance task. L’élément JobExecutionContext fourni peut être utilisé pour générer les informations d’état. Vérifiez si la tâche est interrompue par l’utilisateur et produit un résultat (réussite ou échec).

For situations where a maintenance task should not be run on all installations (for example, run only on the publish instance), you can make the service require a configuration in order to be active by adding @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, voir 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

/* * #%L * sample-maintenance-task * %% * Copyright (C) 2014 Adobe * %% * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * https://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. * #L% */ package com.adobe.granite.samples.maintenance.impl; import java.io.File; import java.util.Calendar; import java.util.Collection; import java.util.Map; import org.apache.commons.io.FileUtils; import org.apache.commons.io.filefilter.IOFileFilter; import org.apache.commons.io.filefilter.TrueFileFilter; import org.apache.felix.scr.annotations.Activate; import org.apache.felix.scr.annotations.Component; import org.apache.felix.scr.annotations.Properties; import org.apache.felix.scr.annotations.Property; import org.apache.felix.scr.annotations.Service; import org.apache.sling.commons.osgi.PropertiesUtil; import org.apache.sling.event.jobs.Job; import org.apache.sling.event.jobs.consumer.JobConsumer; import org.apache.sling.event.jobs.consumer.JobExecutionContext; import org.apache.sling.event.jobs.consumer.JobExecutionResult; import org.apache.sling.event.jobs.consumer.JobExecutor; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import com.adobe.granite.maintenance.MaintenanceConstants; @Component(metatype = true, label = "Delete Temp Files Maintenance Task", description = "Maintatence Task which deletes files from a configurable temporary directory which have been modified in the last 24 hours.") @Service @Properties({ @Property(name = MaintenanceConstants.PROPERTY_TASK_NAME, value = "DeleteTempFilesTask", propertyPrivate = true), @Property(name = MaintenanceConstants.PROPERTY_TASK_TITLE, value = "Delete Temp Files", propertyPrivate = true), @Property(name = JobConsumer.PROPERTY_TOPICS, value = MaintenanceConstants.TASK_TOPIC_PREFIX + "DeleteTempFilesTask", propertyPrivate = true) }) public class DeleteTempFilesTask implements JobExecutor { private static final Logger log = LoggerFactory.getLogger(DeleteTempFilesTask.class); @Property(label = "Temporary Directory", description="Temporary Directory. Defaults to the java.io.tmpdir system property.") private static final String PROP_TEMP_DIR = "temp.dir"; private File tempDir; @Activate private void activate(Map<string, object=""> properties) { this.tempDir = new File(PropertiesUtil.toString(properties.get(PROP_TEMP_DIR), System.getProperty("java.io.tmpdir"))); } @Override public JobExecutionResult process(Job job, JobExecutionContext context) { log.info("Deleting old temp files from {}.", tempDir.getAbsolutePath()); Collection<file> files = FileUtils.listFiles(tempDir, new LastModifiedBeforeYesterdayFilter(), TrueFileFilter.INSTANCE); int counter = 0; for (File file : files) { log.debug("Deleting file {}.", file.getAbsolutePath()); counter++; file.delete(); / TODO - capture the output of delete() and do something useful with it } return context.result().message(String.format("Deleted %s files.", counter)).succeeded(); } /** * IOFileFilter which filters out files which have been modified in the last 24 hours. * */ private static class LastModifiedBeforeYesterdayFilter implements IOFileFilter { private final long minTime; private LastModifiedBeforeYesterdayFilter() { Calendar cal = Calendar.getInstance(); cal.add(Calendar.DATE, -1); this.minTime = cal.getTimeInMillis(); } @Override public boolean accept(File dir, String name) { / this method is never actually called. return false; } @Override public boolean accept(File file) { return file.lastModified() <= this.minTime; } } } <file></string,>

experience-emanager-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 :

This will add a corresponding resource at /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.

Présentation du système

The System Overview Dashboard displays a high-level overview of the configuration, hardware and health of the AEM instance. En d’autres termes, l’état d’intégrité du système est transparent et toutes les informations sont agrégées dans un tableau de bord unique.

Accès

To access the System Overview Dashboard, navigate to Tools > Operations > System Overview.

Explication du tableau de bord de 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 ».

You can also download a JSON file summarizing the dashboard information by clicking the Download button in the upper right-hand corner of the dashboard.The JSON endpoint is /libs/granite/operations/content/systemoverview/export.json and it can be used in a curl script for external monitoring.

Section	Informations affichées	État « Critique »	Est lié à
Contrôles de l’intégrité	Liste des contrôles renvoyant l’état « Critique » Liste des contrôles renvoyant l’état « Avertissement »	Indication visuelle : Indicateur rouge pour les contrôles Critique Indicateur orange pour les contrôles Avertissement	Page Rapports d’intégrité
Tâches de maintenance	Liste des tâches ayant échoué Liste des tâches en cours d’exécution Liste des tâches qui ont réussi lors de la dernière exécution Liste des tâches qui n’ont jamais été exécutées Liste des tâches qui ne sont pas planifiées	Indication visuelle : Indicateur rouge pour les tâches ayant échoué Indicateur orange pour les tâches en cours d’exécution (car elles peuvent affecter les performances) Indicateurs gris pour tous les autres états	Page Tâches de maintenance
Système	Système d’exploitation et version du système d’exploitation (Mac OS X, par exemple) system load average, as retrieved from OperatingSystemMXBeanusable Espace disque (sur la partition sur laquelle se trouve le répertoire) maximum heap, as returned by MemoryMXBean	N/D	N/D
Instance	Version d’AEM Liste des modes d’exécution Date à laquelle l’instance a été démarrée	N/D	N/D
Référentiel	Version d’Oak Type d’entrepôt de nœuds (fichier TAR de segments ou document) Si le type est document, le type d’entrepôt de documents s’affiche (RDB ou Mongo). S’il existe un entrepôt de données personnalisé : Pour un entrepôt de données de fichiers, le chemin d’accès s’affiche. Pour un entrepôt de données S3, le nom du compartiment S3 s’affiche. Pour un entrepôt de données S3 partagé, le nom du compartiment S3 s’affiche. Pour un entrepôt de données Azure, le conteneur s’affiche. S’il n’y a pas d’entrepôt de données externe personnalisé, un message le mentionnant s’affiche.	N/D	N/D
Agents de distribution	Liste des agents comportant des files d’attente bloquées Liste des agents configurés incorrectement (« Erreur de configuration ») Liste des agents dont le traitement de la file d’attente est suspendu Liste des agents inactifs Liste des agents en cours d’exécution (qui sont actuellement des entrées de traitement)	Indication visuelle : Indicateur rouge pour les agents bloqués ou les erreurs de configuration Indicateur orange pour les agents suspendus Indicateur gris pour les agents suspendus, inactifs ou en cours d’exécution	Page de distribution
Agents de réplication	Liste des agents comportant des files d’attente bloquées Liste des agents inactifs Liste des agents en cours d’exécution (qui sont actuellement des entrées de traitement)	Indication visuelle : Indicateur rouge pour les agents bloqués Indicateur gris pour les agents suspendus	Page de réplication
Workflows	Tâches de workflow : Nombre de tâches de workflow ayant échoué (le cas échéant) nombre de tâches de processus annulées (le cas échéant) Comptabilisation des flux de travail - nombre de workflows dans un état donné (le cas échéant) : en cours d’exécution a échoué suspendu abandon 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é : L’utilisateur doit vérifier s’il existe des workflows et des tâches avec des états inattendus.	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) : a échoué en file d’attente annulé actif	Non interprété : L’utilisateur doit vérifier s’il existe des tâches avec des états inattendus ou un nombre élevé.	N/D
Nombre de nœuds estimés	Nombre estimé : pages ressources balises éléments autorisables nombre total de nœuds Le nombre total de noeuds est obtenu à partir de nodeCounterMBean, tandis que le reste des statistiques est obtenu à partir d'IndexInfoService.	N/D	N/D
Sauvegarde	Affiche « Sauvegarde en ligne en cours », le cas échéant.	N/D	N/D
Indexation	Affichages: Indexation en cours Requête en cours Si un thread d’indexation ou de requête est présent dans l’image mémoire des threads.	N/D	N/D