Journaux courants

Le document décrit les entrées de journal courantes que vous voyez, ce qu’elles signifient et comment les traiter.

Avertissement GLOB

Exemple d’entrée de journal :

[Fri Jul 20 03:35:09 2018] [W] [pid 8300 (tid 139937910880384)] /etc/httpd/conf/publish-filters.any:5: Allowing requests with globs is considered unsafe. Please consult the documentation at 'https://www.adobe.com/go/docs_dispatcher_config_en' on how to use attributes method/url/query/protocol/path/selectors/extension/suffix instead.

Depuis la version 4.2.x du module répartiteur, il était déconseillé aux utilisateurs d’utiliser le type de correspondance suivant dans leur fichier de filtres :

/0041 { /type "allow" /glob "* *.css *"   }  ## enable css

Il est préférable d’utiliser la nouvelle syntaxe :

/0041 { /type "allow" /url "*.css" } ## enable css

Ou, mieux encore, de ne pas correspondre du tout à un appariement de caractères génériques :

/0041 { /type "allow" /extension "css" } ## enable css 

L’une ou l’autre des méthodes suggérées élimine ce message d’erreur des journaux.

Filtrer les refus

Remarque :

Ces entrées ne s’affichent pas toujours, même s’il y a des refus lorsque le niveau du journal est trop bas. Définissez les filtres sur Info ou déboguez pour vous assurer qu’ils refusent les requêtes.

Exemple d’entrée de journal :

[Fri Jul 20 17:25:48 2018] [D] [pid 25939 (tid 139937517123328)] Filter rejects: GET /libs/granite/core/content/login.html HTTP/1.1 

ou :

[Fri Jul 20 22:16:55 2018] [I] [pid 128803] "GET /system/console/" ! - 8ms [publishfarm/-] 
Attention :

Comprenez que les règles du répartiteur ont été définies pour filtrer cette requête.  Dans ce cas, la page sur laquelle l’utilisateur a tenté de se rendre a été volontairement refusée, nous ne modifions donc rien.

Si l’entrée de votre journal ressemble à ceci :

[Fri Jul 20 17:26:47 2018] [D] [pid 20051 (tid 139937517123328)] Filter rejects: GET /etc/designs/exampleco/fonts/montserrat-regular/montserrat-regular-webfont.eot HTTP/1.1 

Cela nous indique que notre fichier de conception .eot est bloqué. Nous souhaitons donc y remédier.

Par conséquent, nous devons examiner notre fichier de filtres et ajouter la ligne suivante pour permettre aux fichiers .eot de passer

/0011 { /type "allow" /method "GET" /extension 'eot' /path "/etc/designs/*" }

Cela permet au fichier de passer et empêche l’enregistrement dans le journal.

Si vous souhaitez voir ce qui est filtré, vous pouvez exécuter cette commande dans votre fichier journal :

$ grep "Filter rejects\|\!" /var/log/httpd/dispatcher.log | awk 'match($0, /\/.*\//, m){ print m[0] }' | awk '{ print $1 }'| sort | uniq -c | sort -rn 

Délais d’expiration du rendu

Exemple d’entrée de journal de délai d’expiration du socket :

[Fri Jul 20 22:31:15 2018] [W] [pid 3648] Unable to connect socket to 10.43.3.40:4502: Connection timed out 
[Fri Jul 20 22:31:15 2018] [W] [pid 3648] Unable to connect to any backend in farm authorfarm

Ce problème se produit lorsque vous avez configuré une adresse IP incorrecte dans la section des rendus de votre batterie.  Cette instance ou l’instance AEM a arrêté de répondre ou d’écouter et le répartiteur ne peut pas l’atteindre.

Vérifiez les règles de votre pare-feu et assurez-vous que l’instance AEM fonctionne correctement.

Exemple d’entrée de journal de délai d’expiration de la passerelle :

[Fri Jul 20 22:32:42 2018] [I] [pid 3648] "GET /favicon.ico" 502 - 54034ms [authorfarm/-] 
[Fri Jul 20 22:35:45 2018] [I] [pid 3648] "GET /favicon.ico" 503 - 54234ms [authorfarm/-]

Cela signifie que l’instance AEM disposait d’un socket ouvert qu’elle pouvait atteindre et qui a expiré avec la réponse.  Autrement dit, votre instance AEM était trop lente ou ne fonctionnait pas correctement et le répartiteur a atteint le délai d’expiration configuré dans la section de rendu de la batterie.  Augmentez le délai d’expiration ou assurez-vous que votre instance AEM fonctionne correctement.

Niveau de cache

Exemple d’entrée de journal :

[Fri Jul 20 23:00:19 2018] [I] [pid 16004 (tid 140134145820416)] Current cache hit ratio: 87.94 % 

Cela signifie que l’extraction à partir du niveau de rendu est mesurée par rapport à celle du cache.  Si vous souhaitez atteindre plus de 80 % du cache, suivez ces indications :

https://helpx.adobe.com/fr/experience-manager/kb/optimizing-the-dispatcher-cache.html

Ceci vous permettra d’augmenter ce nombre au maximum.

Remarque :

Même si vos paramètres de cache se trouvent dans le fichier de la batterie pour mettre en cache tout ce que vous purgez trop souvent ou de manière trop agressive, cela peut entraîner une baisse du pourcentage de réponses positives du cache.

Répertoire manquant

Exemple d’entrée de journal :

[Fri Jul 20 14:02:43 2018] [E] [pid 4728 (tid 140662586435328)] Unable to create parent directory /mnt/var/www/author/libs/dam/content/asseteditors/formitems.overlay.infinity.json/application: Not a directory

Ceci s’affiche généralement lorsqu’un élément est récupéré alors qu’un effacement du cache est en cours.

Les permissions de cette entrée ou du répertoire racine du document sont incorrectes ou le contexte de fichier SELinux sur le dossier empêche Apache de créer les nouveaux sous-répertoires nécessaires.

Pour les problèmes d’autorisation, vérifiez les autorisations de la racine du document et assurez-vous qu’elles ressemblent à ce qui suit :

dispatcher$ ls -la

URL Vanity introuvable

Exemple d’entrée de journal :

[Thu Sep 27 17:35:11 2018] [D] [pid 18936] Checking vanity URLs 
[Thu Sep 27 17:35:11 2018] [D] [pid 18936] Vanity URL file (/tmp/vanity_urls) not found, fetching... 
[Thu Sep 27 17:35:11 2018] [W] [pid 18936] Unable to fetch vanity URLs from 10.43.0.42:4503/libs/granite/dispatcher/content/vanityUrls.html: remote server returned: HTTP/1.1 404 Not Found

Cette erreur se produit lorsque vous avez configuré votre répartiteur de façon à ce qu’il utilise le filtre automatique dynamique pour autoriser les URL Vanity, mais que vous n’avez pas terminé la configuration en installant le package sur le rendu AEM.

Pour résoudre ce problème, installez le pack de fonctionnalités URL Vanity sur l’instance AEM et autorisez les utilisateurs anonymes à l’installer.  Plus d’informations ici

Une URL Vanity fonctionnelle correctement configurée ressemble à ceci :

[Thu Sep 27 17:40:29 2018] [D] [pid 21844] Checking vanity URLs 
[Thu Sep 27 17:40:29 2018] [D] [pid 21844] Vanity URL file (/tmp/vanity_urls) not found, fetching... 
[Thu Sep 27 17:40:29 2018] [D] [pid 21844] Loaded 18 vanity URLs from file /tmp/vanity_urls

Batterie manquante

Exemple d’entrée de journal :

[Wed Nov 13 17:17:26 2019] [W] [pid 19173:tid 140542738364160] No farm matches host 'we-retail.com', selected last farm 'publishfarm'

Cette erreur indique qu’à partir de tous les fichiers de batterie disponibles dans /etc/httpd/conf.dispatcher.d/enabled_farms/, aucune entrée correspondante n’a pu être trouvée dans la section /virtualhost.

Les fichiers de batterie correspondent au trafic basé sur le nom de domaine ou sur le chemin d’accès dans lequel la requête est arrivée.  Ils utilisent la correspondance GLOB. Si elle ne correspond pas, cela signifie que vous n’avez pas configuré correctement votre batterie, que vous avez mal saisi l’entrée dans la batterie ou que l’entrée est manquante.   Lorsque la batterie ne correspond à aucune entrée, elle utilise par défaut la dernière batterie incluse dans la pile des fichiers de batterie.  Dans cet exemple, c’est 999_ams_publish_farm.any qui porte le nom générique de la batterie de publication.

Voici un exemple de fichier de batterie /etc/httpd/conf.dispatcher.d/enabled_farms/300_weretail_publish_farm.any qui a été réduit pour mettre en évidence les parties en question.

Élément diffusé à partir de

Exemple d’entrée de journal :

[Tue Nov 26 16:41:34 2019] [I] [pid 9208 (tid 140112092391168)] "GET /content/we-retail/us/en.html" - + 24034ms [publishfarm/0]

La page a été récupérée via la méthode GET http pour le contenu /content/we-retail/us/en.html et l’opération a duré 24 034 millisecondes.  La partie sur laquelle nous voulons porter attention se trouve à la toute fin [publishfarm/0]. Vous constatez qu’elle ciblait et correspondait à la batterie de publication.  La requête a été récupérée à partir du rendu 0.  Cela signifie que cette page a dû être sollicitée à AEM, puis mise en cache.  Sollicitons à nouveau cette page et voyons comment le journal évolue.

Exemple d’entrée de journal :

[Tue Nov 26 16:42:16 2019] [I] [pid 9207 (tid 140112321234688)] "GET /content/we-retail/us/en.html" - - 1ms [publishfarm/-]

L’élément a de nouveau été sollicité et, comme vous pouvez le voir, il ciblait la même batterie de publication que la requête précédente.  Cette fois, l’entrée indique [publishfarm/-]. Le tiret à la fin indique qu’elle a été diffusée à partir du cache et qu’il n’était pas nécessaire de la récupérer à partir du rendu AEM.

Logo Adobe

Accéder à votre compte