Support Features
Nexus Repository provides several features that allow you to ensure your server is configured correctly and provides you with tools to investigate details about the configuration. This information can be useful for troubleshooting and support activities.
All support features are available in the Support group of the Administration menu in the main menu section.
Logging
Logging and the log viewer are available to those with the nx-all privilege under Administration → Support → Logging. Here, you can configure the level of logging for Nexus Repository and all plugins as well as inspect the current nexus, audit, cluster, and task logs.
Logging and Configuring Loggers
Note
When upgrading the repository manager, keep in mind that some loggers change between versions, so if you rely on specific loggers, you might have to reconfigure them.
The Logging feature view allows you to manage pre-configured loggers and create new ones.
 |
Note
The loggers configured in the user interface are persisted differently based on your setup.
In standard installations, loggers are stored in
$data-dir/etc/logback/logback-overrides.xml, overriding levels set in$install-dir/etc/logback/logback.xmland otherlogback-*files. If you need to edit a logging level in those files, edit the overrides file. This will give you access to edit the configuration in the user interface at a later stage and also ensure that the values you configure take precedence.For high-availability (HA) environments, logger configurations are stored in the
logging_overridestable for cluster-wide consistency.
Creating a Logger
From the Logging view, select the Create Logger button.
Provide the logger's name in the Logger Name field.
A logger's name typically corresponds to the Java package name used in the source code. Depending on your needs, you can inspect the source of Nexus Repository and its plugins to determine the related loggers.
Select the desired Logger Level.
Select Save.
Modifying a Logger's Logging Level
You can modify the log level for a configured logger by clicking on the row for the logger you wish to modify. This will bring you to a form where you can adjust the logging level using a Logger Level drop-down menu. Select the logging level you wish to use and then press the Update button to apply the change.
Warning
Logger levels are already set at optimal levels for normal operation. Setting loggers to more verbose levels may cause performance issues and any changes you make will take effect immediately. As a best practice, only adjust loggers to diagnose a specific problem and adjust them back to default levels after diagnosing that specific problem.
You can reset all default loggers to their default level by selecting the Reset to Default Levels button.
Note
Opting to reset all loggers to default levels will also delete custom loggers without underlying default logger configuration.
Logging Levels
The ROOT logger level controls how verbose the logging is in general. If set to DEBUG, logging will be very verbose, printing all log messages including debugging statements. If set to ERROR, logging will be far less verbose, only printing out a log statement if Nexus Repository encounters an error. INFO represents an intermediate amount of logging.
The following table describes the different logging levels.
Logging Level | Description |
|---|---|
Trace | This is the most detailed and verbose level of logging; it details every step of an event's code execution. |
Debug | This is the second-most detailed and verbose level of logging. It provides granular information to use for debugging and is too verbose for everyday use. |
Info | This level of logging provides information about events (e.g., an application entering a certain state, a user requesting authorization). This level is purely informative and can be ignored during normal operations. |
Warn | This level indicates that something unexpected occurred in the application, but the primary features continue to operate. It does not mean that the application failed, but it does indicate an issue that could disrupt one of the processes. |
Error | This level indicates that the application has encountered an issue preventing proper functionality. |
Deleting a Logger
Note
You can only delete custom loggers; to disable a default configured logger, set its logger level to OFF.
Use the Reset to default levels button to remove all custom loggers and reset all default loggers to their default level.
Commonly Adjusted Loggers by Feature Area
Nexus Repository default logger levels are intended to be verbose enough to help diagnose problems should you encounter them but quiet enough to not create overly large log files.
You can increase default log output verbosity when you need to gather more information about a problem or activity. In some cases, making a logger less verbose is justified to avoid spamming the application log with noisy messages.
Below are some of the loggers commonly adjusted by feature area. This is not a complete list and not all loggers are available in all versions of Nexus Repository.
Warning
Logger levels are already set at optimal levels for normal operation. Setting loggers to more verbose levels may cause performance issues. As a best practice, only adjust loggers to diagnose a specific problem and adjust them back to default levels after diagnosing that specific problem.
LDAP
Diagnose LDAP Queries and LDAP Server Connection Stack Traces by setting logger org.sonatype.nexus.ldap to DEBUG.
NuGet Repository Format
Set logger com.sonatype.nexus.repository.nuget to DEBUG to diagnose NuGet issues.
Webhooks
Diagnose outbound webhook payloads by setting org.sonatype.nexus.internal.webhooks to DEBUG.
Click to expand example log entries...
Example Log Entries
2016-12-14 17:09:43,902+0000 DEBUG [event-1-thread-2] admin org.sonatype.nexus.internal.webhooks.WebhookServiceImpl - Sending webhook request: WebhookRequest{id='9d80527e-8f7d-455a-a86b-191e9ac7ab9e', webhook=rm:repository:component, payload=org.sonatype.nexus.repository.webhooks.RepositoryComponentWebhook$RepositoryComponentWebhookPayload@2a89735b, url=http://requestb.in/abcd}
2016-12-14 17:09:44,420+0000 DEBUG [event-1-thread-2] admin org.sonatype.nexus.internal.webhooks.WebhookServiceImpl - Sending POST request: POST http://requestb.in/abcd HTTP/1.1
2016-12-14 17:09:44,736+0000 DEBUG [event-1-thread-3] admin org.sonatype.nexus.internal.webhooks.WebhookServiceImpl - Sending webhook request: WebhookRequest{id='29608664-b00b-4e1a-af3d-d0ced495fd57', webhook=rm:repository:component, payload=org.sonatype.nexus.repository.webhooks.RepositoryComponentWebhook$RepositoryComponentWebhookPayload@9ef9b8, url=http://requestb.in/abcd}
2016-12-14 17:09:44,760+0000 DEBUG [event-1-thread-3] admin org.sonatype.nexus.internal.webhooks.WebhookServiceImpl - Sending POST request: POST http://requestb.in/abcd HTTP/1.1
2016-12-14 17:09:44,765+0000 DEBUG [event-1-thread-2] admin org.sonatype.nexus.internal.webhooks.WebhookServiceImpl - Response status: HTTP/1.1 200 OK
2016-12-14 17:09:44,996+0000 DEBUG [event-1-thread-3] admin org.sonatype.nexus.internal.webhooks.WebhookServiceImpl - Response status: HTTP/1.1 200 OK
If there is an error in posting to the webhook url, then you will see an error like the following:
2016-12-14 16:40:34,567+0000 ERROR [event-1-thread-16] admin org.sonatype.nexus.internal.webhooks.WebhookServiceImpl - Failed to send webhook request: WebhookRequest{id='071b719e-683d-4fb4-a031-12e292ed4ec0', webhook=rm:repository:component, payload=org.sonatype.nexus.repository.webhooks.RepositoryComponentWebhook$RepositoryComponentWebhookPayload@76beefa6, url=http://requestb.in/abcd} org.apache.http.client.HttpResponseException: Not found
User Interface
Diagnose UI search inbound JSON payloads by setting logger org.sonatype.nexus.coreui.SearchComponent to DEBUG.
SAML
Log SAML-related activity by setting loggers com.sonatype.nexus.saml and org.keycloak.saml to DEBUG.
Log Viewer
Note
The Log Viewer is not available when using a High Availability deployment option.
Once logging is configured as desired, you can view and download logs via the user interface in the Logs page, which is available under Administration → Support → Logs.
 |
A table on this screen contains available nexus, audit, cluster, and task logs. Select a specific log file to view its contents. The image below shows an example nexus.log file displayed in the user interface.
 |
Here, you can set the rate at which the log refreshes by selecting an option from the Refresh Rate drop-down menu. Available options include Manual, Every 20 Seconds, Every Minute, Every 2 Minutes, or Every 5 Minutes. You can manually refresh by selecting the refresh icon (two arrows in a circle) in the top menu.
You can also use the Size drop-down menu to opt whether to display the last 25KB, 50KB, or 100KB.
In nexus.log, you can also add a custom text string into the log in order to create reference points in the log file for analysis. In the Marker to insert into the log text box, type the text you wish to insert; then, select the Insert button. This will insert the text at the bottom of the log file. The text will be surrounded by asterisks (*) to make it easy to find. If you do not insert any of your own custom text in the text box, the button will insert the word "MARK" by default.
Finally, you can download a copy of the logs from the server to your machine by pressing the Download button.
Status Checks
Sonatype Nexus Repository provides node health status information on the Status screen under Administration → Support → Status. You can also access this screen by selecting the health status icon that appears in the main header at all times. This icon will appear as a green circle with a checkmark when the system status is completely healthy. It will appear as a red circle with an "X" in it when there are status issues to examine.
Note
It may take a few minutes for the icon to change from the red "X" to the green check mark after you fix an issue or start a node.
If your deployment does not have clustered mode (for High Availability) enabled, you will see detailed information about your system status as described in the table below.
If you have clustered mode enabled to use one of our High Availability deployment options, you will first see a Node Status table listing each node by name along with any available error information.
Select a node from the Name column to view more detailed information about that node as described in the table below.
 |
Note
Note that if you are using one of our high-availability deployment options and a node is not shut down gracefully, this node will continue to appear in the listing for a few seconds.
Available information is described in the table below:
Status Check Name | Status Check Description | Error Explanation |
|---|---|---|
Available CPUs | Detects if the maximum available processors are below the minimum recommended threshold of four (See Sonatype Nexus Repository System Requirements). | If the maximum number of available processors is detected to be below four, then the status check will fail with a message reporting the number detected. |
Azure Blob Store PRO | Detects if you attempt to use an Azure blob store in a High Availability Clustering (HA-C) environment. | HA-C does not support Azure blob stores. |
Blob Stores Ready | Monitors for problems with the blob store's operability. | One or more blob stores are not fully operational. The status check message will contain information on the detected problems. |
Blob Stores Quota | When you set a soft quota, Nexus Repository monitors a blob store and raises an alert when it exceeds your configured constraint. All soft quotas' statuses are aggregated in this status check. | An alert on this status check does not impact the blob store in any way and just informs administrators that action should be taken. |
Coordinate Content Selectors | Detects if any content selectors contain coordinates. | Coordinate-based content selectors are deprecated. |
Default Admin Credentials | Reports on if the default administrator account with default credentials still exists in the Nexus Repository instance. | Fails if the default admin using default credentials exists in the Nexus Repository instance. |
DefaultRoleRealm | Monitors if Default Role Realm (as described in Realms) is properly configured. Will return healthy if it is either not enabled or properly configured to use an existing role. | Will return unhealthy if Default Role Realm is enabled but not configured, configured improperly, or if it is configured to use a role that does not exist. |
File Blob Stores Path | Detects file blob stores with path violations. | A file blob store must have a unique path, and may not be contained in a sub-directory of another blob store. This status check informs of file blob stores with violations. |
File Descriptors | Monitors file descriptor count. | The recommended file descriptor limit is 65536 (see System Requirements). This status check reports if your file descriptor count is exceeding the limit. |
Licensing PRO | Indicates if your Nexus Repository Pro license is properly configured and valid. | Informs you if your Pro license has expired. |
Lifecycle Phase | Shows if Nexus Repository is running in the final phase (TASKS) as expected. | If Nexus Repository is not running in the final phase (TASKS), the status check will show unhealthy and provide a message stating what phase Nexus Repository is running in. |
NuGet V2 repositories | Shows if you are using any NuGet V2 repositories. | Using NuGet V2 will not cause failures; however, we recommend you upgrade NuGet V2 repositories to NuGet V3. |
Read-Only Detector | Detects if the instance is in read-only mode. | Alerts when the instance is in read-only mode and provides the username of the account that enabled read-only mode along with any reason they may have provided. |
Recent Version PRO | Detects, based on the release date, whether you are running on a recently released Nexus Repository version. | Prompts you to upgrade to the most recent version of Nexus Repository to take advantage of new features and bug fixes. |
Scheduler | Provides a list of tasks that have triggers scheduled but no task configured. | Indicates that those tasks should be reconfigured to their desired specification. |
Scripting | Detects if scripting is enabled. | Fails if scripting is enabled. See our scripting support article for information on why we've disabled scripting in Nexus Repository 3 by default. |
Single Node per Database PRO | Detects multiple nodes. | Nexus Repository does not support having multiple nodes interact with an external database. |
Thread Deadlock Detector | Validates there are no thread deadlocks. | Indicates if any thread deadlocks exist and require troubleshooting. |
Transactions | Monitors an instance for any transaction with excessive retries in the last hour. | Excess transactions can indicate things like heavy cluster load, inter-node network issues, or something more malignant. A failing check here does not mandate any action but is a good first thing to check if you are experiencing abnormal symptoms in your instance. |
Prometheus
Nexus Repository exports its metrics in Prometheus format at /service/metrics/prometheus and requires Application privilege for Domainmetrics and action read(or use existing nx-metrics-all privilege) to access it. To consume those metrics you need to configure your Prometheus to scrape the data from Nexus Repository. For your convenience, we have provided an example Prometheus YAML file below that you can pass to Prometheus (remember to edit the target to point to your Nexus Repository instance; we used host.docker.internal:8081). Once you've got your Prometheus running, verify connectivity between Prometheus and Nexus Repository at http://your-prometheus-server/targets. You can stop here or you can go further and use Prometheus as a datasource for another tool like Grafana or Elastic.
Example Prometheus YAML
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. The default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
scrape_configs:
- job_name: "prometheus"
scrape_interval: 15s
scrape_timeout: 10s
metrics_path: /service/metrics/prometheus
scheme: http
basic_auth:
username: admin
password: admin
static_configs:
- targets: ["localhost:8081"]Support ZIP
Administrators can produce a support zip by navigating to Administration → Support → Support Zip. Submit the generated ZIP archive file to Sonatype support by email or attach it to a support ticket.
Sensitive password-related information is removed from the generated files. You are prompted to verify your repository manager account credentials when generating the support zip.
Non-High Availability Environment
To generate a support zip, select the cog icon in the top toolbar to open the administration interface.
Select the Support and then Support Zip sidebar menu options.
Select the contents you would like to include in your support zip; then select Create support Zip.
In non-highly available deployments, the support ZIP archive files are stored on the server under the $data-dir/downloads directory named as the time the file was generated.
When the support zip is generated, you are taken to a screen like the one below where you can see the name, size, and path of the zip file as well as download the file with the Download button.
High Availability Environment
In highly available deployments, each node may need to generate a support zip to properly diagnose issues. These zips are stored in the oldest shared blob store available to each node. You must have a blob store shared across all nodes to create a support zip.
A screenshot and details about creating a support zip in a High Availability (HA) environment are below; the experience varies slightly for non-HA environments.
 |
When a support zip has not been created for a given node, no zip created is displayed.
Follow the steps below to generate a new support zip:
To generate a support zip for a node, select the cog icon in the top toolbar to open the administration interface.
Select Support and then Support ZIP sidebar menu items.
Select the Generate new Zip button for the given node; alternatively, select the Generate Zip from all nodes button to generate new support zips for all nodes using the same settings you will configure in the next step
In the form that appears, select the contents to include.
Select the Create support zip button; support zip creation may take some time. A spinner appears while generation is taking place.
The spinner disappears when the support zip is ready. Refresh your screen to see the new download link(s) in the node cards if a previous support zip existed for a node. The new download link appears without refresh when no zip exists.
Select the link to download the zip file.
Locate the support zip in the shared blob store in the following path:
/shared_blob_store/content/directpath/nexus-blobstore-download-service
When using one of our high-availability deployment options and a node is not shut down gracefully, this node will continue to appear on the Support Zip page for a few seconds.
System Information
The System Information page under Administration → Support → System Information displays many configuration details.
If you have clustering enabled to use one of our high-availability deployment options, you can also use the drop-down menu at the top of the screen to select a specific node for which to view details.
Note
Note that if you are using one of our high-availability deployment options and a node is not shut down gracefully, this node will continue to appear on the System Information page for a few seconds.
 |
System information details include but are not limited to the following:
Details about the Sonatype Nexus Repository version you are using
Installed plugins
Install and work directory location
Application host and port
All system properties are known by the Java Virtual Machine running Sonatype Nexus Repository (e.g.,
java.runtime.nameandos.name)Operating system
Environment variables like
JAVA_HOMEorPATHDetails about runtime (e.g., processor, memory and threads, network connectors, storage file stores)
You can copy a subsection of the text from the panel or use the Download as JSON button to retrieve a JSON-formatted text file.
Access to this view can be granted with the nx-all privilege or the more granular nx-atlas privilege. Note, nx-atlas gives access to multiple pages. No privilege grants access to just this page without any others.