Exemples d’analyse de request.log | AEM

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

Table des matières

A. Introduction

• Format de request.log

B. Étapes de préparation

1. Nettoyage des données
2. Temps redémarré
3. Nombre d'accès par heure
4. Traitement simultané maximal
5. Partage d’un fichier journal
6. Fusionner les enregistrements de requête et les enregistrements de réponse

C. Exemples d’analyses

1. Les accès les plus lourds
2. Accès à la réponse manquante
3. Accès lents
4. Données de série temporelle du temps de réponse
5. Minimum, moyenne, médiane, temps de réponse maximal
6. Nombre d’accès par période
7. Nombre d’états de réponse par période
8. URL les plus fréquentes
9. access.log enregistrements pour un request.log record

D. Conclusion

A. Introduction

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.

B. Étapes de préparation

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

C. Exemples d'analyse

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.

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.

Ressources Business.Adobe.com