Tableau de bord des opérations operations-dashboard
Présentation introduction
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. De plus, les données du tableau de bord des opérations sont accessibles à partir d’outils de surveillance externes via JMX.
Le tableau de bord des opérations :
- est un état système en un clic pour aider les services d’opérations à gagner en efficacité ;
- fournit une vue d’ensemble des contrôles de l’intégrité du système à un emplacement centralisé unique ;
- Réduit le temps de recherche, d’analyse et de résolution des problèmes
- Automatisation de la maintenance autonome qui permet de réduire considérablement les coûts d’exploitation du projet
Il est accessible en sélectionnant Outils – Opérations dans l’écran d’accueil d’AEM.
Rapports d’intégrité health-reports
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 des seuils pour certains compteurs configurables et, dans certains cas, fournira des informations sur la façon de résoudre le problème.
Il comporte différentes fonctionnalités, décrites ci-dessous.
Contrôles de l'intégrité health-checks
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 inspectés dans la variable Console web JMX, sous org.apache.sling.healthcheck domaine.
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 :
Types de contrôle de l’intégrité health-check-types
Il existe deux types de contrôles de l’intégrité dans AEM 6 :
- Contrôles de l’intégrité individuels
- 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é. En haut de la page, vous trouverez un lien vers l’analyseur "Message du journal" dans la section Outils de diagnostic, qui vous permettra d’analyser plus en détail ces erreurs et de reconfigurer les enregistreurs.
A Contrôle d’intégrité composite est une vérification qui agrège les informations de plusieurs 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 ».
Procédure de création de contrôles de l’intégrité how-to-create-health-checks
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 creating-an-individual-health-check
La création d’un contrôle de l’intégrité individuel comprend deux étapes : implémentation 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 noeuds de 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é. Voir Documentation du contrôle de l’intégrité Sling pour plus d’informations.
Exemple de composant de contrôle de l’intégrité Sling, écrit avec des annotations de composant de service OSGi :
code language-java @Component(service = HealthCheck.class, property = { HealthCheck.NAME + "=Example Check", HealthCheck.TAGS + "=example", HealthCheck.TAGS + "=test", HealthCheck.MBEAN_NAME + "=exampleHealthCheckMBean" }) public class ExampleHealthCheck implements HealthCheck { @Override public Result execute() { // health check code } }note note NOTE La propriété MBEAN_NAMEdé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- Type :
String - Valeur :
granite/operations/components/mbean
- Type :
-
Nom :
resource- Type :
String - Valeur :
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
- Type :
note note NOTE 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/testnote note NOTE Assurez-vous que les propriétés ci-dessous du chemin d’accès /apps/settings/granite/operations/hcsont définies sur true :sling:configCollectionInheritsling:configPropertyInheritCela 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 creating-a-composite-health-check
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 noeud de configuration doit être ajouté, de la même manière que pour une vérification simple.
-
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é, 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 sera 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. Un nom significatif est recommandé.
- Balises (hc.tags) : balises de ce contrôle de l’intégrité. Si ce contrôle de l’intégrité composite est destiné à faire partie d’un autre contrôle de l’intégrité composite (dans une hiérarchie de contrôles de l’intégrité, par exemple), ajoutez les balises auxquelles ce contrôle composite est associé.
- Nom du MBean (hc.mbean.name) : Nom du MBean Mbean qui sera donné 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).
note note NOTE 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 noeud sera définie par la valeur de hc.mean.name dans la configuration OSGI.Si, par exemple, vous avez créé une configuration et défini la variable hc.mbean.name valeur à diskusage, les noeuds de configuration se présentent comme suit :
-
Nom :
Composite Health Check- Type :
nt:unstructured
- Type :
Avec les propriétés suivantes :
-
Nom :
sling:resourceType- Type :
String - Valeur :
granite/operations/components/mbean
- Type :
-
Nom :
resource- Type :
String - Valeur :
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
- Type :
note note NOTE 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 noeud 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. -
Contrôles de l’intégrité fournis avec AEM health-checks-provided-with-aem
Surveillance avec Nagios monitoring-with-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.
-
Configurez et installez Nagios sur le serveur de surveillance.
-
Installez ensuite Nagios Remote Plugin Executor (NRPE).
note note NOTE Pour plus d’informations sur l’installation de Nagios et NRPE sur votre système, consultez la section Documentation Nagios. -
Ajoutez une définition de l’hôte pour le serveur AEM. Pour ce faire, utilisez le gestionnaire de configuration de l’interface web de Nagios XI :
- Ouvrez un navigateur et pointez vers le serveur Nagios.
- Appuyez sur le bouton Configure dans le menu supérieur.
- Dans le volet de gauche, appuyez sur Gestionnaire de configuration principale sous Configuration avancée.
- Cliquez sur le lien Hôtes sous la section Surveillance.
- Ajoutez la définition de l’hôte :
Voici un exemple de fichier de configuration de l’hôte si vous utilisez Nagios Core :
code language-xml define host { address 192.168.0.5 max_check_attempts 3 check_period 24x7 check-command check-host-alive contacts admin notification_interval 60 notification_period 24x7 } -
Installez Nagios et NRPE sur le serveur AEM.
-
Installez le check_http_json sur les deux serveurs.
-
Définissez une commande de contrôle JSON générique sur les deux serveurs :
code language-xml define command{ command_name check_http_json-int command_line /usr/lib/nagios/plugins/check_http_json --user "$ARG1$" --pass "$ARG2$" -u 'https://$HOSTNAME$:$ARG3$/$ARG4$' -e '$ARG5$' -w '$ARG6$' -c '$ARG7$' } -
Ajoutez un service pour la mémoire utilisée sur le serveur AEM :
code language-xml define service { use generic-service host_name my.remote.host service_description AEM Author Used Memory check_command check_http_json-int!<cq-user>!<cq-password>!<cq-port>!system/sling/monitoring/mbeans/java/lang/Memory.infinity.json!{noname}.mbean:attributes.HeapMemoryUsage.mbean:attributes.used.mbean:value!<warn-threshold-in-bytes>!<critical-threshold-in-bytes> } -
Reportez-vous au tableau de bord Nagios du service que vous venez de créer :
Outils de diagnostic diagnosis-tools
Le tableau de bord des opérations donne également accès aux outils de diagnostic qui peuvent vous aider à trouver et à résoudre les causes profondes des avertissements provenant du tableau de bord du contrôle de l’intégrité, ainsi qu’à fournir des informations de débogage importantes aux opérateurs système.
Parmi ses principales caractéristiques :
- Un analyseur de messages de journal
- La possibilité d’accéder aux vidages de tas et de threads
- Requêtes 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 log-messages
Par défaut, l’interface utilisateur des messages du journal affiche tous les messages ERREUR. Si vous souhaitez afficher davantage de messages de journal, vous devez configurer un journal avec le niveau de journal 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 également que la modification des configurations de l’enregistreur se répercutera à l’avenir de l’enregistreur en mémoire. Les entrées déjà enregistrées et qui ne sont plus pertinentes ne sont pas supprimées, mais des entrées similaires ne seront plus enregistré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 la capture de tous les messages dont le niveau est égal ou supérieur à celui spécifié.
Exemples :
-
Si vous envisagez d’enregistrer tous les messages ERREUR, aucune configuration n’est nécessaire. Tous les messages ERROR sont capturés par défaut.
-
Si vous envisagez de capturer toutes les ERROR, WARN et INFO messages : le nom de l’enregistreur doit être défini sur : "root", et le niveau de journalisation à : INFO.
-
Si vous envisagez de capturer tous les messages provenant d’un certain package (par exemple com.adobe.granite), le nom de l’enregistreur doit être défini sur : "com.adobe.granite" et le niveau de journalisation à : DEBUG (cette opération capturera toutes les ERROR, WARN, INFO et DEBUG messages), 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 requêtes request-performance
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 précisément, les requêtes suivantes seront capturées :
- Demandes d’accès aux ressources sous
/content - Demandes d’accès aux ressources sous
/etc/design - Demandes comportant l’extension
".html"
La page affiche :
- Heure à laquelle la demande a été effectuée
- L’URL et la méthode de requête
- Durée en millisecondes
Par défaut, les 20 requêtes de page les plus lentes sont capturées, mais la limite peut être modifiée dans Configuration Manager.
Performance des requêtes query-performance
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 :
- Heure à laquelle la requête a été effectuée
- La langue de la requête
- Nombre d’envois de la requête.
- L’instruction de la requête
- Durée en millisecondes
Expliquer la requête explain-query
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 de l’optimisation de la requête consiste à comprendre comment 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, accédez à Outils - Opérations - Diagnostic dans l’écran de bienvenue AEM, puis cliquez sur Performances des requêtes et le passage à la fonction 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 vous avertit au sujet des requêtes pouvant être potentiellement lentes.
- Indique l’index Oak utilisé pour exécuter la requête.
- Affiche l’explication réelle du moteur de requête Oak.
- Fournit une liste de clics pour charger des requêtes lentes et populaires
Une fois que vous êtes dans l’interface utilisateur Expliquer la requête , il vous suffit de saisir la requête et d’appuyer sur la touche Expliquer button :
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.
Choisir le Inclure le temps d’exécution avant d’exécuter la requête, indique également le temps pendant lequel la requête a été exécutée, ce qui permet d’obtenir plus d’informations qui peuvent être utilisées pour optimiser les index pour votre application ou déploiement.
Gestionnaire d’index the-index-manager
Le gestionnaire d’index a pour objectif de faciliter la gestion des index, comme la maintenance des index ou l’affichage de leur état.
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 du tableau en saisissant 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 download-status-zip
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.
Télécharger l’image mémoire des threads download-thread-dump
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, telles que son état, le chargeur de classe et la trace de pile.
Télécharger l’image mémoire des segments de mémoire download-heap-dump
Vous avez également la possibilité de télécharger un instantané du segment de mémoire afin de l’analyser ultérieurement. Notez que cela déclenchera le téléchargement d’un fichier volumineux de l’ordre de plusieurs centaines de mégaoctets.
Tâches de maintenance automatisées automated-maintenance-tasks
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é. Les tâches peuvent également être exécutées manuellement à partir de l’interface.
Pour accéder à la page Maintenance du tableau de bord des opérations, vous devez accéder à la section Outils - Opérations - Tableau de bord - Maintenance à partir de l’écran de bienvenue AEM ou suivez directement 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 dans la fenêtre de maintenance hebdomadaire s’exécuteront entre 1h00 et 2h00 le samedi.
Vous pouvez également configurer les minutages en appuyant sur l’icône d’engrenage sur l’une des deux cartes de maintenance :
Nettoyage de la révision revision-clean-up
Pour plus d’informations sur l’exécution du nettoyage des révisions pour AEM 6.4, voir cet article dédié.
Nettoyage des binaires Lucene lucene-binaries-cleanup
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.
Bien que la tâche de maintenance ait été développée pour réduire les déchets de révision liés à Lucene, il existe des gains d’efficacité généraux lors de l’exécution de la tâche :
- L’exécution hebdomadaire de la tâche de nettoyage de la mémoire d’entrepôt de données se terminera plus rapidement.
- Elle peut également améliorer légèrement les performances générales d’AEM.
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.
Récupération de l’espace mémoire du magasin de données data-store-garbage-collection
Pour plus d’informations sur le nettoyage de la mémoire d’entrepôt de données, reportez-vous à la section dédiée page de documentation.
Purge des workflows workflow-purge
Il est possible également de purger les workflows à partir du tableau de bord de maintenance. Pour exécuter la tâche Purge du workflow, vous devez :
- Cliquez sur le bouton Période de maintenance hebdomadaire page.
- Dans la page suivante, cliquez sur le bouton Play dans le Purge des workflows carte.
Maintenance des journaux d’audit audit-log-maintenance
Pour en savoir plus sur la maintenance des journaux d’audit, consultez cette page de la documentation.
Purge de version version-purge
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.
Avec 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 la fenêtre de maintenance suivante s’ouvre.
- Manuellement : pour arrêter manuellement la tâche, sur la carte de maintenance Purge de version, cliquez sur l’icône Arrêter. Lors de la prochaine exécution, la tâche reprendra en toute sécurité.
Tâches de maintenance personnalisées custom-maintenance-tasks
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 :
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 d’un répertoire temporaire configurable qui ont été modifiés au cours des 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é à l’interface utilisateur du tableau de bord des opérations et peut être ajouté à l’une des plannings 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 noeud avec les valeurs des modes d’exécution qui doivent être principales pour cette tâche de maintenance.
Présentation du système system-overview
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.
Accès how-to-access
Pour accéder au tableau de bord de présentation du système, sélectionnez Outils > Opérations > Présentation du système.
Explication du tableau de bord de présentation du système system-overview-dashboard-explained
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 aucune information pertinente à afficher (par exemple, la sauvegarde n’est pas en cours, aucun contrôle de l’intégrité n’est critique), la section correspondante affichera 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.