Repository Management with Nexus

3.11. Monitoring Nexus

Now that your Nexus 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 Nexus. 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 Nexus itself is available via the Support Tools, which allow you to inspect the value directly in the Nexus user interface.

3.11.1. General Logging

Nexus 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”.

3.11.2. Request Access Logging

Logging all access requests to Nexus allows you to gain a good understanding of the Nexus 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 Nexus

Requests access logging is enabled by default in Nexus 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.

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 Nexus 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

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

in bin/jsw/conf/wrapper.conf.

[Warning]

Older versions of Nexus require different customization of the Jetty configuration files. Instructions for these customizations can be found on the support site.

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

Nexus 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 access Nexus 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]

Nexus versions older than 2.8 require different procedures, depending on the specific version.

Once Nexus is restarted with JMX enabled you can inspect the running JVM in detail. Figure 3.13, “Overview of Nexus Monitored via JMX in VisualVM” and Figure 3.14, “CPU, Memory and Other Visualizations of Nexus Monitored via JMX in VisualVM” show some example screenshots of VisualVM connected to a Nexus instance running on localhost.

figs/web/monitoring-jmx-visualvm-overview.png

Figure 3.13. Overview of Nexus Monitored via JMX in VisualVM


figs/web/monitoring-jmx-visualvm-charts.png

Figure 3.14. CPU, Memory and Other Visualizations of Nexus 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.

3.11.4. Analytics

The analytics integration of Nexus allows you to gather a good understanding of your Nexus usage, since it enables the collection of event data in Nexus. It collects non-sensitive information about how you are using Nexus. 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 Nexus user interface and the Nexus REST API, the primary interaction points between your environment and Nexus. 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 Nexus 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”.

figs/web/analytics-events.png

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 Nexus 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 Nexus instance.

[Tip]

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

[Important]

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.