In the runbooks, we use grafonnet-lib to generate dashbards that are deployed to our grafana instance. However, the repository is archived and marked as deprecated. We should start using grafana/grafonnet instead.
I'm not sure if there are any incompatibilities between both libraries.
@rnienaber@swiskow I've labelled this as Category:Capacity Planning, because some capacity planning dashboards are also generated in this fashion. But I wonder if we should have a new Category:Metrics catalog that we (Scalability-Projections) own. We've been the de-facto people that work on this the catalog the most for capacity planning and SLIs. Reliability is our customer in terms of alerting, dashboards, and capacity planning. Would that make sense?
Bob Van Landuytchanged title from Switch dependecy from the deprecated grafonnet-lib to grafonnet to Switch dependency from the deprecated grafonnet-lib to grafonnet
changed title from Switch dependecy from the deprecated grafonnet-lib to grafonnet to Switch dependency from the deprecated grafonnet-lib to grafonnet
@nduff mentioned on Slack that the next update of Grafana starts complaining about the use of the old library. This means that very likely it will be disabled in the next major release.
@lmcandrew@swiskow I'm afraid this could be quite a bit of work because we haven't kept up with it very well. I think changing this to a project for which the output is that we're on the latest version and is kept up to date by renovate.
Just confirming that in the Grafana 11 release, the old angular js panels are disabled by default. There is still the ability to re-enable them by a feature toggle, but this change is almost certainly a per cursor to the fact they will be completely removed in the next major version
My gut feel is that treating these as two separate problems to be solved independently might be simpler than trying to solve them together.
For example, we could replace the graphs with the new Timeseries plugin from Grafonnet while mixing in some of the older components from the old Grafonnet-lib library and gradually move across.
My gut feel is that treating these as two separate problems to be solved independently might be simpler than trying to solve them together.
So, just to confirm, I've tested this approach and it does work.
We will be able to mix and match new Grafonnet panels embedded with old grafonnet-lib dashboards, and the dashboards render correctly (and use the new, non-deprecated Timeseries panels).
This means that we'll be able to slowly migrate the dashboards, component at a time, and not do a single big-bang migration. This will make the migration considerably easier than the alternative.
Having said that, it's still going to be a lot of work. The API of the new Grafonnet library is considerably different from the old library. This is going to be a major effort.
However, the good news is that we can tackle this one panel at a time: we don't need to do the whole change in one go.
We could just extract the panel types that need updating out to a shared lib to generate the panel. Then look to just go through each dashboard and re-point them to this. This would solve the immediate problem and allow us more time to look at abstracting some of these out into mixins.
We could just extract the panel types that need updating out to a shared lib to generate the panel. Then look to just go through each dashboard and re-point them to this. This would solve the immediate problem and allow us more time to look at abstracting some of these out into mixins.
Yup. I'm just relieved that this works (some previous attempts at mixing-and-matching failed to render so I was concerned that it might not be possible).
I'm considering adding new timeseries in gitlab-com/runbooks!7366 (merged), as this is a relatively standalone dashboard and would act as a good POC.
gitlab-com/runbooks!7366 (merged) is now in review, having replaced the old Graph plugin visualizations built with Grafonnet-lib with new Timeseries dashboards built with Grafonnet.
A few takeaways:
The generated Grafonnet docs are close to useless. They say a lot without saying much at all. It's very difficult to figure out how to structure things without finding an example to copy.
I think we definitely want to consider wrapping Grafonnet in our own easier-to-use libraries, rather than using it directly. Being a generated client, it's incredibly verbose, and as someone who doesn't work with the inner details of Grafana, difficult to know where to find a property or field.
The new Timeseries plugin works really nicely and will be a big improvement over the old Graph plugin.
I think we definitely want to consider wrapping Grafonnet in our own easier-to-use libraries, rather than using it directly. Being a generated client, it's incredibly verbose, and as someone who doesn't work with the inner details of Grafana, difficult to know where to find a property or field.
Isn't that what we were kind of doing with grafana/basic.libsonnet already. I think we could restart that somewhat but slightly keeping a mapping between what is in grafonnet.
I think the old angular implementation might be causing issues: On dashboards like the service overview dashboard, the timerange selection doesn't seem to work. While for one of the migrated dashboards it does.