Closed majagrubic closed 1 year ago
Pinging @elastic/kibana-app (Team:KibanaApp)
I change above a few things. In addition, it will be good to capture Total number of new dashboard in the last 90 days and 30 days
regarding
Breakdown of number of visualizations on dashboard
Not sure how its best to be capture since its a per cluster collection and a cluster might have dozens of dashboards. Maybe max visualizations on a dashboard, min visualizations on a dashboard and average visualizations on a dashboard
Not sure if this is tracked via that issue, so wanted to drop this here: Once visualizations are embedded in Dashboards directly we'll lose the existing Telemetry on them. So we basically have two options:
Write telemetry collectors specifically for dashboard, that will load the dashboards and crap whatever information we need from them to report to telemetry.
Advantages:
Disadvantages:
This means we would need to write a system for dashboards that different embeddable implementations can plugin their own telemetry collectors. This would basically then get the embedded states and can gather telemetry data from them.
Advantages:
Disadvantages:
This is in my opinion a larger task we still need to discuss and I'd like to involve @stacey-gammon into this.
cc @timductive @flash1293
Once visualizations are embedded in Dashboards directly we'll lose the existing Telemetry on them.
Which telemetry will we lose? will it be all visualizations counters? Lens? or the dashboard counters?
Once visualizations are embedded in Dashboards directly we'll lose the existing Telemetry on them.
Which telemetry will we lose? will it be all visualizations counters? Lens? or the dashboard counters?
I'm sorry. I phrased this very poorly.
For visualizations embedded directly in dashboards no further telemetry would be collected (none of the current visualizations or lens telemetry). The existing telemetry will still be there, and for visualizations created in the library this telemetry will be collected as it was so far. But visualizations embedded inside a dashboard are "invisible" to those telemetry counters. That's why we need to solve this problem in one of the above ways, before merging that effort (or being okay without that telemetry, which I don't think we are).
We synced around that topic with the App Arch, Stacey and the telemetry team. Here is the summary:
getTelemetryData
interface that can be used to look up their data. Somehow all of this needs to be collected and stored.Closing this as we've added telemetry for Time to Visualize. We can re-open or open a new issue once we need more specific telemetry.
With the new time to visualize, improvements and simplifications of the dashboard, we want users to create their dashboard from within a dashboard.
Metrics we would like to collect
Currently collected
Other metrics we may want to consider