To better understand our users and their usage of SonarQube, we want to start collecting some basic telemetry to answer the following questions:
- How many instances of SonarQube are live today?
- What version of SonarQube do they run?
- Which plugins are installed?
- What's the overall volume of code they cover? And what's the breakdown per language?
- The data sent by a SonarQube instance must not allow to identify a specific user (= anonymous information)
- This data must be sent on a fixed periodical basis
- Same basis for all SonarQube instances
- Data is sent weekly
- First check to eventually send data is done after 6 hours to avoid the test instances that are up for a short time (ex: developer box, ITs)
- In this first version, here's the data that will be sent:
- The server UUID
- The version of SonarQube
- The list of plugin keys along with their version
- The total number of projects
- The breakdown of projects per language (as we have on the "Projects" page)
- The total number of lines
- The breakdown of lines of code per language
- The number of (active - i.e. non deleted) users
- Feature must be enabled by default
- At startup, an INFO message must be logged to inform the user that anonymous data information will be collected (<= let's formulate it the same way we do in SonarLint)
- To opt-out, the user should be able to uncomment a property in the "sonar.properties" file (property for which we document precisely what anonymous data is sent)
- When we detect that this property is set to "true" at startup, we send a DELETE request to notify Chestnut about this opt-out, and we never send another new ping. Only the server uuid is sent in this case.
- If it turns out that this property is removed some day, then the telemetry must start again
- Note: this property should have no effect when a commercial plugin is installed (to be discussed)
- If sending the data fails for whatever reason (e.g.: missing proxy configuration), it should fail silently without displaying any error in the logs
- This data should be available in the "System Info" JSON document served by api/system/info
- We can simply add a new "Statistics" entry (at the same level as "System" or "Settings") that will contain the exact JSON document (payload field) that is sent to Chestnut with an enabled field
- SonarQube should rely on the same mechanism as SonarLint to send this anonymous data
- JSON data over HTTPS
- with user agent containing "SonarQube" (like for the UPC calls)
- pointing to Chestnut endpoint
Chestnut endpoint is: https://telemetry.sonarsource.com/sonarqube
- POST request is a "ping"
- DELETE request is the opt-out (only server UUID is sent in this case)
No need to pass a timestamp inside the document, Chestnut takes care to add one when it receives the document.
Expected document is: