Support for additional panel types in dashboard schema definition
Problem Statement
We are working to add additional chart types to GitLab, and we therefore need a way to define which type you want for a given chart. We can start with adding this support in YML based definition and database schema, and then add the option in the UI when we build the chart designer: https://gitlab.com/gitlab-org/gitlab-ee/issues/4452
Also - we know additional teams at GitLab are also thinking about dashboards, and it would be great to build a framework which multiple teams can leverage, as well as users mixing and matching panel types.
Proposal
We should add the concept of a panel
to the dashboard framework, which would define a single entity like a chart. Some chart types may have slightly different require fields, and so we could add these as their own panel. We could also extend this in the future to offer panel types for things like pipelines or other pieces of data.
To accomplish this, we should slightly alter and extend the existing YML definition to support additional panel types.
- We should rename the existing entity called
metrics:
topanels:
. Since the YML file is only defined internally for now, we can simply swap in this release. - Add the field
panelType
to the YML spec for a given chart, with an value for each panel type we want to support: areaChart, heatMap, singleValue, etc. This field should be optional, with a default to an area chart if nothing else is set.
Note that we may have to further extend the schema if there are any unique fields for a given chart type, but that can be done on an as needed basis.
Example
Currently our YAML looks something like this:
- group: Response Metrics (NGINX Ingress)
priority: 10
metrics:
- title: "Throughput"
...
- title: "Latency"
...
- group: System Metrics (Kubernetes)
priority: 5
metrics:
- title:
...
Future format is defined in: https://gitlab.com/gitlab-org/gitlab-ce/issues/60383
MVC proposal
In the interest of iteration, gitlab-org/monitor/general#16 (closed) was created to tackle the whole feature in smaller chunks, for this issue I'd like to propose shipping just one additional panel type, the single_stat
chart type being the simplest one to manage, considering that a prometheus query is also needed to make sure the new chart type works as expected.