Problem

Our DB console dashboards are maintained in the frontend code. There is friction for a DB-Eng to make adjustments to the dashboards, such as adding graphs, fixing up help texts, etc.
As a result of this friction, the dashboards are effectively unmaintained. The frontend teams that have the expertise to easily adjust these graphs have no expertise on the graphs, and so a hand-off is necessary for many changes.

For a personal example, I have spent so many hours looking at this graph, which mixes two time series that operate at vastly different scales (1-20 vs hundreds), effectively hiding the smaller timeseries:

I never went and fixed this. There are tons of things like this. Most metrics don't have help texts; we do have help texts in the backend and while they aren't perfect either, they exist. Nobody will transcribe them into the frontend.

Dashboards are poorly organized and for the same reasons as mentioned above, this isn't improving.

As a result of, I'm finding myself using custom charts most of the time when I'm running experiments.

(Partial) Solution

All charts should be powered by custom charts code from a definition served by a CRDB endpoint.
The custom charts are generated from a json definition (here's a sample) and if we added titles and legends and hover help texts to that, it seems like it could render the same thing as the main metric pages. The upshot could be that we could generate the json from the chart catalog that we have already, so we'd be very close to unifying with #54178, where the goal is (likely) to similarly create grafana dashboards from the same chart catalog.
I think in due time we'd also get better dashboards and ownership, since the friction to rearranging them would drop quite dramatically, as engineers could do it without touching the frontend.

cc @thtruo

Jira issue: CRDB-15382