[Dashboard] Adds dashboard collector for byValue panels

[crob611]

This PR adds a telemetry collector for dashboard, specifically focusing on by value panels

Collector will fetch all of the dashboard saved objects and then loops through their panels to count up by value panels for visualization and lens.

This is not intended to be the final solution for handling byValue telemetry, but rather just a stop gap for 7.11 while we figure out how to handle the problem across Kibana as a whole.

To test this, you can go to /api/stats?extended=true on your instance to see everything that is generated from a telemetry run. Look for the usage.dashboard key to see the dashboard specific values this introduces.

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 0b6c37d

Metrics [docs]

Distributable file count

id	before	after	diff
default	47138	47900	+762
oss	27530	27532	+2

History

• 💔 Build #94236 failed 85a608b
• 💔 Build #94221 failed 7ac5260

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[poffdeluxe]

This looks good to me. I tested this out and was able to see it count by-value embeddables in my dashboards

[ThomThomson]

This works great! I was able to see accurate counts of all of the by value panels in the stats url. Additionally, the parsing of dashboard panels for Lens & Visualize looks good to me.

Just out of curiosity, what is the latest thinking on running migrations on outdated dashboard panels before collecting telemetry on them? Will they be considered malformed and skipped? If so, this could result in some fluctuations in the number of by value panels when users update because the migrations will only be run ad hoc when the dashboard loads on the front end.

[crob611]

@ThomThomson That's a good question.

Currently, there is nothing that is going to happen to migrate anything so there could still be the out of date panels. Can you think of any scenarios where this might cause issues? I tried to make the Lens/Visualization Panel types extremely optional to protect against anything out of date that's really misshapen. Those would just be skipped.

The persistable state service provides a migrate method, so once this moves to be run against that, perhaps we can run the migrations at that time to make sure that everything is up to date as well, but I'll talk about that with the embeddable teams as we discuss how to make use of persistable state service for this telemetry stuff.

[Bamieh]

Using DYNAMIC_KEY is not ideal since we'll have a rough time exploring and mapping this data on the cluster. LGTM since this is a stop-gap solution but lets try to address this collector early on in 7.12 if possbile

[crob611]

@Bamieh Understood. I used that to match the existing visualizations and lens structures.

This should be addressed in 7.12 once we figure out how to handle nested embeddables on a large scale. Thanks!

[ThomThomson]

Can you think of any scenarios where this might cause issues?

The only scenario I can think of would be if the telemetry is run on a dashboard after a breaking change, but before the dashboard has been loaded / migrated on the front end. Then the telemetry could potentially return 0 by value panels, which could skew the stats. It's a long shot but still something to consider.

The persistable state service provides a migrate method, so once this moves to be run against that, perhaps we can run the migrations at that time to make sure that everything is up to date as well, but I'll talk about that with the embeddable teams as we discuss how to make use of persistable state service for this telemetry stuff.

This sounds promising. Hopefully this is how it will be handled once the persistable state service is implemented. I anticipate that the migration code would be moved to common, and run both ad hoc on dashboard load, and before a migration is run. Seems to me that this would fix the above rare issue.

Edit

Meant to also add that this PR is absolutely good as a stop-gap and that we will very likely not run into the above scenario.

[crob611]

@ThomThomson Right. But, this should hopefully only have to stick around for maybe 1 or 2 releases, so I think we're good running with it for now.