Dashglass :des tableaux de bord Prometheus, en un seul binaire Go.
Un binaire Go, aucune base de données, rien d'autre à déployer — la partie tableaux de bord de Grafana, et seulement celle-là.
Développé par Bleemeo sur les mêmes composants de graphiques et d'édition PromQL que notre propre interface de monitoring. Vous éditez dans le navigateur, vous relisez le diff dans git.
Démarrage rapide
Pointez-le sur un Prometheus et ouvrez un navigateur
Lancez l'image publiée contre votre propre Prometheus.
docker run -p 8080:8080 -v "$(pwd)/dashboards:/dashboards" \
ghcr.io/bleemeo/dashglass -prometheus-url http://your-prometheus:9090Ouvrez ensuite http://localhost:8080. Les tableaux de bord sont de simples fichiers dans le répertoire monté : mettez ce répertoire dans git et vous avez le GitOps. Les images sont taguées latest et par version (CalVer, par exemple 2026.07.25.120000) ; un tag snapshot mobile suit la branche principale et peut casser.
Vous partez d'une instance vide ? L'écran d'accueil propose des tableaux de bord d'exemple en un clic — « Prometheus overview » et « Prometheus internals » — construits uniquement sur les métriques que Prometheus expose sur lui-même, ils affichent donc de vraies données sur n'importe quelle installation.
Vous préférez un binaire unique ? Des exécutables pour Linux, macOS et Windows sont attachés à chaque version :
./dashglass -prometheus-url http://localhost:9090 -dashboards-dir ./dashboardsPas de Prometheus sous la main ? Le dépôt fournit une démo Compose avec un Prometheus qui se scrape lui-même, les tableaux de bord d'exemple ont ainsi de vraies données :
git clone https://github.com/bleemeo/dashglass && cd dashglass
docker compose upUne chose à savoir avant de l'exposer : une instance neuve démarre sans authentification, donc quiconque peut l'atteindre est un administrateur anonyme — un bandeau dans l'interface le rappelle. Créez le premier utilisateur depuis Admin → Users pour que tout le monde doive se connecter, ou définissez DASHGLASS_BOOTSTRAP_ADMIN_PASSWORD pour un déploiement automatisé.
L'application
Une grille, un éditeur PromQL et un mode kiosque
Une grille de 24 colonnes avec sections, annulation/rétablissement et un aperçu en direct qui utilise vos vraies variables et votre plage de temps. Les panneaux se répètent sur les valeurs d'une variable, les liens de données transportent les variables et la plage courantes vers un autre tableau de bord ou un outil externe, et chaque graphique accepte le zoom et la sélection. Thèmes clair et sombre, et un mode kiosque pour les écrans muraux.
Ce qu'il fait
Construire, connecter, versionner
Les tableaux de bord s'éditent dans l'interface et restent de simples fichiers, que vous pouvez mettre dans git. Les requêtes ne quittent jamais le backend. C'est tout le principe.
Construire
- Panneaux courbes, valeur, jauge, tableau, barres, heatmap, grille de statuts, markdown, image et horloge, avec unités et seuils.
- Éditeur PromQL avec autocomplétion et vérification en direct, adossé à l'API Prometheus.
- Variables, y compris chaînées, où une liste dépend d'une autre.
- Répétition de panneau par variable : une définition, une tuile par instance.
- Liens de données et navigation transportant les variables courantes et $__from / $__to.
- Deux éditeurs : une grille visuelle, et une vue as-code du fichier brut validée à l'enregistrement.
- Mode Explore pour les requêtes ponctuelles, mode kiosque et thèmes clair et sombre.
Connecter
- Le navigateur ne parle jamais à Prometheus : chaque requête passe par un proxy en lecture seule côté backend.
- Les identifiants restent côté serveur — authentification basique ou jeton bearer, jamais dans la page.
- En-têtes supplémentaires pour la multi-tenance Mimir/Cortex (X-Scope-OrgID) ou un schéma Authorization personnalisé.
- CA personnalisée pour un endpoint à autorité privée, et certificat client + clé pour le mTLS.
- Le test de connexion vérifie TLS, en-têtes et identifiants avant tout enregistrement.
- Provisionnez la source de données dans dashglass.yaml, ou configurez-la à l'exécution depuis Admin.
Versionner
- Sérialisation déterministe en JSON, YAML ou TOML : une modification d'un champ produit un diff d'une ligne.
- Historique git dans l'interface : parcourir les commits touchant un tableau de bord, les comparer, en restaurer un.
- Commit à l'enregistrement, au nom de l'utilisateur connecté, pour que git blame reste honnête.
- La synchronisation distante récupère à intervalle régulier et pousse après un commit, en rebasant un historique divergent.
- Surveillance des fichiers et rechargement en direct via SSE : modifiez un fichier sur disque et le tableau de bord ouvert suit.
- Le mode provisionné (-readonly) refuse toute écriture, administrateurs compris.
- dashglass lint valide les fichiers : un tableau de bord cassé échoue en CI, pas dans un navigateur.
Le lancer
Un seul artefact, quel que soit le déploiement
La SPA est embarquée dans le binaire Go : il n'y a rien d'autre à servir.
Docker
La commande de démarrage rapide ci-dessus, depuis ghcr.io/bleemeo/dashglass. Les tags suivent CalVer par version, plus latest et un snapshot mobile.
Binaire unique
Des exécutables pour Linux, macOS et Windows sont attachés à chaque version. Un fichier statique — seules les fonctions d'historique git réclament autre chose, à savoir le binaire git dans le PATH.
Démo Compose
Un docker compose up dans un clone vous donne Dashglass et un Prometheus qui se scrape lui-même, les tableaux de bord d'exemple affichent donc de vraies données.
Depuis les sources
pnpm install, puis pnpm build-binary produit le binaire unique avec la SPA embarquée. Le guide de contribution couvre la boucle de développement.
Documentation:Guide d'utilisationConfiguration annotéeDocument de conception
Migration
Vous venez de Grafana
Importez ce que vous avez déjà, et voyez exactement ce qui a changé.
Depuis grafana.com
Collez l'URL d'un tableau de bord ou son identifiant numérique et cliquez sur Load. Le backend n'accepte qu'un identifiant numérique et ne contacte que grafana.com, ce qui écarte les SSRF.
Depuis un export JSON
Collez ou déposez le JSON du Share → Export de Grafana. La conversion s'effectue dans le navigateur.
Au mieux, et sans le cacher
Les panneaux courants, les lignes en sections, les requêtes PromQL, le templating et les variables label_values sont convertis. Ce qui ne peut pas être transposé est importé tel quel plutôt que supprimé, et chaque approximation est listée avant enregistrement.
Périmètre
Ce que Dashglass n'est pas
Ce sont des non-objectifs du document de conception, pas des manques en attente.
- Pas un système d'alerting. Ni règles d'alerte, ni canaux de notification, ni gestion d'incidents. Dashglass dessine ce que votre Prometheus sait déjà ; réveiller quelqu'un n'est pas son travail — c'est celui d'Alertmanager, ou d'une plateforme qui s'en charge pour vous.
- Pas une plateforme multi-sources. Prometheus uniquement. La couche source de données est une interface, donc une autre reste possible plus tard, mais SQL, Loki et les traces sont explicitement hors périmètre aujourd'hui. Mimir et Cortex fonctionnent, via l'en-tête de tenance.
- Pas multi-tenant. Trois rôles fixes — viewer, editor, admin — avec des utilisateurs locaux, des en-têtes de reverse proxy ou OIDC. Pas d'ACL par tableau de bord, pas d'équipes, pas d'organisations. Les utilisateurs auto-hébergés ont de vrais rôles ; la limite est posée au fin grain et au multi-tenant.
- Pas une marketplace de plugins. Les panneaux sont des plugins, mais ils sont composés à la compilation. Aucun chargement de plugins tiers à l'exécution, et aucune marketplace à parcourir.
Les questions qu'on nous pose sur Dashglass
Où il se situe, et où il s'arrête volontairement.
Est-ce un remplaçant de Grafana ?
Pour la partie tableaux de bord, c'est exactement l'intention — et il importe ce que vous avez déjà construit. Pour le reste, non : l'alerting, les sources de données autres que Prometheus et un écosystème de plugins sont des non-objectifs assumés. Si vous en avez besoin, gardez Grafana.
Quelles sources de données sont prises en charge ?
Prometheus, et tout ce qui parle son API HTTP — y compris Mimir et Cortex, où l'en-tête de tenance se règle dans la configuration de la source. SQL, Loki et les traces sont hors périmètre.
Le navigateur peut-il joindre directement mon Prometheus ?
Jamais. Chaque requête passe par un proxy en lecture seule dans le backend Go : l'URL, les identifiants, la CA et le certificat client restent côté serveur et n'atteignent jamais la page.
Peut-on provisionner et verrouiller les tableaux de bord ?
Oui. Démarrez avec -readonly (ou dashboards.readonly: true) et l'API refuse les écritures tandis que l'interface retire toute possibilité d'édition — administrateurs compris. Les tableaux de bord sont alors gérés entièrement en modifiant les fichiers dans git.
Comment fonctionne l'authentification ?
Une instance neuve est ouverte volontairement : tant qu'aucun utilisateur n'existe, tout le monde est administrateur anonyme, et un bandeau le signale. Créez le premier administrateur pour que chacun doive se connecter. Ensuite : utilisateurs locaux avec trois rôles cumulatifs, authentification par en-têtes de reverse proxy, ou OIDC avec authorization code + PKCE et mapping des groupes vers les rôles. LDAP est prévu, pas livré.
Faut-il git pour l'utiliser ?
Non. Les tableaux de bord sont des fichiers ; git est ce qui rend ces fichiers relisibles. Les fonctions d'historique exigent que le répertoire soit un dépôt git et que le binaire git soit dans le PATH — sans l'un ou l'autre, tout le reste fonctionne et ces fonctions n'apparaissent simplement pas. Vous transformerez le répertoire en dépôt quand vous le voudrez.
Construit sur des outils que vous connaissez déjà
Dashglass embarque plusieurs projets open source comme bibliothèques : Apache ECharts pour les graphiques, le paquet CodeMirror PromQL officiel de Prometheus pour l'édition et l'autocomplétion, react-grid-layout pour la grille, Zod pour le schéma des tableaux de bord et la validation des fichiers, Chakra UI et React côté interface, et Go avec la SPA embarquée pour l'artefact unique que vous déployez.