Du point de vue Experience Manager Assets, la surveillance devrait inclure l'observation et le rapports des processus et technologies suivants :
En règle générale, Experience Manager Assets peut être surveillé de deux manières, à savoir la surveillance en direct et la surveillance à long terme.
La surveillance en temps réel est conseillée lors de la phase de test des performances de votre développement ou en cas de charges élevées afin de comprendre les caractéristiques de performance de votre environnement. Typiquement, différents outils peuvent être utilisés pour la surveillance en temps réel. Voici quelques recommandations :
Visual VM : Visual VM vous permet de vue des informations détaillées sur la machine virtuelle Java, y compris l'utilisation du processeur et de la mémoire Java. En outre, il vous permet d’échantillonner et d’évaluer le code qui s’exécute sur un déploiement.
Top : Top est une commande Linux ouvrant un tableau de bord qui affiche des statistiques d’utilisation, notamment sur le processeur, la mémoire et les E/S. Vous obtenez ainsi une vue d’ensemble de ce qui se produit sur une instance.
Htop : Htop est un utilitaire qui permet de visualiser les processus de manière interactive. Il permet de disposer d’informations détaillées sur l’utilisation du processeur et de la mémoire en plus des informations fournies par Top. Htop peut être installé sur la plupart des systèmes Linux en utilisant yum install htop
ou apt-get install htop
.
Iotop : Iotop fournit un tableau de bord détaillé sur l’utilisation des disques en lecture/écriture. Il fournit des informations détaillées sur les processus qui utilisent les E/S sur les disques ainsi que le volume utilisé. Iotop peut être installé sur la plupart des systèmes Linux en utilisant yum install iotop
ou apt-get install iotop
.
Iftop : Iftop affiche des informations détaillées sur l’utilisation des ports ethernet et réseau. Iftop affiche des statistiques par canal de communication sur les entités utilisant Ethernet et la quantité de bande passante utilisée. Iftop peut être installé sur la plupart des systèmes Linux en utilisant yum install iftop
ou apt-get install iftop
.
Java Flight Recorder (JFR) : JFR est un outil Oracle pouvant être utilisé gratuitement dans les environnements qui ne sont pas destinés à la production. Pour plus d'informations, voir Comment utiliser l'enregistreur de vol Java pour diagnostiquer les problèmes d'exécution CQ.
Experience Manager error.log
fichier : Vous pouvez rechercher dans le Experience Manager error.log
fichier les détails des erreurs consignées dans le système. Utilisez la commande tail -F quickstart/logs/error.log
pour identifier les erreurs à rechercher.
Console d’administration des workflow : utilisez la console d’administration des workflow pour suivre les workflow en retard ou bloqués.
En règle générale, vous utilisez ces outils ensemble pour obtenir une idée complète des performances de votre déploiement Experience Manager.
Il s’agit d’outils standard qui ne sont pas pris en charge directement par Adobe. En outre, ils ne requièrent pas de licences supplémentaires.
Figure : Surveillance en direct à l'aide de l'outil Visual VM.
La surveillance à long terme d'un déploiement Experience Manager implique la surveillance à plus long terme des mêmes parties que celles qui sont surveillées en direct. Cela implique également de définir des alertes spécifiques à votre environnement.
Il existe plusieurs outils disponibles pour les journaux d'agrégats, par exemple Splunk™ et Elastic Search, Logstash et Kabana (ELK). Pour évaluer le temps de fonctionnement de votre déploiement Experience Manager, il est important que vous compreniez les événements de journaux spécifiques à votre système et que vous créiez des alertes en fonction de ces derniers. Une bonne connaissance de vos pratiques de développement et d'exploitation peut vous aider à mieux comprendre comment ajuster votre processus d'agrégation des journaux pour générer des alertes critiques.
La surveillance de l’environnement implique de surveiller les éléments suivants :
Des outils externes sont nécessaires, par exemple NewRelic™ et AppDynamics™ pour la surveillance de chaque élément. Vous pouvez, avec ces outils, définir des alertes spécifiques à votre système, par exemple, en cas d’utilisation intensive du système, pour la sauvegarde des workflow, en cas d’échec des contrôles de l’intégrité ou d’accès non authentifiés à votre site web. Adobe ne recommande pas un outil plutôt qu’un autre. Choisissez l’outil qui correspond le plus à vos besoins et utilisez-le pour la surveillance des éléments indiqués ici.
La surveillance des applications internes comprend la surveillance des composants d’application qui composent la pile Experience Manager, y compris la JVM, le référentiel de contenu et la surveillance par le biais du code d’application personnalisé créé sur la plate-forme. En général, elle se fait via les Mbeans JMX qui peuvent être contrôlés directement par de nombreuses et solutions de contrôle populaires telles que SolarWinds ™, HP OpenView™, Hyperic™, Zabbix™ et bien d’autres encore. Pour les systèmes ne prenant pas en charge une connexion directe avec JMX, vous pouvez écrire des scripts shell pour extraire les données JMX et les présenter à ces systèmes dans un format intelligible pour eux.
Par défaut, l’accès à distance aux Mbeans JMX n’est pas activé. Pour plus d’informations sur la surveillance via JMX, reportez-vous à la section Surveillance et gestion à l’aide de la technologie JMX.
Souvent, il faut une valeur de référence pour que la surveillance des statistiques soit efficace. Pour créer une valeur de référence, observez le système dans des conditions de fonctionnement normales pendant une période de temps prédéfinie, puis identifiez la mesure normale.
Surveillance JVM
Comme pour toute pile d'applications Java, Experience Manager dépend des ressources qui lui sont fournies par le biais de la machine virtuelle Java sous-jacente. Vous pouvez suivre l’état de ces ressources via les MXBeans de plateforme présentés par JVM. Pour plus d’informations sur les MXBeans, reportez-vous à la section Utilisation du serveur MBean de plateforme et des MXBeans de plateforme.
Voici quelques paramètres de base que vous pouvez surveiller pour la JVM :
Mémoire
MBean: lava.lang:type=Memory
/system/console/jmx/java.lang:type=Memory
Les informations fournies par ce bean sont exprimées en octets.
Threads
java.lang:type=Threading
/system/console/jmx/java.lang:type=Threading
MoniteurExperience Manager
Experience Manager présente également un ensemble de statistiques et d’opérations via JMX. Elles peuvent vous aider à évaluer l’état de santé du système et à identifier les éventuels problèmes avant qu’ils n’affectent les utilisateurs. Pour plus d’informations, voir documentation sur Experience Manager MBeans JMX.
Voici quelques paramètres de référence que vous pouvez surveiller pour Experience Manager:
Agents de réplication
MBean : com.adobe.granite.replication:type=agent,id=”<AGENT_NAME>”
URL : /system/console/jmx/com.adobe.granite.replication:type=agent,id=”<AGENT_NAME>"
Instances : un auteur et toutes les instances de publication (pour les agents de purge)
Seuil d’alarme : lorsque QueueBlocked
true
a la valeur ou lorsque la valeur de QueueNumEntries
est supérieure de 150 % à la valeur de référence.
Définition de l’alarme : une file d’attente est bloquée dans le système, indiquant que la cible de réplication n’est pas active ou qu’elle est hors d’atteinte. Très souvent, les problèmes d’infrastructure ou de réseau provoquent la mise en attente d’un nombre excessif d’entrées, ce qui peut affecter les performances du système.
Pour les paramètres MBean et URL, remplacez <AGENT_NAME>
par le nom de l'agent de réplication à surveiller.
Décompte du nombre de sessions
org.apache.jackrabbit.oak:id=7,name="OakRepository Statistics",type="RepositoryStats"
Contrôles de l’intégrité
Les contrôles de l’intégrité disponibles dans le tableau de bord des opérations ont des MBeans JMX correspondants pour la surveillance. Vous pouvez toutefois créer des contrôles personnalisés pour disposer de statistiques supplémentaires sur le système.
Voici plusieurs contrôles de l’intégrité prêts à l’emploi qui pourront vous être utiles :
Contrôles système
org.apache.sling.healthcheck:name=systemchecks,type=HealthCheck
/system/console/jmx/org.apache.sling.healthcheck:name=systemchecks,type=HealthCheck
File d’attente de réplication
org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck
/system/console/jmx/org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck
Performances des réponses
org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck
/system/console/jmx/org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck
Performances des requêtes
org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck
/system/console/jmx/org.apache.sling.healthcheck:name= queriesStatus,type=HealthCheck
Lots actifs
org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck
/system/console/jmx/org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck
Erreurs de journal
org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck
/system/console/jmx/org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck
Dans le processus de surveillance, si vous rencontrez des problèmes, voici quelques tâches de dépannage que vous pouvez exécuter pour résoudre des problèmes courants avec des déploiements Experience Manager :
Si vous utilisez TarMK, exécutez souvent la compression Tar. Pour plus d'informations, voir Maintenance du référentiel.
Vérifiez les journaux OutOfMemoryError
. Pour plus d’informations, reportez-vous à la section Analyse des problèmes de mémoire.
Consultez les journaux pour vérifier les références aux requêtes non indexées, ou aux parcours d’arborescence ou d’index. Ils signalent les requêtes non indexées ou indexées de façon inappropriée. Pour connaître les meilleures pratiques relatives à l’optimisation des performances de requête et d’indexation, voir Meilleures pratiques relatives aux requêtes et à l’indexation.
Utilisez la console d’administration des workflow pour vérifier que vos workflow se comportent comme prévu. Si possible, regroupez plusieurs workflow en un seul.
Revoyez la surveillance en temps réel et recherchez toute congestion supplémentaire ou recherchez les processus fortement consommateurs de certaines ressources spécifiques.
Examinez les points d'évacuation du réseau client et les points d'entrée vers le réseau de déploiement Experience Manager, y compris le répartiteur. Ce sont souvent des zones de congestion. Pour plus d’informations, reportez-vous à la section Considérations relatives aux ressources réseau.
Augmentez la taille de votre serveur Experience Manager. Votre déploiement Experience Manager peut ne pas être correctement dimensionné. Le service à la clientèle d’Adobe peut vous aider à déterminer si votre serveur est sous-dimensionné.
Consultez les fichiers access.log
et error.log
pour trouver les entrées situées autour du moment où le problème est survenu. Recherchez des indices susceptibles d’indiquer la présence d’anomalies au niveau du code personnalisé. Ajoutez-les à la liste d’événements à surveiller.