Monitoring Nexus Repository 2

Nexus Repository 2

When your repository manager instance is installed 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 and diskspace utilization
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 repository 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.

General Logging

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 Logging.

Request Access 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 requests.

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 effect.

If you do not want to run access logging, you can disable it by commenting out the line in bin/jsw/conf/wrapper.conf.

wrapper.app.parameter.2=conf/jetty-requestlog.xml

Warning

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.

Using Java Management Extension (JMX)

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:

wrapper.app.parameter.3=./conf/jetty-jmx.xml

to the list of wrapper.app parameters in NEXUS_HOME/bin/jsw/conf/wrapper.conf and set the parameters jmx-host and jmx-port in NEXUS_HOME/conf/nexus.properties.

jmx-host=192.168.10.12
jmx-port=1099

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.

Warning

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.11, “Overview of Nexus Repository Manager Monitored via JMX in VisualVM” and Figure 3.12, “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.11. Overview of Nexus Repository Manager Monitored via JMX in VisualVM

Figure 3.12. 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.

Analytics

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.13, “List of Events in the Analytics Tab”.

Figure 3.13. 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.

Note

More information about capabilities can be found in 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 Managing Scheduled Tasks.