dashboardcheck

Overview ¶

dashboardcheck verifies the Grafana dashboards the AutoFlow loadtest provisions: each file parses as JSON, carries the fields the file provisioner needs, and places every panel where it actually renders.

Grafana repairs a broken layout instead of rejecting it. Its grid compacts on load: panels that overlap are pushed down, and panels under a gap float up into it. Either way a stale gridPos renders as some unrelated section out of place, with no error anywhere. Provisioned dashboards are read-only in the UI, so the repaired layout is never written back and the file keeps drifting further from what it draws.

A dashboard also has to reach Grafana at all. The loadtest module names each file twice, once to embed it in the provisioning ConfigMap and once to mount it, so a file added to the directory but not to the module is checked here and provisioned nowhere. -provisioned-in points at that module so the two cannot drift apart.

The checks stand in for a schema because there is none to validate against: Grafana publishes CUE for the V2 dashboard schema only, and these files use the classic model.

Panel order is checked too, even though Grafana sorts by grid position on load and so renders any order correctly. Keeping the file in that same order is what makes a panel's place in it tell you where the panel lands, and which row owns it.

Queries and legends must not name an otel_scope_ label. The Prometheus exporter emits instrumentation-scope attributes under that prefix, and no component here is told apart by one anymore, so a query grouping on such a label silently collapses every component into one series.

encoding/json/v2 rather than v1, for two properties that matter on a 200 KiB file only ever edited by hand: it rejects duplicate object members, where v1 silently keeps the last one, and it reports a syntax error as a JSON pointer plus offset rather than "unexpected end of JSON input". It lands the package a Go release ahead of the go directive, hence the build constraint above.