Push Heartbeat dashboards to contrib

[justinkambic]

It's been expressed that there is some dismay amongst current users of Heartbeat dashboards that they're not going to be supported in 7.0. In the last planning meeting, we decided that it would be fairly low-effort to make them available in a new contrib repo for Uptime.

I figured it would be a good idea to track this in a dedicated issue here, especially because members of our team weren't able to make the call and we should have a centralized place to share thoughts on the topic.

[andrewvc]

I go back and forth on this.

On the one hand, supporting dashboards and the uptime app is a real burden. On the other hand, for users integrating heartbeat data into existing dashboards having the pre-built ones is a real benefit.

One thought, can we somehow bundle the dashboards in Kibana? Including them with the beat setup command has always seemed weird to me.

[tbragin]

@jamiesmith and I discussed it further, and here is how we think about it.

1. Is there value in providing out of the box dashboards that display Heartbeat data? Our key differentiator for Observability data sources, including Uptime, is that each data source "is just another index" in Elasticsearch. You can take the data we provide and report on it in an ad-hoc manner. You can mix and match data sources outside of curated UIs. With that in mind, providing default dashboards to get users going working with these data sources is of significant value -- and supports key workflows we are trying to promote as differentiating for our stack.

2. What should be on them? Previously our dashboards were quite complex. Since we did not have curated UIs, dashboards tried to mimic workflows in the current Uptime app. This no longer needs to be the case. We should consider how we can show off strengths of Kibana for data visualization and analysis for things outside the uptime app, without creating something that is hard to maintain.

3. Where we should provide them? From the user experience perspective, as long as the user can discover the dashboards and install them easily, that is all that matters. They don't need to live in Beats or Kibana short term, if we don't have good mechanisms for exposing default dashobards directly within the product. If we put them in a Github repo and link to them from the product (or even the docs), with some manual instructions on how to import them, that might be sufficient in the very short term. In fact, putting them in an uptime-contrib repo has a number of advantages as well -- we can iterate on them outside the release cycle, we can version them, we can encourage internal and community contributions, etc..

cc @makwarth

[tbragin]

We discussed this in a live meeting and concluded that putting dashboards in uptime-contrib in the short term makes most sense. This mirrors what we do in APM, and allows us to iterate. For now, we should put the 6.7 dashboard in there. For 7.0 dashboards, we'd still have to build them.

@jamiesmith @dov0211 It might be interesting to think through and suggest specific visualizations we may consider for Uptime dashboards going forward. What questions could they help the user answer (beyond the curated UI), that show off the power of Elasticsearch and Kibana for ad-hoc analytics and data visualizations. Perhaps you and other PMMs can make suggestions on what the dashboards may show going forward?

[andrewvc]

I've created the uptime-contrib repo initial commit. Could someone review it?

Also, any opposition to closing out this issue?