Available in Nexus Repository OSS and Nexus Repository Pro
Now that your repository manager instance is up and running, you need to ensure that it stays that way. Typically this is done on a number of levels and each organization and system administration team has its own preferences and tools.
In general you can monitor:
- hardware values like CPU, memory or diskspace utilization and many more
- operating system level values like processes running
- Java Virtual Machine specific values
- application specific value
For the hardware and operating system values, a large number of dedicated tools exist. Many of these tools can be configured to work with application-specific logs and other events. The following section discusses some of the available information in the repositiory manager. It can potentially be integrated into the usage of the more generic tools for monitoring, log capturing and analysis.
A host of information from the operating system, the Java Virtual Machine and the application itself is available via the Support Tools, which allow you to inspect the value directly in the user interface.
The repository manager logs events in the
sonatype-work/nexus/logs/nexus.log file. In addition a dedicated user
interface to configure and inspect the log is available. Further information about this interface can be found in
Section 6.10, “Logging”.
Logging all access requests to the repository manager allows you to gain a good understanding of the usage in your organization and the sources of these requests.
For example, you will be able to tell if the main load is due to a CI server cluster or from your developers, based on the IP numbers of the requests. You can also see the spread or requests and load across different time zones. Also available for review are the URLs , API calls, and features that are used in the repository manager.
Requests access logging is enabled by default in version 2.8 or higher and uses a performant and flexible LogBack
implementation with built-in log rotation already configured for 90 days of log file retention. The log is written
to the file
sonatype-work/nexus/logs/request.log and contains all requests and the username for authenticated
The configuration is located in
NEXUS_HOME/conf/logback-access.xml and can be changed to suit your
requirements. If you change the file, a restart of the repository manager is required for these changes to take
If you do not want to run access logging, you can disable it by commenting out the line
Older versions of Nexus Repository Manager Pro and Nexus Repository Manager OSS require different customization of the Jetty configuration files. Instructions for these customizations can be found on the support site.
JMX is a common tool for managing and monitoring Java applications with client software like the free VisualVM and many others available. It can be performed locally on the server as well as remotely.
The repository manager can be configured to support JMX by adding
to the list of
wrapper.app parameters in
NEXUS_HOME/bin/jsw/conf/wrapper.conf and set the parameters
jmx-host is the host name, or commonly the IP address, to remotely monitor the application using JMX from
another host and
jmx-port is the network port used for the connection. It is important to ensure that the port
is not blocked by any network setup, when connecting remotely. The value of 1099 is the default port used for JMX,
but any other available port can be used as well.
Versions older than 2.8 require different procedures, depending on the specific version.
Once the repository manager is restarted with JMX enabled you can inspect the running JVM in detail. Figure 3.13, “Overview of Nexus Repository Manager Monitored via JMX in VisualVM” and Figure 3.14, “CPU, Memory and Other Visualizations of Nexus Repository Manager Monitored via JMX in VisualVM” show some example screenshots of VisualVM connected to a repository manager instance running on localhost.
Figure 3.14. CPU, Memory and Other Visualizations of Nexus Repository Manager Monitored via JMX in VisualVM
Depending on the tool used to connect, a number of monitoring, analysis and troubleshooting actions can be performed. Please refer to the documentation about your specific tool for more information.
The analytics integration of Nexus Repository Manager allows you to gather a good understanding of your usage, since it enables the collection of event data in the repository manager. It collects non-sensitive information about how you are using the repository manager. It is useful to you from a compatibility perspective, since it gathers answers to questions such as what features are most important, where are users having difficulties, and what integrations/APIs are actively in use.
The collected information is limited to the use of the user interface and the REST API, the primary interaction points between your environment and the repository manager. Only the user interface navigation flows and REST endpoints being called are recorded. None of the request specific data (e.g., credentials or otherwise sensitive information) is ever captured.
You can enable the event logging in the Settings section of the Analytics tab available via Analytics menu item in the Administration menu in the left side navigation. Select the checkbox beside Enable analytics event collection and press the Save button.
You can choose to provide this data automatically to Sonatype by selecting the checkbox beside Enable automatic analytics event submission. It enables Sonatype to tailor the ongoing development of the product. Alternatively, you can submit the data manually or just use the gathered data for your own analysis only.
Once enabled all events logged can be inspected in the Events tab in the Analytics section displayed in Figure 3.15, “List of Events in the Analytics Tab”.
The list of events shows the Type and the Timestamp of the event as well as the User that triggered it and any Attributes. Each row has a + symbol in the first column that allows you to expand the row vertically. Each attribute will be expanded into a separate line allowing you to inspect all the information that is potentially submitted to Sonatype. The User value is replaced by a salted hash so that no username information is transmitted. The Anonymization Salt is automatically randomly generated by the repository manager and can optionally be configured in the Analytics: Collection capability manually. This administration area can additionally be used to change the random identifier for the repository manager instance.
More information about capabilities can be found in Section 6.6, “Accessing and Configuring Capabilities”.
If you desire to further inspect the data that is potentially submitted, you can select to download the file containing the JSON files in a zip archive by clicking the Export button above the events list and downloading the file. The Submit button can be used to manually submit the events to Sonatype.
When you select to automatically submit the analytics data, a scheduled task, named Automatically submit analytics events, is automatically created. This task is preconfigured to run at 1:00 AM every day. If desired the recurrence can be changed in the scheduled tasks administration area documented in Section 6.5, “Managing Scheduled Tasks”.
Sonatype values your input greatly and hopes you will activate the analytics feature and the automatic submission to allow us to ensure ongoing development is well aligned with your needs. In addition, we appreciate any further direct contact and feedback in person and look forward to hearing from you.