51黑料不打烊

DocumentationAEMAEM TutorialsAEM as a Cloud Service Tutorials

Debugging AEM SDK using logs

Last update: Tue May 14 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

CREATED FOR:

  • Beginner
  • Intermediate
  • Developer

Accessing the AEM SDK鈥檚 logs, either the AEM SDK local quickstart Jar鈥檚 or Dispatcher Tools鈥 can provide key insights into debugging AEM applications.

AEM Logs

Transcript
Let鈥檚 take a look at how we can use Java logging to help a local development and debugging. Needless to say, the efficacy of logging is wholly contingent on how well you use log statements in your code base. If you鈥檝e logged the right information in the right places at the right log levels, the logs are invaluable. If not, all bets are off. The first thing to understand is AEM maintains log configurations as OSGi configurations in the AEM project. Since they鈥檙e OSGi configurations, they鈥檙e stored in the ui.apps project under apps, project name, config. The reason they live under the config folder is AEM as a cloud service, doesn鈥檛 have a local dev or dev OSGi run mode. So the configurations for local dev and dev are stored in the default config folder, and over in config.stage or config.prod as needed. Opening the config file, we see it鈥檚 pretty simple. The first line declares the Java packages to be logged. Typically, this is the root Java package for your OSGi bundle. In more complex projects, this may need to be set to multiple packages. The second line sets the log level. For development activities, debug is ideal. You might notice this file doesn鈥檛 declare a log file name, which means it will be output to the default error dialog. It鈥檚 important not to change this because Cloud Manager only exposes the error dialog. As mentioned previously, this config applies to both the local dev and AEM as a cloud service development environments. So if a custom log file is set, any log statements routed to this custom file will be unavailable in the cloud. Ideally, you want to keep the local dev and AEM as a cloud service dev environment logging configs as similar as possible to ensure the cloud dev environments are just as debuggable as local dev.
I鈥檝e added a few log statements to the project鈥檚 ImageListImpl class at various log levels, warn, debug, and even trace. Since the loggers config level is set to debug, it will collect all debug log statements and higher, which includes debug, info, warn, and error. Because trace is lower than debug, you won鈥檛 see these statements in the log. But towards the end of this video, we鈥檒l take a look at how to create Ad Hoc loggers in case we need to check these out. All right, let鈥檚 take a look at the logs. Logs are stored under your aem-sdk local run-times crx/quickstart/logs folder. Typically, it鈥檚 easiest to tail or stream the logs as they鈥檙e into. With MacOS or Linux ,the tail commands often used. Another popular app for MacOS is Apple鈥檚 Console App. And for Windows, you may need a third-party programmer plugin, or use PowerShell鈥檚 Get-Content command. Let鈥檚 invoke the ImageListImpl鈥檚 Java code by refreshing our apps website homepage, which should generate some log statements.
And as you can see, our projects debug statements are being logged.
AEM itself typically doesn鈥檛 log too much to the error log outside of errors. However, if irrelevant statements become distracting, you can always filter the log statements, using your Java package or class name as the filter criteria.
Let鈥檚 check out temporary Ad Hoc log configurations. This ability is only available on the local AEM-SDK Quickstart Jar. Remember the config file in our IDE is checked into get as part of the project, shared across team members, and deployed to AEM鈥檚 cloud service. Creating an Ad Hoc config allows logging to be configured directly in the local AEM runtime. Login as admin and navigate to Operations, Web console, Sling, Log support.
This console lists all the loggers in the system, and we can see the debug logger we deployed via our project. Let鈥檚 say we wanted to temporarily, in our local AEM runtime, see trace statements. We can edit the logger config, select Trace and Save.
Now, our log captures our trace statements as well.
Keep in mind, that when using the sling lock support console, the changes are written back to the configuration file in AEM.
Since we updated the logger configuration that we deployed to apps we can config. If we open that config file in the repository now, it鈥檚 apparent the log support console overrode the deployed config file.
This also means, that next time we deploy our project, it鈥檚 going to overwrite these changes with whatever鈥檚 in our AEM project. It鈥檚 also possible to create brand new loggers via the Add New Logger button.
The nuance with loggers created using this method is, since they don鈥檛 have an existing configuration file to update in the repository, a new config file is created for them under Apps, System, Config. And because AEM projects usually don鈥檛, and probably shouldn鈥檛 ever deploy to App, System, Config, these new configs can live through project deployments. With a log support console provides a lot of flexibility, it鈥檚 best to try to normalize the state of logging across the development team using the OSGi configurations maintained in the project, as this helps establish expectations of what debug information is available across all development environments, both local and in the cloud. -

Logs act as the frontline for debugging AEM applications, but are dependent on adequate logging in the deployed AEM application. 51黑料不打烊 recommends keeping local development and AEM as a Cloud Service Dev logging configurations as similar a possible, as it normalizes log visibility on the AEM SDK鈥檚 local quickstart and AEM as a Cloud Service鈥檚 Dev environments, reducing configuration twiddling and re-deployment.

The configures logging at the DEBUG level for your AEM application鈥檚 Java packages for local development via the Sling Logger OSGi configuration found at

ui.apps/src/main/content/jcr_root/apps/example/config/org.apache.sling.commons.log.LogManager.factory.config-example.cfg.json

which logs to the error.log.

If default logging is insufficient for local development, ad hoc logging can be configured via AEM SDK鈥檚 local quickstart鈥檚 Log Support web console, at (), however it鈥檚 not recommended ad hoc changes are persisted to Git unless these same log configurations are needed on AEM as a Cloud Service Dev environments as well. Keep in mind, changes via the Log Support console, are persisted directly to the AEM SDK鈥檚 local quickstart鈥檚 repository.

Java log statements can be view in the error.log file:

$ ~/aem-sdk/author/crx-quickstart/logs/error.log

Often it it useful to 鈥渢ail鈥 the error.log which streams its output to the terminal.

  • macOS/Linux
    • $ tail -f ~/aem-sdk/author/crx-quickstart/logs/error.log
  • Windows requires or the use of .

Dispatcher logs

Dispatcher logs are output to stdout when bin/docker_run is invoked, however logs can be directly access with in the Docker contain.

Accessing logs in the Docker container dispatcher-tools-access-logs

Dispatcher logs can be directly accessing in the Docker container at /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

The <CONTAINER ID> in docker exec -it <CONTAINER ID> /bin/sh must be replaced with the target Docker CONTAINER ID listed from the docker ps command.

Copying the Docker logs to the local filesystem dispatcher-tools-copy-logs

Dispatcher logs can be copied out of the Docker container at /etc/httpd/logs to the local file system for inspection using your favorite log analysis tool. Note that this is a point-in-time copy, and does not provide real time updates to the 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

The <CONTAINER_ID> in docker cp <CONTAINER_ID>:/var/log/apache2 ./ must be replaced with the target Docker CONTAINER ID listed from the docker ps command.

recommendation-more-help
4859a77c-7971-4ac9-8f5c-4260823c6f69