Depuração do SDK do AEM usando logs
Acessar os registros do SDK do AEM, o SDK do AEM local do quickstart Jar ou as Ferramentas do Dispatcher AEM podem fornecer informações importantes sobre como depurar aplicativos do.
Logs do AEM
Os registros atuam como linha de frente para depurar aplicativos de AEM, mas dependem do logon adequado no aplicativo AEM implantado. A Adobe recomenda manter as configurações de desenvolvimento local e de registro de desenvolvimento AEM as a Cloud Service o mais semelhantes possível, pois normaliza a visibilidade do registro no quickstart local do SDK do AEM e nos ambientes de desenvolvimento da AEM as a Cloud Service, reduzindo a oscilação e a reimplantação da configuração.
O Arquétipo de projeto do AEM configura o registro em log no nível DEBUG para os pacotes Java do aplicativo AEM para desenvolvimento local por meio da configuração OSGi do Sling Logger, encontrada em
ui.apps/src/main/content/jcr_root/apps/example/config/org.apache.sling.commons.log.LogManager.factory.config-example.cfg.json
que faz logon no error.log
.
Se o registro padrão for insuficiente para o desenvolvimento local, o registro ad hoc poderá ser configurado por meio do console da Web Suporte a logs do SDK local do AEM, em (/system/console/slinglog). No entanto, não é recomendado que as alterações ad hoc sejam mantidas no Git, a menos que essas mesmas configurações de registro também sejam necessárias em ambientes de desenvolvimento do AEM as a Cloud Service. Lembre-se, as alterações feitas por meio do console Log Support persistem diretamente no repositório do SDK do AEM local de início rápido.
As instruções de log Java podem ser exibidas no arquivo error.log
:
$ ~/aem-sdk/author/crx-quickstart/logs/error.log
Geralmente é útil para "tail" o error.log
que transmite sua saída para o terminal.
- macOS/Linux
$ tail -f ~/aem-sdk/author/crx-quickstart/logs/error.log
- O Windows requer aplicativos tail de terceiros ou o uso do comando Get-Content do Powershell.
Logs do Dispatcher
Os logs do Dispatcher são enviados para stdout quando bin/docker_run
é chamado. No entanto, os logs podem ser acessados diretamente com no Docker contém.
Acesso a logs no container do Docker dispatcher-tools-access-logs
Os logs do Dispatcher podem estar acessando diretamente no contêiner Docker em /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
O <CONTAINER ID>
em docker exec -it <CONTAINER ID> /bin/sh
deve ser substituído pela ID do CONTÊINER do Docker de destino listada no comando docker ps
.
Copiar os logs do Docker para o sistema de arquivos local dispatcher-tools-copy-logs
Os logs do Dispatcher podem ser copiados do contêiner do Docker em /etc/httpd/logs
para o sistema de arquivos local para inspeção usando sua ferramenta de análise de log favorita. Observe que essa é uma cópia point-in-time e não fornece atualizações em tempo real aos 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 cp -L <CONTAINER ID>:/etc/httpd/logs logs
$ cd logs
$ ls
dispatcher.log healthcheck_access_log httpd_access.log httpd_error.log
O <CONTAINER_ID>
em docker cp <CONTAINER_ID>:/var/log/apache2 ./
deve ser substituído pela ID do CONTÊINER do Docker de destino listada no comando docker ps
.