Dashboards, the crux of migrations

Dashboards are one of the most complicated objects in any observability platform. There are countless nuances, dependencies (like widget layout location), styling options, and dozens of other small yet important configurations to consider.

This makes migrating dashboards the potential crux of any migration process. If you fail to translate metrics, the dashboard won’t work. If you fail to translate the layout, it won't work either. Fail to translate queries? Nope. Don’t support the right configurations? You’ll get a messy blob of nonsense.

Migrating dashboards is quite similar to reorganizing the layout and furniture of your old house to a new one, matching your taste and personality while accommodating the constraints of the new space so the feng shui feels right.

It is inevitable that things will be different in any new house: room number and size, window directions, ceiling height, balcony placement, kitchen layout. The list goes on. This can cause a lot of frustration; assuming everything will fit exactly as before usually doesn’t work.

You can sketch up arrangements in AutoCAD, measure everything to scale, try different layouts, or even replace some furniture ahead of time. But all of that requires time, effort and expertise. You could even ask an AI app to organize it all for you, but the difference between that and reality usually leaves you disappointed.

Sometimes, a simple solution is all you need. An opinionated, deterministic algorithm can be enough to help our users escape their legacy vendor-locks.

Of course, we needed to support a variety of new features to enable smooth and seamless translation of other vendors’ dashboards to groundcover’s. But more often, we just needed to make opinionated decisions, how a specific widget or layout from one vendor should look in groundcover.

Here are a few interesting examples on how this process evolved:

• We’ve recently added support for our Data Widget to enable a much needed widget often used by customers in other vendors.
• We’ve even moved to a 24 column based layout in order to support translating x axis coordinates and widths from other 24 column based vendors, since translating 12 to 24 is fairly easy, but 24 to 12, less so.
  
  • If a widget is 3 out of 24 columns wide, how would you translate that? Choosing 2 or 4 would mean changing the width of all other widgets in that row, and potentially cascading changes across the entire dashboard
• Translating other vendors’ dashboard JSON structure is not easy, but it’s a finite task. Once the schema is defined, it can be repeated for every dashboard, achieving a deterministic translation algorithm.
• Migrating Variables was perhaps one of the hardest challenges. We had to understand what values are suggested in other vendors and reverse engineer how they are being calculated at scale to ensure users don’t experience discrepancies.
  
  • Most will agree that getting values like ‘node names‘ from metric A will give different results than getting it from metric B or even from all traces and logs.

A lot of thought has been put into the migration of this beast of an object called a dashboard. Our goal is not to make you worry that this is a complex job, it is simply to help you appreciate the work behind it a bit more.

Hopefully you can quickly go back to enjoy your new observability platform, without thinking about the effort that was put into building it and making it your own, due to the one time, quick and painless migration experience.