Exemples d’analyse de request.log | AEM

request.log de Adobe Experience Manager (AEM) est une source d’informations riche, notamment les temps de réponse, qui est essentielle pour l’analyse des problèmes de performances. Cet article fournit plusieurs exemples pour illustrer ce point.

Description description

Environnement

Experience Manager 6.5

Problème/Symptômes

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/

Résolution resolution

Table des matières

A. Introduction

B. Étapes de préparation

C. Exemples d’Analysis

D. Conclusion

A. Introduction

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 de request.log :

Dans cet article, une ligne avec "->" est appelée "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 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.

B. Étapes de préparation

Étape 1. Nettoyage des données

Avant de passer à l'analyse de request.log, il est important de normaliser les enregistrements de journal.

La première commande sed supprime un espace supplémentaire dans les enregistrements Content-Type des réponses, afin d’éviter une séparation de champs 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. Les enregistrements de requête avec la requête ID = 0 indiquent qu’il peut y avoir ce type d’opération.

Dans l’exemple ci-dessus, les ID de requête ont été réinitialisés à 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 de 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. Fractionner un fichier journal

L’ID de requête de request.log est réinitialisé au redémarrage d’AEM ou à l’installation d’un Service Pack. En raison de ce comportement, l’analyse peut être incorrecte lorsqu’un 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 l’ request.log à l’aide 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.

La dernière commande 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 :

C. Exemples d'analyse

Exemple 1. 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} par [ 0-9] {6} dans la commande grep pour réduire le nombre d’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 (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 Publish.

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 enregistrement request.log

Recherchez access.log pour les enregistrements qui correspondent à un ID 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 enregistrements access.log pour un seul ID de requête.

D. Conclusion

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.