Import-Fallen finden, bevor das Dashboard ausgeliefert wird.

22 Regeln über einen echten Parse des Dashboards: 7 Fehler, 11 Warnungen und 4 Hinweise. Die Fehler sind die, die ändern, was Grafana tut — eine Template-Variable, die nichts deklariert, ein ${DS_…}-Platzhalter ohne __inputs-Block, ein AngularJS-Panel, das auf Grafana 11–12 nichts rendert, zwei Panels mit derselben id, ein repeat über eine nicht existierende Variable, ein Panel ohne type und eine schemaVersion, die so alt ist, dass JSON und Rendering zwei verschiedene Dashboards sind. Die Warnungen sind die Portabilitäts- und Review-Probleme: fehlende uid, eine Datenbank-id in einer committeten Datei, eine über den Namen referenzierte Datasource, ein veraltetes graph- oder singlestat-Panel, ein unsichtbares Panel der Breite null, ein Standard-Zeitraum von über einem Jahr, ein refresh unter zehn Sekunden. Jede Regel hat auf dieser Seite ihren eigenen Unterabschnitt, und die Regel-Chips im Playground verlinken direkt dorthin.

Nein. Der Parser und alle Regeln sind JavaScript, das in Ihrem Tab läuft — es gibt keinen Server, keinen API-Aufruf und kein Logging, also werden 0 Bytes hochgeladen. Das zählt hier mehr als bei den meisten Tools: ein Dashboard-JSON ist eine Landkarte Ihrer internen Landschaft. Metriknamen, Datasource-uids, Hostnamen in Legendenformaten, Servicenamen in Variablen-Queries, manchmal eine interne URL in einem Panel-Link. Genau die Datei, die man nicht in einen beliebigen Online-Formatierer einfügen sollte.

Nein, und das sagt das Tool ausdrücklich. Grafanas Dashboard-Schema ist groß, versioniert und weiterhin in Bewegung; eine teilweise Prüfung, präsentiert als Schema-Prüfung, wäre schlimmer als keine Prüfung. Was hier passiert, ist ein struktureller Lint: er liest die Formen, die Importe und Reviews brechen — Variablen, Datasource-Referenzen, Panel-Typen, IDs, Layout, Zeit und refresh — und nennt zu jedem Fund den JSON-Pfad. Er parst kein PromQL, kennt Ihre Plugins nicht und spricht mit keinem Grafana. Die vollständige Liste dessen, was er bewusst nicht meldet, steht oben unter „Was er bewusst nicht meldet“.

Weil die Datei mit „Export for sharing externally“ erzeugt wurde. Dieser Export ersetzt jede Datasource-Referenz durch einen Platzhalter — ${DS_PROMETHEUS} — und ergänzt einen „__inputs“-Block, der beschreibt, was jeder Platzhalter braucht. Nur der Dialog Dashboards → Import liest diesen Block und fragt nach einer echten Datasource. Provisioniert man dieselbe Datei, POSTet sie an die API oder legt sie in einen Git-synchronisierten Folder, wird der Dialog übersprungen: der Platzhalter überlebt in das gespeicherte Dashboard und jedes Panel scheitert daran. Importieren Sie also über den Dialog — oder setzen Sie vor dem Provisionieren die echte { type, uid } ein. Dieser Linter meldet den Platzhalter in beiden Fällen als Fehler, weil die Datei so nicht provisionierbar ist.

Die uid ist der Identifier, den Sie wählen. Sie ist Teil der Dashboard-URL, sie ist das, was Provisioning und API ansprechen, und sie gehört zusammen mit dem JSON in die Versionskontrolle. Die id ist eine Zeilennummer in der Datenbank genau einer Grafana-Instanz — anderswo bedeutet sie nichts. Eine Datei mit uid aktualisiert bei jedem Import dasselbe Dashboard; eine ohne erzeugt bei jedem Import eine neue Kopie. Eine Datei mit veralteter id scheitert beim Import oder trifft ein Dashboard, das nichts mit Ihrem zu tun hat — deshalb sollte ein Export „id“: null tragen.

Die Kern-Panels graph, singlestat und table-old werden beim Laden automatisch migriert und funktionieren also weiter — aber das JSON in Ihrem Repository wird nicht migriert. Die Datei, die Sie reviewen, und das Panel, das Grafana rendert, sind damit zwei verschiedene Dinge. Speichern Sie das Dashboard ab Grafana 9 erneut, damit die Migration in die Datei geschrieben wird. AngularJS-Panel-PLUGINS sind eine andere Geschichte: grafana-piechart-panel, grafana-worldmap-panel und die übrigen haben keine automatische Migration, und Angular wurde in Grafana 9 als veraltet markiert und über Grafana 11–12 entfernt. Diese Panels rendern nichts und müssen von Hand ersetzt werden.

Das Regelwerk ist auf grafana-12 / schemaVersion 41 gepinnt — abgedruckt auf dieser Seite und in jedem kopierten Report, damit nie unklar ist, was geprüft hat. Versionsabhängige Regeln sind als Bereiche formuliert — „Grafana 9–12“, „über Grafana 11–12 entfernt“ — statt als ein exaktes Release, weil Ihre Instanz in der Nähe dieses Punkts liegt und nicht genau darauf. Ist die schemaVersion Ihres Dashboards höher als 41, erhalten Sie einen HINWEIS dazu, und die schemaspezifischen Funde werden als unverbindlich markiert. Eine unbekannte Schemaversion ist eine Grenze dieses Linters, kein Mangel Ihres Dashboards — sie wird deshalb nie als Fehler gemeldet.

Weil Grafana nicht scheitert — es interpoliert nichts und führt die Query mit dem Literal darin aus. Ein PromQL-Selektor {env="$env"} trifft keine Serie, das Panel ist also leer; ein Selektor mit Regex-Matching kann viel MEHR Serien treffen als gemeint, das Panel ist dann gefüllt und falsch. In keinem der beiden Fälle erscheint irgendwo in der Oberfläche eine Meldung. Die einzige Ausnahme, die dieser Linter macht, ist eine Referenz in einem String, der wie ein regulärer Ausdruck aussieht: dort ist „$“ auch ein Zeilenende-Anker, und der Fund sinkt auf eine Warnung, weil das geschriebene „$env“ tatsächlich ein Anker mit folgendem Text sein kann.

Bis zu 5.000.000 Zeichen, was ein generiertes Dashboard mit mehreren Tausend Panels abdeckt; ein Dashboard mit 500 Panels wird in wenigen Millisekunden geprüft. Darüber verweigert das Tool mit einer Meldung, statt Ihren Tab einzufrieren — eine so große Eingabe ist ein Log oder ein Archiv, kein Dashboard. Auch die Funde sind begrenzt: höchstens 50 pro Regel und 400 insgesamt, und das Panel nennt die Grenze und die tatsächliche Zahl, sobald eine greift — eine gekürzte Liste, die ihre Kürzung nicht nennt, wäre genau die stille Unrichtigkeit, gegen die dieses Tool existiert.