Optional In-Product Analytics in Nexus Repository Manager OSS

Sonatype Nexus Repository
1

Sonatype is adding optional, in-product analytics to Nexus Repository OSS. This is an important change that will help us improve Repository, guiding the areas on which we focus our efforts. What’s working at scale? What might need some attention?

For some time, we’ve had a similar analytics program for Nexus Repository Pro that’s been enormously helpful. We’d now like to do the same for OSS.

Opting In

This is an optional program. As of version 3.31.0, the first time you sign in as an administrator, you’ll be asked if you’d like to participate.

If you agree, Nexus Repository OSS will periodically send Sonatype a data packet about feature usage and configuration choices. If you decline, analytics remains disabled (it’s off by default) and nothing gets sent to Sonatype.

If you change your mind, you can enable or disable analytics in the Capabilities administration section of the UI. If at any point you want to inspect what’s being sent to Sonatype, you can do so by visiting the /service/data/metrics endpoint on your Nexus Repository instance and looking for elements that start with “nexus.analytics.”

What Gets Sent?

This feature will collect anonymous, non-sensitive information about your use of Nexus Repository OSS.

By anonymous, we mean that we don’t collect information that would identify specific users: no usernames, passwords, emails, hostnames, or URLs of any kind.

By non-sensitive, we mean this feature doesn’t collect anything that could identify anything on which you or your teams are working. We don’t collect repository names, component names, coordinates or paths, the names or content of content selectors or routing rules, or paths of any kind—anything that might inadvertently contain information about your organization’s projects or the components you’re using.

What we do collect is high-level configuration choices, feature usage rates, internal error frequency, and performance information. Are you using the S3 blob store support? Is it working well? Is it fast enough? Have you switched to NuGet v3, or is v2 still everywhere?

We also collect a limited amount of environmental information to help us understand nuts and bolts details like memory and thread pool efficiency. This also helps us see how the great cloud migration is going and when it’s time to deepen our support for new environments where you are deploying Nexus Repository.

Feedback

Of course, while automated data is extremely useful, we continue to rely on feedback from developers and DevOps professionals like you to truly understand how you’re using Nexus Repository OSS and how well it meets your needs.

If you have questions or feedback about this program or any other aspect of Nexus Repository, please let us know on this post or in the Nexus Repository Manager category.

3 Likes
2

@msymons This post should provide some additional context re: your question here. Please let us know if you have any more questions!

1 Like
3

hello @mfrost

If we enable this capability will it generates tons of logs ? our main concerns is on storage part,
Also I hope it wont store any sensitive information related repo structure and user data, I have gone through this document In-Product Analytics Capability

still wants to reconfirm this,

Thanks in Advance.

4

Hi @sameer29nov! I did check with our Nexus Repo team about this - it is my understanding after speaking with them that the user can configure the logger to limit the size of their logs. We do not store any sensitive info related to repo structure or user data with the in-product analytics.

I hope this helps confirm things!

1 Like
5

For the record, I find the configuration and documentation of this capability confusing and vague. What’s the difference between “Enable this capability” and “Select this option to provide limited metrics about the sever to Sonatype.”? If enabled, does the second option end up providing more or less information to Sonatype? Is there any point in enabling this feature beyond sending data to Sonatype? Does it provide any internally useful analytics?

7

Hi Robert,

I believe “Select this option to provide limited metrics about the sever to Sonatype” is the text you see in the UI in order to opt in.

So, when you select that option, you are opting in and enabling the In-Product Analytics capability to provide us the anonymous information described in the docs linked above in comments. The capability will appear in the Capabilities list under Administration → System → Capabilities in the UI. So, selecting it does not provide less information than enabling the capability; selecting it is enabling the capability.

Capabilities are a specific Sonatype Nexus Repository feature (link to help docs on Capabilities). Apologies if the terminology was confusing.

1 Like
8

To add to Maura’s comment, here is a link to our help documentation on configuring loggers

9

@ldurant, if this is true then what’s the difference between unchecking “Enable this capability” and unchecking “Select this option to provide limited metrics about the sever to Sonatype.”? It sounds like they’re effectively the same end result even thought there are two different check boxes.

10

Ooh you’re inside of the manual “Create capability” workflow rather than the banner! I’m sorry, I misunderstood. (Edit: I thought you were looking at the banner that pops up on upgrade/install…which doesn’t even look like what you described, but rather just has a button that you click and it sets up the capability for you.)

So, what I THINK (but am double checking) is that “Enable this capability” will create the capability within the system, but you have to check the checkbox to actually make it active (like to fully agree I think). You’ll see an “Enable this capability” checkbox on every screen for creating any new capability manually through the Capabilities UI.

I can definitely see how that is confusing, and I’m not positive that that’s the behavior. Let me check with our Engineers and Design Team, and I can file a request to reevaluate this UI. If the behavior is as described above, it would probably make sense to make that checkbox some sort of official “agreement” type language.

What I do know for sure is that we haven’t created some method to modify what info is sent, so I can at least tell you that that checkbox is not some option to send less information.

11

Oh, I see. So the second checkbox sounds pretty much a legal “Opt In” agreement. Yes, the UX could be better here.