Add feature tracking

[andresmgot]

What happened:

There are multiple features in ADX that due to its complexity or the very specific use cases they cover, are probably not used. The goal of this task is to add some feature tracking so we can get more information about how much these features are used. If they are not, we can remove them from the code base, if they are we can improve its UX so they are easier to use.

This is the list of things we can track:

Data source configuration:

• On-Behalf-Of authentication: This is currently a beta feature, quite difficult to setup and recently added.
• Query Timeout: This is a differen timeout than Grafana's data proxy. It's not useful if the data proxy is not configured with at least the same value.
• Dynamic caching and max cache age. This is quite easy to use and pretty valuable, but disabled by default. It would be interesting to see its usage so maybe we can default it to true.
• Data consistency: It's not clear what this does so I'd assume not that many people use it.
• Default editor value: Is there a point of using "Raw" by default?
• Managed schema: Seems a bit difficult to use, allowing just certain schema values.

Query editor:

• Format: I assume a big percentage of queries will use the "Time series" format, since it was the default but we lately changed it to "Table". Also there is a third format "ADX Time series" which we don't know how much it's used.
• Builder vs KQL editor: How much is the raw (KQL) editor used? Should we invest more on it?

[andresmgot]

Question here! Maybe @yaelleC you have an opinion:

For data source features (e.g. usage of on-behalf-of), we have two options:

• Track 1 event per data source load. This will give us data only about the data sources (e.g. 5% of data sources enable On-Behalf-Of authentication)
• Track 1 event per dashboard load. Similar to what we do with query features (e.g. query type). In this case, the focus will be on queries. For example: 5% queries uses a data source with On-Behalf-Of authentication.

I believe the second is more valuable since it's more relevant a data source used in 1k queries than one used just for one but maybe I am missing something.

Also, there is the issue of retrieving the data source information on the dashboard load, which should be possible but haven't tried yet.

[yaelleC]

Another option would be to add the event on save-and-test button. E.g 5% of datasources were set up using xyz feature (not sure how that would differ from your first option).

But I agree with you, having the data on dashboard loads to focus on volume might be more interesting, but I'm not sure either how possible it would be to get some feature information on dashboard load.
Which brings to mind a newbie / silly question: How is authentication handled on queries? Is it a one of (for the dashboard / datasource loaded in state)? or is it done for every query?

[andresmgot]

Another option would be to add the event on save-and-test button. E.g 5% of datasources were set up using xyz feature (not sure how that would differ from your first option).

The problem with that is that it would only take into account new data sources (or re-edited).

but I'm not sure either how possible it would be to get some feature information on dashboard load.

I can try that and see if it's possible 👍

How is authentication handled on queries? Is it a one of (for the dashboard / datasource loaded in state)? or is it done for every query?

The authentication between the browser and Grafana is handled by the grafana_session cookie. The authentication between the Grafana backend and the Azure API happens per query, before the first query, the backend retrieves an authorization token which is then cached and used while it's valid.

[yaelleC]

Nice thanks for all the info!

I agree with a next step to try and figure out if we can get the info on dashboard load, thanks!