Exemples d’analyse request.log | AEM

Le fichier request.log de Adobe Experience Manager (AEM) est une source d’informations riche, notamment en termes de temps de réponse, ce qui est essentiel pour analyser les problèmes de performances. Cet article fournit plusieurs exemples pour illustrer ce point.

Description description

Environnement

Experience Manager 6.5

Problème/Symptômes

Le request.log Adobe Experience Manager (AEM) contient diverses informations utiles, telles que le temps de réponse, pour analyser les problèmes de performances. Vous trouverez ci-dessous une liste d’exemples d’analyse utilisant des commandes Linux (y compris certaines commandes externes telles que 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. Présentation

B. Étapes de préparation

C. Exemples d’analyse

D Conclusion

A. Présentation

Format de request.log :

Par défaut, AEM 6.5 génère des request.log au format suivant. En raison d’une limitation du système, les lignes de commande de cet article s’affichent sous la 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 ».

Demander l’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 requête, la méthode de requête et l’URL.

Enregistrement de réponse :

Lorsqu’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’identifiant de requête, le code d’état, Content-Type et le temps de réponse (en millisecondes).

Recherchez le manuel correspondant dans ​ 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 journaux.

La première commande sed supprime un espace supplémentaire dans le type de contenu des enregistrements de réponse, afin d’éviter une séparation incorrecte des champs avec des espaces. 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 avec un espace blanc au lieu du signe deux-points.

Étape 2. Heure de redémarrage

Le redémarrage d’AEM et l’installation d’un pack de services réinitialisent l’identifiant de requête de request.log. Les enregistrements de requête avec ID = 0 de requête indiquent qu’il peut y avoir ce type d’opération.

Dans l’exemple ci-dessus, les identifiants de requête ont été réinitialisés à 0 aux :08: 13 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 du serveur d’AEM.

Par défaut, le nombre maximal de connexions simultanées pour Jetty dans AEM est défini sur 200. Il y a un retard dans la libération du socket après avoir terminé la réponse. Lorsque le nombre de traitements simultanés dépasse environ 170, il devient incapable d’accepter de nouvelles demandes.

Étape 5. Partagez un fichier journal

L’ID de requête de request.log est réinitialisé au redémarrage d’AEM ou lors de l’installation d’un pack de services. 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 la taille du fichier traité en même temps, divisez le request.log à l’aide des enregistrements de requête avec le ID = 0 de requête.

É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 identifiant de requête permet de déterminer plus facilement le moment où les problèmes de performances ont commencé. Ce fichier journal fusionné sera utilisé dans les exemples ultérieurs.

La dernière commande sed ajoute une réponse factice aux enregistrements de requête 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 elles sont insignifiantes, car elles ne font généralement pas l’objet d’une 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ède à la réponse manquante

Extraire les accès sans 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 les accès à ceux qui ont pris plus de 100 secondes.

Exemple 4. Données de série temporelle du temps de réponse

Il est utile de n’extraire que la date et l’heure et le temps de réponse des données pour créer des graphiques.

L’omission des accès qui ont répondu immédiatement rend les données plus efficaces. L’exemple suivant extrait les accès qui ont pris plus d’une seconde.

Exemple 5. Temps de réponse minimal, moyen, médian et 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 influence le résultat.

Exemple 6. Nombre d'accès par période

Comptez le nombre d’accès par tranche de 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 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 de statuts de réponse par période

Créez un tableau du nombre de chaque statut de réponse par tranche de dix minutes avec la commande datamash.

Exemple 8. URL les plus fréquentes

Imprimez les trois principales URL qui ont été consultées le plus souvent toutes les dix minutes.

Exemple 9. enregistrements access.log pour un enregistrement request.log

Rechercher access.log enregistrements correspondant à un ID de demande spécifique.

Si plusieurs accès à la même URL ont eu lieu au même moment, le résultat affiche plusieurs enregistrements de access.log pour un seul identifiant de requête.

D Conclusion

Les exemples de cet article doivent 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. Veuillez les ajuster en fonction des commandes installées dans votre environnement.