Depuração do AEM SDK usando logs
- Aplica-se a:
- Experience Manager as a Cloud Service
- Tópicos:
- Ferramentas de desenvolvedores
Criado para:
- Iniciante
- Intermediário
- Desenvolvedor
Ao acessar os registros do AEM SDK, o Jar de início rápido local do AEM SDK ou as Ferramentas do Dispatcher podem fornecer informações importantes sobre a depuração de aplicativos do AEM.
Logs do AEM
Os registros atuam como linha de frente para depurar aplicativos do AEM, mas dependem do logon adequado no aplicativo AEM implantado. A Adobe recomenda manter as configurações de desenvolvimento local e de registro em log do AEM as a Cloud Service Dev o mais semelhantes possível, pois normaliza a visibilidade do registro no ambiente de inicialização rápida local do AEM SDK e nos ambientes de desenvolvimento do AEM as a Cloud Service, reduzindo a confusã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 através 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 AEM SDK, 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 log 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 de Suporte ao registro são mantidas diretamente no repositório do SDK AEM.
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
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
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.