Adoption Telemetry

[mpstefan]

As a maintainer of NGF
I want users to send telemetry containing non-personal information on their environment
So that I know is the popularity of our product has increased over time, after a feature, or after another event
And so that I can use basic cluster information to build a persona of our typical user
And so that I can use the relative popularity of our features to prioritize future development.

Background

After 1.0, the NKG project needs a way to track adoption beyond just downloads. Specifically, we want to look at number of deployments, cluster size, which features are being used, and other non-identifying attributes. This data can be used to validate that we are delivering the right features and which new features will have the biggest impact.

We also want users to be able to view the data they are sending to gain valuable insights for their own cluster. What will be available on initial release will depend on the implementation we choose to store the data.

Users need a way to opt-out of any and all telemetry they do not want to participate in.

Acceptance Criteria

• Telemetry is enabled by default, with an easy option to disable before and after NGF is installed.
• Sent telemetry is associated with an identifier that is unique for each cluster.
• Sent telemetry contains the data outlined here
• Documentation is created that outlines what telemetry is sent and how to disable it.

Tasks

Beta Give feedback

1. Telemetry Job (NGF) #1382
   area/telemetry refined size/small +3
   
2. Collect Cluster Identifier (NGF) #1303
   area/telemetry refined size/extra-small +3
   
3. Collect Deployment ID (NGF) #1304
   area/telemetry refined size/small +3
   
4. Collect Cluster Node Count (NGF) #1306
   area/telemetry refined size/extra-small +3
   
5. Collect Deployment Replica Count (NGF) #1307
   area/telemetry refined size/extra-small +3
   
6. Collect Deployed Platform and Kubernetes Version (NGF) #1308
   area/telemetry refined size/medium +3
   
7. Collect Project and Version (NGF) #1309
   area/telemetry refined size/extra-small stale +4
   
8. Collect Image Source (NGF) #1310
   area/telemetry refined size/small +3
   
9. Collect Count of Relevant Resources (NGF) #1312
   area/telemetry refined size/extra-small stale +4
   
10. Collect Deployment Flag Options (NGF) #1315
    area/telemetry refined size/small +3
    
11. Collect Installed Architecture (NGF) #1316
    area/telemetry refined size/small +3
    
12. Telemetry Exporter #1318
    2 of 2
    area/telemetry refined size/large +3
    
13. Mechanism to Opt Out of all Telemetry #1317
    area/telemetry refined size/small +3
    
14. Telemetry Documentation #1319
    area/telemetry documentation refined size/medium +4
    
15. Repository for Exporter Library #1374
    refined release-engineering size/small +3
    
16. Exporter Library Testing Pipeline #1375
    refined size/large tests +3
    
17. Integrate Telemetry Exporter with NGF Project #1377
    area/telemetry refined size/medium +3
    
18. Open Source Process for Telemetry Exporter #1521
    chore release-engineering +2
    
19. Review Resulting NGF Schema with Collection Team #1522
    chore refined +2
    
20. Tests Product Telemetry Performance #1561
    area/telemetry refined size/small tests +4
    
21. Automate Functional Tests in the Pipeline #1562
    area/telemetry refined size/medium tests +4
    
22. Enable Production Endpoint for Product Telemetry #1563
    area/telemetry refined size/small tests +4
    
23. Functional Test for Telemetry Exporter Integration #1640
    refined size/medium tests +3
    

For Discussion

• How can NGF work with NIC to build a common telemetry solution?
• Are there any elements above we want to avoid for the initial releases of telemetry due to excessive complexity?
• Should we include any of the following?
  • CRD Type count - for Ingress only?
  • Ingress Annotations
  • Deployment flag options
  • Installation method
• Is there any reason to use an OpenTelemetry Gateway at this stage?