Skip to main content

Repository: Nexus Repository 2 Logging Guide

Updated

Nexus application logging uses SLF4J and Logback internally.

Nexus Repository 2 officially sunsetted June 30, 2025. Visit my.sonatype.com for archived documentation. Migrate to Sonatype Nexus Repository 3 as soon as possible.

Adjusting Nexus Repostory 2 Logging

There are two methods of adjusting standard Nexus Repository 2 logging verbosity.

  1. Using the Nexus Repository 2 Logging UI ( preferred )
  2. Editing Logback configuration files directly

Using the Nexus Repository 2 Logging UI

Go to Administration -> Logging.

This option allows both viewing and adjusting Nexus Repository 2 logs. Nexus Repository 2.7 completely revamped the user interface. 

In Nexus Repository 2.6 and earlier, there was only a very simplified UI that can adjust the ROOT logger level only. Viewing log files was done under Administration -> System Files.

Editing Logback Configuration Directly

Sometimes you may not be able to access the Nexus User interface to change the logging level or view logs. or perhaps you do not like the default log rotation settings. In these cases there is a limited set of files you can modify directly.

Nexus should automatically pick up log file edits within 60 seconds without restarting Nexus.

logback-overrides.xml

Nexus Repository 2.7+ added a new logback configuration file called logback-overrides.xml.

The loggers configured in the user interface are persisted into sonatype-work/nexus/conf/logback-overrides.xml and override any logging levels configured in other logback-*.xml files. Manual changes to this file will give you access to edit the configuration in the user interface at a later time and also ensure that the values you configure take precedence.

You can do things like:

  • add new loggers
  • adjust logger levels
  • change pattern layouts
  • adjust log rotation

Refer to the Logback Documentation for details.

logback.properties

Nexus Repository 2.6 and earlier administrators can us this file to change the ROOT Logger level.

Edit sonatype-work/nexus/conf/logback.properties, change

root.level=INFO

to

root.level=DEBUG

and save the file. DEBUG can be one of any supported logger levels and will apply to all loggers without an explicit level defined.

logback-nexus.xml

Nexus Repository 2.6 and earlier administrators can edit sonatype-work/nexus/conf/logback-nexus.xml in the same way as logback-overrides.xml described above.

 

Log Files Location

Nexus Repository 2 Application Log

sonatype-work/nexus/logs

This is where the Nexus Repository 2 application logs are stored. The active log file here is nexus.log. Compressed log file rotation is also configured by default.

Logging Best Practice

Review your custom logging changes before upgrading

Nexus Repository 2 does not automatically try to migrate any of your custom logging changes made to logback-nexus.xml or logback-overrides.xml. It is assumed you changed these files for a specific reason and merging any new defaults into these files may not be appropriate.

Occasionally we will make changes to the logging configuration defaults to better reflect typical use cases of Nexus Repository 2. You are encouraged to review and compare your current logging configuration with the shipped default configuration before upgrading and making appropriate changes yourself to keep these in line.

Include complete thread ids Nexus Repository log lines (Nexus 2.4.x and earlier)

In versions of Nexus Repository prior to 2.5, the default log configuration of Nexus Repository prints only a truncated thread id for each log statement. This can make it impossible to distinguish between some logging statements from different threads. We fixed that so that a full thread id is printed. if you are running Nexus Repository older than 2.5, then you can also make this change manually. Here's how:

Edit sonatype-work/nexus/conf/logback-nexus.xml. Replace

${appender.pattern}

with

%4d{yyyy-MM-dd HH:mm:ss} %-5p [%thread] %X{userId} %c - %m%n

Then save the file. Now within 60 seconds, Nexus will start printing the full thread id.

Include the Requested Path in the Complete Thread ID

Assuming you have ensured the complete thread id is now being included in Nexus log statements ( see above ), it is also a good idea to have Jetty include the requested path in the thread id as well. This is extremely helpful in keeping track of what is actually being requested for each thread, at the cost of some additional log file size.

    <!-- enable request path as part of thread id -->
    <logger name="org.eclipse.jetty.server.AbstractHttpConnection" level="DEBUG" />

Don't Run Too Long at DEBUG levels

Nexus can generate a large amount of DEBUG logging in active servers. Unless advised by Sonatype Support or you are trying to diagnose a problem, do not leave Nexus in DEBUG logging mode for long periods of time.

Feature Specific Loggers

You can enable detailed logging for specific loggers to help debug at a low level the decisions Nexus is making. Use this technique when all other understanding fails or you are asked by Sonatype Support.

Note:You should also make sure the full thread id is printed in the appender pattern as described in this article. Monitor the output of any of these specific log changes to make sure you are satisfied the verbosity is acceptable.

Outbound Request Headers

Outbound requests from Nexus use Apache HTTP Client 4+. Often it is useful to print these outbound request HTTP header values in the Nexus log to debug problems. The below logger levels do this.

    <logger name="org.apache.http" level="DEBUG" />
    <logger name="org.apache.http.wire" level="ERROR" />

Security - Checking Request Authorization

 <logger name="org.sonatype.security.authorization.ExceptionCatchingModularRealmAuthorizer" level="TRACE" />

This trace logger will print a line per AuthorizingRealm, for every privilege needed to access the requested resource as a given user and if access was granted. For example, lines such as these:

jvm 1    | 2014-08-06 14:14:10,642-0300 TRACE [qtp1589148679-98] admin org.sonatype.security.authorization.ExceptionCatchingModularRealmAuthorizer - Realm: XmlAuthorizingRealm user: admin has permission: nexus:status:read
jvm 1    | 2014-08-06 14:14:10,642-0300 TRACE [qtp1589148679-99] developer org.sonatype.security.authorization.ExceptionCatchingModularRealmAuthorizer - Realm: XmlAuthorizingRealm user: developer does NOT have permission: nexus:status:read

Verbose Security

    <logger name="org.sonatype.security" level="TRACE" />
    <logger name="org.sonatype.nexus.security" level="TRACE" />
    <logger name="org.sonatype.nexus.jsecurity" level="TRACE" />
    <logger name="org.sonatype.nexus.proxy.access" level="TRACE" />
    <logger name="org.apache.shiro" level="TRACE" />
    <!-- enable request path as part of thread id -->
    <logger name="org.eclipse.jetty.server.AbstractHttpConnection" level="DEBUG" />

SNAPSHOT Removal Details

The Remove SNAPSHOT from Repository task relies on a worker to do the removals. You can configure the logger of this component to get details about what it is removing.

<!-- monitor actual snapshot removals -->
<logger name="org.sonatype.nexus.maven.tasks.DefaultSnapshotRemover" level="DEBUG />

Mail Sending

  <logger name="javax.mail" level="DEBUG" />
  <logger name="javax.activation" level="DEBUG" />
  <logger name="com.sun.mail" level="DEBUG" />
  <logger name="org.sonatype.nexus.email" level="DEBUG" />
  <logger name="org.sonatype.micromailer" level="DEBUG" />

LDAP

  <logger name="org.sonatype.security.ldap" level="DEBUG" />
  <logger name="com.sonatype.security.ldap" level="DEBUG" />
  <logger name="org.sonatype.nexus.security.ldap" level="DEBUG" />

Transport (HTTP/Proxy Repository)

<logger name="org.sonatype.nexus.apachehttpclient" level="DEBUG" />
<logger name="org.sonatype.nexus.proxy" level="DEBUG" />

NuGet

<logger name="com.sonatype.nexus.plugins.nuget" level="DEBUG" />

Yum

<logger name="org.sonatype.nexus.yum.internal.task.CommandLineExecutor" level="DEBUG" />

Smart Proxy Messaging

Add this logger on the subscriber side, this will show messages received from the master.

<logger name="com.sonatype.nexus.plugins.smartproxy.event.internal.handler" level="DEBUG" />

Add this logger on the publishing side, this will show messages sent by the master.

<logger name="com.sonatype.nexus.plugins.smartproxy.event.internal.EventPublisherImpl" level="DEBUG" />

 

Low-level JMX/RMI Debugging

You may need to also add these to <nexus_app_dir>/conf/logback.xml to get complete coverage.

  <logger name="org.eclipse.jetty.jmx" level="DEBUG" />
  <logger name="javax.management" level="TRACE" />
  <logger name="sun.rmi" level="TRACE" />

Adding the system property via the wrapper.conf wrapper.java.additional.4=-Djava.rmi.server.logCalls=true can reveal some more logging.

Java Service Wrapper (JSW) Logging

For Nexus Repository 2 bundle distributions only ( not trial installer ), Nexus Repository 2 uses JSW to launch the Nexus Repository 2 application. JSW has it's own logging files and configuration.

JSW Log Configuration

JSW has log rotation configured via  <nexus_install_dir>/bin/jsw/conf/wrapper.conf properties - therefore you may notice rotated log files ending with a number named similarly to wrapper.log.1

Wrapper Log File

<nexus_install_dir>/logs

This location contains the Java Service Wrapper (JSW) log files. The active log file name is wrapper.log. It contains:

  • every log statement that can be produced from launching and running Nexus Repository 2 (superset)
  • at startup,restart especially, a few additional logging statements more than the Nexus Repository 2 application logs
  • log statements written by JSW itself directly, like those when JSW is put in DEBUG mode
  • stderr output, like that from any triggered thread dumps
  • information about JSW controlled restarts, forced process kills

 

Related articles