Importing
Five dashboards, all in English, all in Grafana’s shareable export format: the
datasource is a ${DS_...} placeholder and the __inputs block asks the
importer to choose their own.
| File | Panels | Store |
|---|---|---|
ghchronicle- | 152 | InfluxDB 3, queried with SQL |
ghchronicle- | 152 | Prometheus |
ghchronicle- | 152 | PostgreSQL or TimescaleDB, from the SQL sink |
ghchronicle- | 152 | Graphite, from the Graphite sink |
ghchronicle- | 152 | Elasticsearch or OpenSearch, from the Elasticsearch sink |
The five hold the same panels in the same order. What differs is how many of them the store behind each one can answer.

The account in that capture is the invented one every capture in this
documentation uses, acme and five repositories, described beside what the
panels show. Every section but the Overview
ships collapsed, which is why Lifetime is a header there.
Importing from the UI
Section titled “Importing from the UI”-
In Grafana, go to Dashboards, then New, then Import.
-
Upload the
ghchronicle-<store>.jsonfor the store you are using. -
Choose the datasource Grafana asks for.
The InfluxDB 3 datasource for the database the sink writes to, in SQL mode.
The Prometheus that scrapes ghchronicle’s exporter.
The PostgreSQL datasource for the database the SQL sink’s statements were piped into. TimescaleDB is the same datasource with the TimescaleDB switch on; the queries do not change.
The Graphite the sink writes to. The paths assume the default prefix,
github, and the functions need Graphite 1.1 or later.An Elasticsearch datasource whose index pattern is
ghchronicle-*and whose time field is@timestamp. One datasource serves every panel, because each target names its own index in the query. OpenSearch works through the same plugin.
Importing with the API
Section titled “Importing with the API”Name the input the file declares:
curl -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d "{\"dashboard\": $(cat ghchronicle-influxdb.json), \"inputs\": [ {\"name\":\"DS_INFLUXDB\",\"type\":\"datasource\",\"pluginId\":\"influxdb\",\"value\":\"<uid>\"}], \"overwrite\": true}" \ "$GRAFANA/api/dashboards/import"The inputs are DS_INFLUXDB (influxdb), DS_PROMETHEUS (prometheus),
DS_POSTGRES (grafana-postgresql-datasource), DS_GRAPHITE (graphite) and
DS_ELASTICSEARCH (elasticsearch).
The uid
Section titled “The uid”Each file carries a fixed uid (ghchronicle-<store>). That is deliberate for
a repository import, where a stable uid means a stable URL and a re-import
updates in place rather than duplicating. Importing two of these into one
Grafana is fine, because the uids differ per store and cannot collide.
They are generated, never hand-edited
Section titled “They are generated, never hand-edited”cmd/internal/dashboards holds one ordered list of sections and panels, and
every panel carries one query set per store. The generator picks one set and
emits the JSON, so every file has the same panels in the same places with the
same titles, and it refuses to write files whose layouts have drifted apart.
go run ./cmd/gen_dashboards # writes all five filesgo run ./cmd/gen_dashboards -check # writes nothing, fails if they are staleEdit cmd/internal/dashboards/sections_*.go, not the JSON. panels.go holds
the panel constructors it uses, query.go the query helpers for each store,
and stores.go only chooses a query set and a datasource.
Publishing to the Grafana directory
Section titled “Publishing to the Grafana directory”The files are already in the shape the directory requires: __inputs declares
the datasource the importer must choose, __requires names the Grafana version
and the plugin, and there is no id key, which the directory assigns on
publication.
Keep the listing names distinct, because five dashboards with the same title are indistinguishable in search results: “ghchronicle for InfluxDB”, “ghchronicle for Prometheus”, “ghchronicle for PostgreSQL and TimescaleDB”, “ghchronicle for Graphite”, “ghchronicle for Elasticsearch and OpenSearch”.
Publishing again against the same listing adds a revision rather than replacing it, so a regeneration that changes panels is a new revision of the same five listings, not five new listings.
That is what a reader needs to know. The step by step, with the listing names,
what each screenshot should show and what to do when a revision is rejected, is
a maintainer’s task and lives in
dashboards/PUBLISHING.md
in the repository.