Usage Metrics
Note
Usage information does not currently display for High Availability (HA) deployments.
Usage metrics were originally introduced in release 3.61.0 but were revised in release 3.66.0. This topic covers the current implementation.
After logging in, Nexus Repository administrators are able to view usage statistics for a Sonatype Nexus Repository instance on their home screens.
Depending on whether you are using Sonatype Nexus Repository Pro or OSS, you will see the following information about this instance's usage:
Statistic | Shown for OSS/Pro | What it Means |
|---|---|---|
Total components | OSS & Pro | Total number of components in this Sonatype Nexus Repository instance across all repository formats. Calculated by counting each individual component record in the database (i.e., Docker components are aligned with Docker manifest tags. Layers are treated as assets and not considered in the component count. |
Unique logins | OSS only | Unique successful logins to this Sonatype Nexus Repository instance in the last 30 days. Calculated by identifying a userID and realm combination as an individual identifier. Only considers requests to the /repository/* urls. |
Peak requests per minute | OSS & Pro | Maximum number of requests per minute to repository endpoints for all repositories in this Sonatype Nexus Repository instance over the past 24 hours. Only considers requests to the /repository/* urls. |
Peak requests per day | OSS & Pro | Maximum number of requests per day to repository endpoints for all repositories in this Sonatype Nexus Repository instance over the past 30 days. Only considers requests to the /repository/* urls. |
Tip
Usage metrics data updates hourly at the top of the hour. Newly generated requests, users, or components will not be accounted for in real-time.
Usage Threshold Tracking for Embedded Databases
Deployments using an embedded database will also see usage threshold trackers under the provided metrics.
This tracker will alert you when your usage begins to approach a point at which your scale is exceeding recommendations for using an embedded database. This includes the following:
20,000 requests per day
100,000 components
While embedded databases are appropriate for disposable edge caches, test deployments, and low-concurrency team usage, an external PostgreSQL is recommended for more demanding use. This is particularly true for higher-concurrency use or in any situation where Nexus Repository is the system of record for the components that it stores.
Embedded databases require the system to enter read-only mode to get a consistent backup. Because of this, many deployments are not properly backed up, leading to extremely long recovery times in the case of an outage that requires restoring data.
Concurrent loads can lead to data integrity problems in OrientDB, which can make some or all components unavailable to users.
Pro customers on a PostgreSQL database will not see a threshold tracker. This is because you are already using a deployment model appropriate for your scale.
 |
What to do When Usage Exceeds Recommendations for Your Deployment
When your Sonatype Nexus Repository usage approaches recommended levels for your deployment, you should begin planning a migration to an architecture that is more appropriate for your needs. If your usage is exceeding recommended levels, you should migrate to a new deployment model as soon as possible.
To help you determine a deployment model that is appropriate for your needs, we’ve created a series of reference architectures for Nexus Repository. Each architecture provides system requirements and deployment strategies to handle specific ranges of anticipated total load. We also provide sizing instructions so that you can appropriately evaluate your total projected load.
Implementing an appropriate deployment model may require upgrading to Sonatype Nexus Repository Pro, migrating to a PostgreSQL database, and exploring options such as high availability, resiliency, and content replication.