L’accès aux journaux du SDK AEM, que ce soit les fichiers Jar de démarrage rapide locaux du SDK AEM ou les outils de Dispatcher peuvent fournir des informations clés sur le débogage d’applications d’AEM.
Les journaux jouent le rôle de première ligne pour le débogage des applications AEM, mais dépendent d’une journalisation adéquate dans l’application AEM déployée. Adobe recommande de conserver les configurations de journalisation de développement local et d’AEM en tant que Cloud Service aussi similaires que possible, car cela normalise la visibilité du journal sur le démarrage rapide local du SDK AEM et l’ en tant qu’environnements de développement Cloud Service, ce qui réduit le délai de configuration et le redéploiement.
L’ archétype de projet AEM configure la journalisation au niveau DEBUG pour les packages Java de votre application AEM pour le développement local via la configuration OSGi de l’enregistreur Sling située à l’adresse
ui.apps/src/main/content/jcr_root/apps/example/config/org.apache.sling.commons.log.LogManager.factory.config-example.cfg.json
qui se connecte à error.log
.
Si la journalisation par défaut n’est pas suffisante pour le développement local, la journalisation ad hoc peut être configurée via la console web de prise en charge des journaux du SDK local, à l’adresse (/system/console/slinglog). Toutefois, les modifications ad hoc recommandées ne sont pas conservées dans Git, sauf si ces mêmes configurations de journal sont également nécessaires dans AEM en tant qu’environnements de développement Cloud Service. Gardez à l’esprit que les modifications effectuées via la console Prise en charge du journal sont conservées directement dans le référentiel de démarrage rapide local du SDK AEM.
Les instructions du journal Java peuvent être visualisées dans le fichier error.log
:
$ ~/aem-sdk/author/crx-quickstart/logs/error.log
Il est souvent utile de "tail" la error.log
qui diffuse sa sortie vers le terminal.
$ tail -f ~/aem-sdk/author/crx-quickstart/logs/error.log
Les journaux de Dispatcher sont sortis vers stdout lorsque bin/docker_run
est appelé, mais les journaux peuvent être directement accessibles avec dans le contenu Docker.
Les journaux de Dispatcher peuvent accéder directement dans le conteneur Docker à l’adresse /etc/httpd/logs
.
$ docker ps
# locate the CONTAINER ID associated with "adobe/aem-ethos/dispatcher-publisher" IMAGE
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
46127c9d7081 adobe/aem-ethos/dispatcher-publish:2.0.23 "/docker_entrypoint.…" 6 seconds ago Up 5 seconds 0.0.0.0:8080->80/tcp wonderful_merkle
$ docker exec -it <CONTAINER ID> /bin/sh
/ #
/ # cd /etc/httpd/logs
/ # ls
dispatcher.log healthcheck_access_log httpd_access.log httpd_error.log
# When finished viewing the logs files, exit the Docker container's shell
/# exit
Le <CONTAINER ID>
dans docker exec -it <CONTAINER ID> /bin/sh
doit être remplacé par l’identifiant Docker CONTAINER cible répertorié dans la docker ps
commande .
Les journaux de Dispatcher peuvent être copiés hors du conteneur Docker à l’adresse /etc/httpd/logs
vers le système de fichiers local pour inspection à l’aide de votre outil d’analyse de journal favori. Notez qu’il s’agit d’une copie ponctuelle qui ne fournit pas de mises à jour en temps réel des journaux.
$ docker ps
# locate the CONTAINER ID associated with "adobe/aem-ethos/dispatcher-publisher" IMAGE
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
46127c9d7081 adobe/aem-ethos/dispatcher-publish:2.0.23 "/docker_entrypoint.…" 6 seconds ago Up 5 seconds 0.0.0.0:8080->80/tcp wonderful_merkle
$ docker cp -L <CONTAINER ID>:/etc/httpd/logs logs
$ cd logs
$ ls
dispatcher.log healthcheck_access_log httpd_access.log httpd_error.log
Le <CONTAINER_ID>
dans docker cp <CONTAINER_ID>:/var/log/apache2 ./
doit être remplacé par l’identifiant Docker CONTAINER cible répertorié dans la docker ps
commande .