Experience Manager 6.5
Adobe Experience Manager (AEM) request.log
contient diverses informations utiles, telles que le temps de réponse, pour l’analyse des problèmes de performances. Voici une liste d’exemples d’analyse utilisant des commandes Linux (y compris certaines commandes externes comme ruby). [
1]
et datamash [
2]
).
Guides d’installation
[
1]
https://www.ruby-lang.org/en/documentation/installation/
[
2]
https://www.gnu.org/software/datamash/download/
A. Introduction
request.log
B. Étapes de préparation
C. Exemples d’analyses
access.log
enregistrements pour un request.log
recordD. Conclusion
Le format de request.log
AEM 6.5 génère request.log
au format suivant par défaut. En raison d’une limitation du système, les lignes de commande de cet article s’affichent sous forme d’images au lieu de texte brut.
Exemple d'un request.log
:
Dans cet article, une ligne contenant "->
" est appelé "enregistrement de requête". Une ligne avec "<
-" est un "enregistrement de réponse".
Demande d’enregistrement:
Lorsqu’une demande est reçue par AEM, un enregistrement de demande est consigné. Il contient la date et l’heure de réception, l’identifiant de la demande, la méthode de demande et l’URL.
Enregistrement de la réponse:
Lorsque AEM répond à une requête, un enregistrement de réponse est consigné. Il contient la date et l’heure de la réponse, l’ID de la requête, le code d’état, le type de contenu et le temps de réponse (en millisecondes).
Recherchez le manuel correspondant sur Interprétation de request.log.
Étape 1. Nettoyage des données
Avant de passer à l'analyse des request.log
, il est important de normaliser les enregistrements de journal.
Le premier sed
supprime un espace supplémentaire dans les enregistrements Content-Type des réponses, afin d’éviter une séparation de champ incorrecte avec l’espace blanc. La commande ruby (voir [
1]
ci-dessus pour installer Ruby) convertit le format de date en ISO 8601. La commande ruby sépare également la date et l’heure par un espace blanc au lieu d’un deux-points.
Étape 2. Temps redémarré
Le redémarrage d’AEM et d’une installation de Service Pack réinitialise l’ID de requête de request.log
. La requête enregistre avec la requête ID = 0
indique qu'il pourrait y avoir ce genre d'opérations.
Dans l’exemple ci-dessus, les ID de requête ont été réinitialisés sur 0 à 13.:08:49 et 13:26:13.
Étape 3. Nombre d'accès par heure
Comptez le nombre d'accès par heure et la période du request.log
.
Étape 4. Traitement simultané maximal
Le nombre de traitements simultanés permet de deviner la charge de serveur de l’AEM.
Par défaut, le nombre maximal de connexions simultanées pour Jetty dans AEM est défini sur 200. Il y a un délai dans la libération du socket après l’exécution de la réponse. Lorsque le nombre de traitements simultanés dépasse environ 170, il ne peut plus accepter de nouvelles requêtes.
Étape 5. Partage d’un fichier journal
L’ID de requête de request.log
est réinitialisé lorsque AEM redémarre ou qu’un Service Pack est installé. En raison de ce comportement, l’analyse peut être incorrecte lorsqu’une request.log
contient de telles opérations. Pour effectuer une analyse précise et réduire simultanément la taille du fichier géré, divisez la variable request.log
utilisation des enregistrements de requête avec la requête ID = 0
.
Étape 6. Fusionner les enregistrements de requête et les enregistrements de réponse
La fusion des enregistrements de requête et de réponse par ID de requête facilite l’identification des problèmes de performances qui ont commencé. Ce fichier journal fusionné sera utilisé dans les exemples suivants.
Le dernier sed
ajoute une réponse factice pour demander des enregistrements qui n’ont pas d’enregistrement de réponse correspondant. Il peut également y avoir des enregistrements de réponse sans enregistrements de requête. Mais ils sont ignorants car ils ne sont généralement pas un problème d'enquête.
Le fichier journal fusionné doit se présenter comme suit :
Exemple 1. Les accès les plus lourds
Triez le fichier journal fusionné par temps de réponse dans l’ordre décroissant, y compris les accès sans réponse.
Exemple 2. Accès à la réponse manquante
Extrayez les accès sans leurs enregistrements de réponse correspondants à l’aide du temps de réponse factice.
Si le délai de réception des accès sans réponse est corrélé à une augmentation de la charge du serveur, ces accès peuvent avoir déclenché des problèmes de performances.
Exemple 3. Accès lents
Extrayez les accès qui ont pris plus de 10 secondes.
Lorsque le nombre d’accès est trop élevé, remplacez [ 0-9] {5}
avec [ 0-9] {6}
dans le grep
pour réduire les accès qui ont pris plus de 100 secondes.
Exemple 4. Données de série temporelle du temps de réponse
L’extraction de l’horodatage et du temps de réponse des données est utile pour créer des graphiques.
Le fait d’omettre les accès qui ont répondu immédiatement rend les données plus efficaces. L’exemple suivant extrait l’accès qui a duré plus d’une seconde.
Exemple 5. Minimum, moyenne, médiane, temps de réponse maximal
L’exemple ci-dessus utilise la commande datamash (https://www.gnu.org/software/datamash/) pour le traitement statistique. Si le journal contient des accès sans réponse, la valeur factice influera sur le résultat.
Exemple 6. Nombre d’accès par période
Comptez le nombre d'accès par dix minutes. Le résultat permet de déterminer si un trafic important a provoqué un problème de performances.
L’exemple suivant montre comment réduire les données aux requêtes de POST uniquement. Un cas d’utilisation type consiste à déterminer s’il existe une concentration de création ou de réplication de contenu au niveau Publication.
Exemple 7. Nombre d’états de réponse par période
Créez un tableau du nombre de chaque état de réponse par dix minutes avec la commande datamash.
Exemple 8. URL les plus fréquentes
Imprimez les trois premières URL qui ont été consultées le plus souvent pendant dix minutes.
Exemple 9. access.log
enregistrements pour un request.log
record
Rechercher access.log
pour les enregistrements qui correspondent à un identifiant de requête spécifique.
Si plusieurs accès à la même URL se sont produits en même temps, le résultat affiche plusieurs access.log
des enregistrements pour un seul ID de requête.
Les exemples de cet article devraient vous aider à analyser vos problèmes de performances.
Les exemples répertoriés ont été testés sur CentOS 7.5 et Ubuntu 22.04LTS, mais ils peuvent ne pas fonctionner comme prévu en fonction de votre environnement, comme différentes versions ou variantes des commandes. Ajustez-les en fonction des commandes installées dans votre environnement.