Grafana est une plateforme open source de visualisation et d’alerte pour les métriques, les logs et les traces issus de nombreuses sources de données. La plupart des gens la découvrent via son interface web, mais tout ce qui compte dans une installation Grafana peut aussi être décrit dans des fichiers : paramètres du serveur, sources de données, tableaux de bord, règles d’alerte, points de contact et politiques de notification. Cette série se concentre sur cette seconde façon de travailler, afin qu’une instance Grafana puisse être reconstruite depuis Git à tout moment et que personne n’ait à se rappeler ce qui a été cliqué le mois dernier.

Comment ça fonctionne

Grafana lit sa configuration à partir de couches que vous pouvez contrôler sans ouvrir l’interface :

1. La configuration du serveur (grafana.ini et les variables d’environnement GF_*) contrôle les ports, la base de données, l’authentification, SMTP et les feature toggles.
2. Les fichiers de provisionnement (YAML dans un dossier provisioning/) créent au démarrage les sources de données, les fournisseurs de tableaux de bord, les ressources d’alerte et les paramètres de plugins.
3. Les fichiers JSON de tableaux de bord sur disque sont chargés par un fournisseur de tableaux de bord (dashboard provider) et réanalysés pendant que Grafana tourne.
4. Les API et les opérateurs (Terraform, le Grafana Operator, Git Sync, la CLI gcx) gèrent ce que les fichiers seuls ne peuvent pas gérer, comme les équipes, les comptes de service et les permissions des dossiers.

Comme tout cela est du texte brut, cela s’intègre au même workflow GitOps que le reste de votre infrastructure, y compris Flux et Argo CD.

Concepts clés

• Source de données — une connexion à un backend tel que Prometheus, Loki ou PostgreSQL. Les tableaux de bord et les règles d’alerte interrogent les sources de données par nom ou par UID.
• Tableau de bord — un document JSON composé de panneaux et de variables. Grafana utilise désormais en interne un schéma de tableau de bord plus récent, et le JSON plus ancien est migré automatiquement au chargement.
• Dossier — organise les tableaux de bord et les règles d’alerte, et porte des permissions.
• Provisionnement — chargement de ressources depuis des fichiers au démarrage, afin qu’elles existent avant que quiconque ne se connecte.
• Alerting — règles d’alerte, points de contact, politiques de notification, plages de mise en sourdine (mute timings) et modèles (templates), le tout pouvant être provisionné.
• Organisation — une frontière de tenant au sein d’un serveur Grafana ; la plupart des fichiers acceptent un orgId.

Pourquoi opérer Grafana comme du code

• Reproductible. Une instance perdue ou nouvelle revient à l’identique depuis le dépôt.
• Relisible. Une modification de tableau de bord ou d’alerte est une pull request avec un diff, et non une modification non tracée.
• Cohérent entre les environnements. Dev, staging et production partagent les mêmes définitions et ne diffèrent que par leurs valeurs.
• La dérive est visible. Les ressources provisionnées peuvent être verrouillées contre les modifications via l’interface, de sorte que Git reste la source de vérité.

Pour commencer

Lancez Grafana dans un conteneur avec un dossier provisioning/ monté, ajoutez un fichier de source de données et un fournisseur de tableaux de bord, puis déposez le JSON des tableaux de bord à côté. Les guides ci-dessous partent de là, puis abordent l’alerting, les secrets, Kubernetes, Terraform et l’Operator. Ils ont été rédigés pour Grafana 13 ; consultez la documentation Grafana pour la version que vous installez, car certaines fonctionnalités « as code » sont encore marquées alpha.