Datasource Plugins: Allow tracking for configuration usage #72650
Conversation
sarahzinger
requested review from
mckn,
joshhunt and
L-M-K-B
and removed request for
a team
sarahzinger
requested review from
yaelleC,
a team,
fridgepoet and
kevinwcyu
and removed request for
a team
| try { | ||
| await onUpdate({ ...dataSource }); | ||
| trackDsConfigUpdated({ item: 'success' }); | ||
| appEvents.publish(new DataSourceUpdatedSuccessfully()); | ||
| appEvents.publish(new DataSourceUpdatedSuccessfully(eventData)); |
There was a problem hiding this comment.
Does this generally publish the datasource configuration to anyone willing to listen?
There was a problem hiding this comment.
Yes, anyone would be able to listen to these events (at least with the current version of the appEvents).
There was a problem hiding this comment.
Yes, that's my understanding as well. I think any subscriber that is set up while the page is loaded can access this information, so it's important that we keep this to be non-sensitive data.
There was a problem hiding this comment.
@sarahzinger we should consider than from a privacy and security perspective we should simply not expose anything from a plugin to another regardless of what we consider sensitive data or not.
Something you can do is to keep the state of the configuration in your plugin datasource and listen to the event (that triggers without sending any kind of payload) to later flush the data you already have. Broadcasting the plugin configuration all over the application is dangerous.
An alternative way is exposing an API that allows only the specific plugin to subscribe to the specific event for its plugin id and won't allow any other plugin to subscribe to the specific event. Not by means of obfuscation but checks in place.
There was a problem hiding this comment.
Really great call outs @academo! Let me know what you think of this solution:
- publish events without any associated data
- then in the config component that has the state information we're looking for we subscribe and report there.
I think I was stuck thinking app event subscriptions had to happen in module.tsx since that's what I had seen us do elsewhere with other events, but in this case there's really no reason to!
There was a problem hiding this comment.
@sarahzinger can a second plugin (plugin B) subscribe to this event and start getting the configuration data for the plugin that saved the information (plugin A) ?
| try { | ||
| await onUpdate({ ...dataSource }); | ||
| trackDsConfigUpdated({ item: 'success' }); | ||
| appEvents.publish(new DataSourceUpdatedSuccessfully()); | ||
| appEvents.publish(new DataSourceUpdatedSuccessfully(eventData)); |
There was a problem hiding this comment.
Yes, anyone would be able to listen to these events (at least with the current version of the appEvents).
|
@mckn Yes! Our use case is that we often have configuration settings that we create for datasource plugins that we'd like to have more understanding of usage for. The example that is currently on our mind is that we're adding a new type of auth to the cloudwatch datasource. In Grafana Cloud right now we only support one type, but in OSS and other envs we have a range of auth types we support: Once we add the new auth type to that dropdown we'd like to better understand who and how many people are opting into the usage of this feature, as well as get a sense of it's overall performance. I had originally considered simply adding this auth type data to an existing reportInteraction call that we have here: My thought there though was that then auth type would show up for every interaction even for plugins that are not relevant, which seemed a bit wrong. It also seemed a bit like an unsustainable pattern for every plugin to start adding their various configurations to one big object in core grafana (even if that plugin is not in core grafana). My sense is that this is a fairly common use case where we have some kind of configuration settings in a datasource plugin that'd we'd love to learn more about that's fairly unique to that datasource plugin. Many of these configurations do not reveal any particular sensitive data. For example: let's look at a configuration page for cloudwatch: I'd love to know things like:
I think by manually setting the data we'd like to track in a property in the datasource's jsonData we can make this generic enough to track particular fields, but ensure that we're not passing along the entire jsonData object which may or may not contain some kind of sensitive information. Here's an example of how this might look in the plugin of us setting the property: |
- no need to publish data from plugin - add listeners in cloudwatch where state already is - ensure that calls are made at the test not the save to more accurately measure if it works.
There was a problem hiding this comment.
@sarahzinger much better with this approach thanks for doing the changes
Datasource Plugins: Allow tracking for configuration usage
…2650) Datasource Plugins: Allow tracking for configuration usage
…2650) Datasource Plugins: Allow tracking for configuration usage
What is this feature?
Sometimes we add new features/settings to a Datasource Plugin's configuration and we'd like to be able to track usage of these configuration settings.
This feature updates/adds to our Event Bus to publish when we save a datasource plugin.
Why do we need this feature?
We are working on improving our auth process for aws datasource plugins and it would be nice to collect some data about when and what auth type users are selecting in Grafana Cloud. Right now we generally only support the use of the "keys" auth type where users supply us with a set of long term credentials (although in other environments like OSS we support other methods as well). In the future we plan to offer more offerings here and would like to track their selection/usage.
To see an example of how plugins can use this feature, please see the Cloudwatch Example in this pr where we track auth type selection in the ConfigEditor on save.
I had originally explored adding this this auth type data directly to an existing event we have that fires off here. My challenge with that is I felt like I wanted to add datasource-specific information to that event and it felt a bit weird to publish a cloudwatch-specific property for all events.
Who is this feature for?
Datasource Plugin Developers who want to track save of a Datasource Configuration, and particular settings that may have been enabled/disabled
Please check that: