Qu’est-ce que Grafana et à quoi sert-il ?

Si vous passez suffisamment de temps à examiner des logs bruts et que vous plissez légèrement les yeux, vous finirez peut-être par voir la Matrice apparaître au milieu de ce que marmonnent ces milliers de lignes incompréhensibles. Et grâce à des incantations obscures dans le terminal, commençant par grep ou awk, vous pourrez trouver la goutte que vous recherchez dans cet océan de caractères. Mais cette méthode est inefficace et elle n’impressionne personne, surtout pas notre responsable ou la personne qui nous plaît. Pour leur permettre, à eux aussi, d’accéder aux connaissances dissimulées parmi des milliers de données, il existe des outils comme Grafana, qui affichent les informations les plus importantes à l’aide de graphiques simples et de tableaux de bord attrayants lors de la supervision.
C’est pourquoi Grafana est l’un des outils les plus reconnaissables dans le domaine de la supervision IT, au point que beaucoup le confondent avec la supervision dans son ensemble. Pourtant, Grafana est la couche qui interroge, explore et visualise les données, et qui déclenche des alertes à partir d’informations stockées dans d’autres systèmes.
Il ne sert donc pas uniquement à dessiner de jolis graphiques sur son canevas, même s’il s’agit de sa fonctionnalité la plus connue, mais il ne remplace pas non plus, à lui seul, tout ce dont nous avons besoin pour collecter, stocker et gérer notre télémétrie.
Il est important de bien comprendre cette distinction, car presque tout le reste en découle. Aujourd’hui, nous verrons ce qu’est réellement Grafana, comment il fonctionne en interne et à quoi il sert, quels avantages il nous apporte, quelle complexité il ajoute… et où cette pièce du puzzle s’intègre au sein d’une architecture de supervision et d’observabilité.

Qu’est-ce que Grafana ?

Passons un instant en mode dictionnaire : Grafana est une plateforme open source de visualisation et d’analyse qui permet d’interroger, d’explorer et de représenter des données stockées dans des sources très diverses, ainsi que de générer des alertes à partir de celles-ci.
C’est pourquoi son utilisation la plus connue concerne les tableaux de bord, ces panneaux remplis de graphiques, de jauges et de voyants qui décorent les écrans de la moitié du département IT. Cependant, sa portée réelle couvre les métriques, les logs, les traces et les profils de performance. La documentation officielle de Grafana résume bien son principe directeur : métriques, logs, traces et profils, où qu’ils se trouvent.

Le fait qu’il s’agisse également d’un outil open source signifie deux choses dans la pratique :

• Nous pouvons le déployer nous-mêmes sans payer de licence.
• Nous pouvons consulter et modifier son code.

Grafana OSS a été replacé sous licence AGPLv3 il y a quelque temps. Toute ancienne référence à Apache 2.0 appartient donc à une autre époque, tout comme grep et awk pour les plus nostalgiques d’entre nous.
À partir de là, trois déclinaisons de l’outil nous sont proposées dans la même assiette :

• Grafana OSS. L’édition ouverte et autogérée qui comprend l’essentiel : visualisation, connexion aux sources de données et système d’alertes. Il s’agit du point de départ de presque tout le monde lors de la découverte de l’application.
• Grafana Enterprise. Cette édition repose sur la même base, mais comprend davantage de plugins commerciaux, des fonctionnalités supplémentaires et un service de support. Elle est destinée aux organisations qui ont besoin de garanties et de connecteurs que la communauté ne couvre pas.
• Grafana Cloud. Cette version suit la tendance actuelle consistant à tout proposer sous forme d’abonnement, mais avec l’avantage de fournir l’ensemble de l’écosystème sous la forme d’un service SaaS géré. Nous n’avons ainsi plus à déployer ni à maintenir l’infrastructure.

Grafana est né comme un fork de Kibana 3 —« Graf » fait référence aux graphiques et « ana » rend hommage à Kibana— car, en décembre 2013, le développeur suédois Torkel Ödegaard avait besoin d’un outil plus flexible pour créer des tableaux de bord de métriques.
Depuis, après des débuts centrés sur les graphiques de séries temporelles, Grafana a largement dépassé ce cadre, jusqu’à devenir une interface de référence pour une grande partie de l’univers de l’observabilité.

Comment fonctionne Grafana

À ce stade, il est utile de soulever le capot de tous ces jolis graphiques et de toutes ces couleurs pour voir ce qui se cache dessous, car presque tous les malentendus concernant Grafana viennent d’une mauvaise compréhension de son fonctionnement.
La première chose à comprendre est que Grafana ne génère pas de données en production. Il se connecte à des systèmes qui les possèdent déjà et les leur demande lorsqu’il en a besoin.
De manière simplifiée, son fonctionnement suit ce parcours :
Source de données → Requête → Panneau → Tableau de bord

En parallèle de ce parcours et à partir de cette même requête, ou de toute autre requête que nous définissons, nous pouvons configurer des règles d’alerte qui évaluent une condition et déclenchent elles-mêmes une notification.
Décomposons ce fonctionnement étape par étape :

• Un système externe collecte ou stocke les données, par exemple un serveur Prometheus, une base de données ou un service cloud.
• Grafana s’y connecte au moyen d’une data source ou source de données, en s’appuyant sur un connecteur spécifique à la technologie concernée. De nombreux connecteurs pour les sources les plus courantes sont intégrés, tandis que d’autres sont installés sous forme de plugins.
• L’utilisateur exécute ensuite une requête, rédigée dans un langage que cette source comprend.
• Le résultat apparaît dans un panneau, qui constitue l’unité minimale de visualisation.
• Plusieurs panneaux sont regroupés dans un tableau de bord, qui offre une vue d’ensemble, et…
• Par ailleurs, des règles d’alerte peuvent être définies sur cette même source de données sans devoir être associées à un panneau, contrairement à ce qui se produisait dans les versions précédentes : elles exécutent des requêtes, évaluent une condition et déclenchent elles-mêmes une notification.

Examinons rapidement de plus près les rouages du processus, car ces concepts sont souvent confondus.

• La source de données correspond à la connexion à une origine de données.
• Le plugin est le traducteur qui parle son langage.
• La query ou requête est la question précise que nous posons.
• Le panneau est une réponse visuelle.
• Le tableau de bord est un ensemble de réponses visuelles configuré en fonction de nos besoins d’information précis.
• L’alert rule ou règle d’alerte est la condition qui déclenche une notification lorsque quelque chose sort des rails.

L’ensemble fonctionne comme le HUD d’un simulateur de vol, où l’écran affiche l’altitude, le carburant et le régime moteur avec une précision millimétrée, mais le panneau n’invente aucun de ces chiffres : ils sont produits par le moteur qui se trouve en dessous.
C’est pourquoi, si nous retirons le moteur, le HUD continue d’afficher de très beaux zéros et Grafana fonctionne toujours de la même manière, car sans source de données configurée, il n’a rien à nous montrer en dehors de ces zéros.
Chaque source dispose en outre de son propre éditeur de requêtes, adapté à la manière dont elle stocke les informations, ce qui peut être aussi puissant que peu pratique, selon les jours.
Il reste un autre élément à assimiler concernant son fonctionnement : rien de tout cela n’est une image statique, sans quoi cela ne nous serait pas très utile.
Chaque tableau de bord possède une plage temporelle et un intervalle d’actualisation dont héritent ses panneaux. Même si un panneau donné peut remplacer la plage par une période relative qui lui est propre, l’actualisation concerne l’ensemble du tableau de bord. Grafana relance donc les requêtes à chaque intervalle et redessine la représentation à partir des résultats reçus.
Ainsi, lorsque nous voyons un graphique évoluer en temps réel, Grafana ne « capture » rien, même si c’est l’impression que cela donne. Il interroge simplement la source à plusieurs reprises et actualise sa représentation.
Comprendre cela permet d’éviter certaines mauvaises surprises, car cela explique pourquoi un panneau devient plat lorsque la source cesse de répondre. La raison est qu’il n’y a plus rien à l’autre bout de la connexion, mais Grafana continue de fonctionner comme nous venons de le voir, ce qui provoque ce type de situation.

À quoi sert Grafana

C’est la question à un million et celle qui amène beaucoup de monde ici, car Grafana peut servir à de nombreuses choses, presque toutes liées à la visualisation et à la compréhension de ce qui se passe dans une infrastructure IT.
Voici ses utilisations concrètes au quotidien :

• Visualisation des métriques d’infrastructure. CPU, mémoire, disque, réseau… Le pain quotidien de tout administrateur système.
• Supervision des serveurs et des applications. En nous signalant, par exemple, leurs temps de réponse, leurs taux d’erreur, leurs files d’attente ou leur latence. C’est ce qui distingue un service sain d’un autre qui agonise en silence.
• Observabilité de Kubernetes et des environnements cloud native. En surveillant l’état des conteneurs, les pods qui redémarrent sans prévenir ou la consommation de ressources par namespace.
• Analyse des logs et des traces distribuées. Cela permet, par exemple, de suivre les traces laissées par une requête qui traverse quinze microservices avant d’échouer dans le dernier.
• Tableaux de bord pour les NOC et les équipes d’exploitation. Ils ressemblent aux grands écrans de la salle de contrôle dans les films d’espionnage, depuis lesquels on vérifie que le monde continue de tourner dans le bon sens.
• Corrélation visuelle entre différentes sources d’information. Cela nous permet de réunir dans une même vue des données stockées à différents endroits, afin qu’elles nous racontent l’histoire complète de ce qui se passe, ce qu’il serait impossible de déterminer en les examinant séparément.
• Alertes et indicateurs métier. Cela va d’une notification signalant un disque plein à un tableau de bord destiné au CEO, avec les chiffres qui comptent vraiment pour quelqu’un qui ne distingue pas un conteneur Docker d’un bac de recyclage des emballages.

Pour rendre cela plus concret, imaginons une nuit comme une autre. Un panneau montre que la latence d’une API a explosé, tandis que celui d’à côté indique que la mémoire de trois conteneurs approche de sa limite. Par ailleurs, un autre panneau met en corrélation ces pics avec une augmentation des erreurs 500 survenue juste après un déploiement.
Aucun de ces graphiques ne résout l’incident à notre place, certes, mais ensemble, ils dessinent un tableau —horrible dans cet exemple— que nous aurions mis trois fois plus de temps à reconstituer et à comprendre dans son ensemble en examinant les données et les systèmes un par un.
C’est là le véritable rôle de Grafana : réunir sur un même écran des éléments qui existent séparément, afin de voir le puzzle dans son ensemble et non ses pièces isolées.
Le fil conducteur est la diversité, car Grafana n’est lié ni à un type de données ni à un fournisseur. L’exemple précédent aurait tout aussi bien pu être construit à partir de l’utilisation du CPU, d’événements de logs, de temps de réponse ou de la disponibilité d’un service.
Cette flexibilité constitue son principal atout, même si, comme nous le verrons, elle n’est pas gratuite : son prix est la complexité.

Les tableaux de bord de Grafana

C’est le moment pour l’outil de briller, car c’est ici qu’il se distingue des autres solutions.
Rappelons qu’un tableau de bord est un ensemble organisé de panneaux qui affichent, en un coup d’œil, l’état de ce qui nous importe. Le panneau est l’élément individuel qui présente un graphique, un tableau ou une jauge, tandis que le tableau de bord est la composition qui les rassemble et leur donne du sens.

Autour de ce concept, Grafana propose une boîte à outils étendue, présentée en détail dans sa documentation consacrée aux tableaux de bord, qui nous permet d’utiliser :

• Différents types de visualisation pour presque tout : des séries temporelles aux cartes de chaleur, en passant par les jauges, les tableaux, les histogrammes, les états…
• Des variables et des filtres afin de ne pas devoir cloner un panneau pour chaque serveur. Grafana permet de réutiliser le même panneau en modifiant une liste déroulante.
• Des annotations qui nous permettent d’indiquer sur le graphique quand une version a été déployée ou quand un incident a commencé.
• Des modèles et des tableaux de bord communautaires que nous pouvons importer et adapter à notre infrastructure IT, ce qui nous évite de partir d’une page blanche.
• Des autorisations et une organisation par équipes, afin que chacun voie ce qui le concerne sans aller fouiner là où il ne le devrait pas ni empiéter sur le travail des autres.

Concevoir un bon tableau de bord relève davantage du savoir-faire que d’une simple succession de clics et pourrait faire l’objet d’un article entier. C’est pourquoi, pour suivre le processus étape par étape, nous avons préparé un guide consacré à la création de tableaux de bord Grafana avec des données de Pandora FMS, dans lequel le processus est examiné en détail.
Pour ce qui nous intéresse ici, il suffit de bien comprendre l’idée fondamentale : le tableau de bord est la vitrine qui expose les informations, et une vitrine n’est attrayante que si elle présente de bons produits.
Ce qui nous conduit inévitablement à…

Les sources de données de Grafana

Le Petit Prince a tenté de nous apprendre que l’essentiel est invisible pour les yeux et, dans le cas de Grafana, les données sont le cœur qui bat à l’intérieur, même si ce n’est pas la partie qui apparaît dans les captures d’écran.
Une source de données est la connexion à un système qui stocke des informations, et chacune s’appuie sur un connecteur externe ou intégré capable de communiquer avec la technologie concernée.
La documentation officielle consacrée aux sources de données présente en détail l’immense catalogue à partir duquel Grafana peut afficher des informations, mais pour démontrer ses capacités, il suffit de citer les suspects habituels :

• Séries temporelles et métriques : Prometheus, InfluxDB, Graphite…
• Clouds publics : AWS CloudWatch, Azure Monitor, Google Cloud Monitoring…
• Bases de données : MySQL, PostgreSQL, Microsoft SQL Server…
• Logs et traces : Elasticsearch, Loki, Tempo, Jaeger…

Comme nous pouvons le constater, cela couvre presque tout. Il est donc inutile de mémoriser une liste qui s’allonge chaque mois. Grafana intègre nativement certaines sources de données principales —les plus populaires et les plus utilisées— et étend les autres au moyen de plugins, ce qui lui permet d’interroger presque indifféremment des métriques, des logs, des traces, des profils et des données provenant de bases de données ou de services cloud.

Cependant, cette diversité s’accompagne de quelques lignes en petits caractères, car chaque source utilise son propre langage de requête.
PromQL pour Prometheus, LogQL pour Loki, SQL pour une base de données relationnelle… Grafana unifie la vue, mais pas le langage qui fonctionne en dessous. Par conséquent, pour en tirer pleinement parti, nous devrons également savoir comment interroger chaque source.
Dans le cas contraire, il est facile de se tromper sans s’en rendre compte, car une source mal configurée, des identifiants expirés ou une requête trop lourde peuvent laisser un magnifique tableau de bord afficher des données incorrectes ou, tout simplement, ne rien afficher du tout.

Supervision et alertes avec Grafana

Nous ne voulons pas seulement des graphiques capables d’impressionner ceux qui tiennent les cordons de la bourse ; nous voulons aussi de l’utilité au quotidien, de l’observabilité, des alertes et des yeux d’elfe surveillant chaque recoin de notre infrastructure et signalant tout ce qu’ils y voient. Dans ce cas, Grafana peut-il servir à superviser ?
Oui, mais cela signifie des choses différentes selon la personne à qui l’on pose la question.
Grafana peut interroger des données de supervision, les afficher en temps réel, évaluer des règles, centraliser les alertes, envoyer des notifications et combiner des requêtes provenant de différentes sources au sein d’une même règle. Son système d’alertes permet également de définir des conditions sur plusieurs sources et de gérer toutes les notifications depuis une vue commune, ce qui est extrêmement utile lorsque notre télémétrie importante est dispersée aux quatre coins du monde.

Je dois toutefois insister sur la nuance qui distingue ceux qui comprennent Grafana de ceux qui le présentent comme une solution miracle. Grafana reste la couche de peinture extérieure, et le fait qu’il puisse nous alerter ne supprime pas la nécessité de collecter, de stocker et de maintenir correctement les données qui l’alimentent.
Une alerte ne sera jamais meilleure que la source sur laquelle elle repose et, si personne ne collecte la métrique ou si celle-ci est mal collectée, Grafana ne nous avertira de rien.

L’écosystème d’observabilité de Grafana

Au fil des années, Grafana Labs a construit autour de Grafana une constellation de projets open source couvrant chaque étape du parcours de la télémétrie, également soutenue par des standards externes tels que Prometheus ou OpenTelemetry. Il est intéressant d’explorer cette constellation, même rapidement, car elle explique pourquoi on parle parfois de la « stack Grafana » et pas seulement de « Grafana » lui-même. Dans cet écosystème, nous trouvons généralement :

• Prometheus : le grand classique de la collecte et du stockage des métriques, même s’il n’appartient pas à Grafana Labs, puisqu’il s’agit d’un projet de la CNCF.
• Loki : le backend destiné aux logs.
• Mimir : bien qu’en espagnol ce terme soit utilisé comme un mème pour dire dormir, il respecte en réalité la tradition consistant à choisir des noms issus de la mythologie nordique, en référence au géant chargé de garder la source de la connaissance située sous les racines de l’arbre le plus sacré. Dans la pratique, il permet un stockage évolutif à long terme des métriques Prometheus.
• Tempo : le backend destiné aux traces distribuées.
• Pyroscope : le profilage continu des performances.
• Alloy : qui collecte et envoie des métriques, des logs, des traces et des profils.

Loki, Tempo et Mimir sont des composants de stockage complémentaires, tandis qu’Alloy joue le rôle de collecteur unifié, sous la forme d’une distribution d’OpenTelemetry Collector centralisant l’envoi de la télémétrie.

Un avertissement important concernant la documentation obsolète : si nous consultons d’anciens guides, mieux vaut oublier Grafana Agent. Celui-ci a atteint sa fin de vie le 1er novembre 2025 et ne reçoit désormais plus aucun support, correctif ni mise à jour de sécurité.
La recommandation officielle consiste à migrer vers Alloy.

Grafana et Prometheus : quelles différences ?

J’ai beaucoup parlé de Grafana et de Prometheus, et ces concepts sont parfois confondus. Je pense donc qu’ils méritent leur propre section afin de bien comprendre le rôle de chacun.

• Prometheus collecte et stocke des métriques. Dans sa relation avec Grafana, il constitue donc une source de données.
• Grafana interroge et visualise ces données. Il constitue donc une couche de présentation.

Ils fonctionnent très bien ensemble, mais aucun des deux ne nous oblige nécessairement à utiliser l’autre.
Grafana est volage et peut se connecter à un très grand nombre de sources de données autres que Prometheus, tandis que Prometheus peut également fonctionner de manière autonome et alimenter d’autres interfaces, dans une relation polygame consentie et très utile pour notre gestion IT.
Comme tout bon couple moderne, ils se complètent sans dépendre l’un de l’autre.
Pour approfondir le sujet, nous expliquons ici comment s’intègre le reste de l’architecture de supervision de Prometheus. La documentation officielle présente également son intégration et sa relation avec Grafana.
Pour le moment, retenons une phrase qui dissipe 90 % des confusions : Prometheus stocke et Grafana affiche.

Avantages de Grafana

Si Grafana est devenu presque un standard dans notre secteur, c’est en raison de sa supériorité dans les domaines suivants :

• Flexibilité de la visualisation. Peu d’outils nous permettent de représenter les mêmes données de façons aussi variées.
• Compatibilité avec de multiples sources. Des métriques, des logs, des traces et des bases de données peuvent cohabiter dans un même panneau, aussi différents soient-ils à l’origine.
• Tableaux de bord personnalisables jusqu’au dernier pixel, avec un écosystème de plugins qui permet d’étendre presque toutes les fonctionnalités.
• Alertes centralisées combinant des requêtes provenant de différentes sources au sein d’une vue unique.
• Séparation entre la visualisation et le stockage. Nous pouvons ainsi remplacer le moteur de données sans devoir reconstruire la structure visuelle des panneaux —même s’il faudra adapter les requêtes— et inversement.
• Communauté et ressources. Grafana est un projet actif qui se porte particulièrement bien, avec du code open source sur GitHub, des milliers de tableaux de bord partagés et des réponses à presque toutes les questions.
• Options self-hosted et cloud, selon la quantité d’infrastructure que nous souhaitons administrer nous-mêmes ou déléguer à d’autres.

En tant que couche de visualisation flexible et dissociée du stockage, peu d’alternatives peuvent rivaliser avec Grafana. Toutefois, il ne s’agit pas non plus de la solution miracle pour toutes les organisations. Il est donc temps de parler de…

Limites de Grafana

Dans Le Seigneur des anneaux, les palantíri permettent à ceux qui les possèdent de voir des choses lointaines, mais ceux qui les utilisent dépendent entièrement de ce qui se trouve de l’autre côté de la pierre… et plus d’un s’est fait tromper pour avoir accordé une confiance excessive à ce qu’il voyait.
Un tableau de bord fonctionne de la même manière, en affichant ce qui lui parvient. Mais si ces informations sont incomplètes ou incorrectes, s’il s’agit d’une ruse de Sauron ou si les données sont mal organisées, nous verrons un magnifique mensonge en temps réel.
Les véritables limites de Grafana sont donc les suivantes :

• Il n’apporte aucune valeur sans sources de données correctement configurées. C’est une conséquence directe du fait que Grafana constitue une fenêtre ouverte sur le stockage des données, mais pas le système de stockage lui-même.
• Une architecture complète nécessite généralement plusieurs outils. Collecteur, stockage des métriques, des logs, des traces… Grafana n’est qu’une pièce du puzzle complet dont nous avons besoin.
• L’installation est simple, mais la maintenance de la stack… C’est une autre histoire, car démarrer Grafana ne prend que quelques minutes, tandis que maintenir la haute disponibilité, la rétention, les autorisations et la montée en charge relève d’un tout autre scénario.
• Les requêtes dépendent de chaque source. Chaque origine possède son propre langage et sa propre structure. Je ne cesserai donc pas d’insister sur le fait que maîtriser Grafana implique également de maîtriser les langages de ses sources de données.
• Les tableaux de bord nécessitent une conception et une maintenance. Car, au final, un panneau mal conçu induit davantage en erreur qu’il n’informe et devient obsolète si personne ne s’en occupe.
• Il peut créer une dépendance à des connaissances spécialisées. Quelqu’un doit savoir maintenir tout cet ensemble, et ce type de profil n’est pas toujours facile à trouver, même s’il est probablement toujours en train d’envoyer des CV pour explorer des horizons plus prometteurs.
• Il ne remplace pas une plateforme de supervision intégrée. En effet, il ne comprend pas nativement d’inventaire, de découverte, d’agents propres administrés depuis la plateforme, de gestion des événements, de rapports SLA, d’accès à distance ni de supervision réseau avancée.

Il ne s’agit pas de dénigrer Grafana, mais de rappeler ce qu’il est réellement et de reconnaître qu’il remplit admirablement bien son rôle. Cependant, une plateforme de visualisation composable n’est pas une plateforme de supervision intégrée.

Grafana OSS, Enterprise ou Cloud : quelle version choisir ?

Quelles sont les différences entre les différentes versions de l’outil ? Que propose chacune d’entre elles et laquelle convient le mieux à notre situation ?
Analysons-les à l’aide d’un tableau simple qui nous apportera une réponse rapide.

Édition	Déploiement	Orientation principale	Idéale pour
Grafana OSS	Autogéré	Fonctionnalités open source essentielles	Les équipes capables d’exploiter leur propre stack
Grafana Enterprise	Autogéré	Fonctionnalités commerciales, plugins et support	Les organisations ayant des exigences professionnelles
Grafana Cloud	SaaS géré	Stack d’observabilité hébergée	Les équipes souhaitant réduire leur charge opérationnelle

Je crains de ne pas pouvoir inclure les tarifs ou les limites des différentes offres, car ils changent régulièrement et cet article serait obsolète avant même son point final.
Quant à l’option qui nous convient le mieux, comme toujours, la bonne réponse est cet agaçant « cela dépend », qui nous oblige d’abord à examiner ce que nous possédons dans notre infrastructure. Le meilleur choix dépendra donc de la part de cette infrastructure que nous souhaitons administrer et des garanties dont nous avons besoin.

• Si nous disposons de l’équipe, du temps et de la motivation nécessaires pour l’exploiter —hé hé—, nous pouvons opter pour l’édition OSS et déployer Grafana de nos propres mains.
• Si nous avons besoin d’un accompagnement commercial, il faudra évidemment choisir la version Enterprise.
• Si nous préférons oublier toute la plomberie, mieux vaut alors choisir l’édition Cloud, avec des tuyaux déjà raccordés et sans aucune fuite.

Comme toujours, les réglementations relatives aux données, à la sécurité ou aux processus de travail internes peuvent nous imposer cette décision, notamment en raison d’une éventuelle obligation de conserver des informations sensibles sur nos propres serveurs ou de mettre en place des mesures de sécurité particulières. Dans ces situations, l’option Cloud serait pratiquement écartée et nous nous orienterions vers OSS ou Enterprise, en particulier pour les entreprises appartenant à des secteurs critiques ou stratégiques.

Intégration de Grafana avec Pandora FMS

C’est ici que deux philosophies se rejoignent au lieu de s’affronter, et la clé réside dans la répartition des fonctions. Celle-ci est plus simple qu’il n’y paraît, et un châssis Grafana équipé d’un « moteur » Pandora FMS nous donne presque toutes les chances de monter sur le podium de la gestion IT.
Dans cette combinaison, le fonctionnement optimal serait le suivant :

• Pandora FMS collecte et gère les données de supervision. La plateforme découvre, mesure, corrèle, alerte et stocke.
• Grafana consomme les données fournies par Pandora FMS comme une source de données supplémentaire afin de créer des visualisations complémentaires.
• L’intégration permet de représenter les modules et les métriques de Pandora FMS dans des tableaux de bord Grafana, en tirant parti du meilleur des deux univers.
• En outre, les autorisations des utilisateurs de Pandora FMS délimitent les données auxquelles il est possible d’accéder, de sorte que la sécurité ne reste pas de l’autre côté de la porte.

Dans la pratique, la connexion repose sur deux composants complémentaires : l’extension de Pandora FMS, qui expose le point d’accès aux données, et le plugin installé dans Grafana, qui les consomme comme une source de données en s’authentifiant à l’aide d’un compte utilisateur Pandora FMS.
Dans les grandes lignes, la mise en place est une danse composée de quatre mouvements simples qui constituent le processus général.
Je ne la décrirai pas de manière exhaustive afin de ne pas transformer cet article en Bible, mais pour consulter le processus complet et actualisé, voici le guide pas à pas de l’intégration de Grafana et Pandora FMS.

Étape 1. Charger l’extension dans la console Pandora FMS

Elle est chargée depuis le gestionnaire d’extensions de la console elle-même et prépare le point d’accès par lequel Grafana demandera les données.
Pour les installations réalisées à partir de l’image ISO, il faut également ajuster quelques paramètres dans les configurations d’Apache et de PHP, puis redémarrer les services afin que les modifications prennent effet. Le guide actualisé indiqué un peu plus haut présente ces détails plus précis ainsi que les commandes correspondantes.

Étape 2. Installer le plugin sur le serveur Grafana

Le plugin est décompressé dans le répertoire des plugins de Grafana, déclaré dans son fichier de configuration, puis le service est redémarré afin que Grafana le reconnaisse correctement au démarrage.

Étape 3. Ajouter Pandora FMS comme source de données

Trois opérations doivent être effectuées ici.

• Cliquer sur le bouton permettant d’ajouter une nouvelle source de données Grafana.
• Sélectionner le plugin Pandora FMS.
• Renseigner les trois champs nécessaires : l’URL de l’extension, qui sera par défaut http://x.x.x.x/pandora_console/extensions/grafana, où x.x.x.x correspond à l’adresse IP ou au nom DNS de notre console Pandora FMS, puis le nom d’utilisateur Pandora FMS et son mot de passe.

Le test de connexion nous indique immédiatement si quelque chose ne fonctionne pas, par exemple si Grafana ne parvient pas à joindre la machine, si l’adresse de l’extension est incorrecte ou si les identifiants sont refusés.

Étape 4. Construire le premier tableau de bord

Lors de la création du panneau, la source de données Pandora FMS est sélectionnée et des listes déroulantes permettant de choisir le groupe, l’agent et le module apparaissent pour faire office d’éditeur de requêtes. Plusieurs requêtes peuvent être intégrées dans un même panneau afin de comparer des modules, et plusieurs panneaux peuvent être réunis dans un même tableau de bord.
L’idée essentielle à retenir est la suivante : deux spécialistes d’élite travaillant ensemble dans les domaines où chacun excelle. Une plateforme comme Pandora FMS, qui collecte et pilote la supervision avec une expérience éprouvée de plus de vingt ans, associée à une couche de visualisation de référence grâce à Grafana, qui apporte une autre manière d’observer ces mêmes données.

Grafana est-il préférable à une plateforme de supervision intégrée ?

Même si la combinaison précédente est optimale, la vie réelle a la fâcheuse habitude de nous imposer des budgets IT limités, et l’association de plusieurs outils peut également être redondante dans notre cas. Nous devons alors choisir l’une ou l’autre option.
Dans ce type de confrontation, il n’y a aucun vainqueur et la bonne réponse est une nouvelle fois « cela dépend ». Mais pas d’inquiétude, car voici les critères de décision.
Grafana convient parfaitement lorsque :

• Nous disposons déjà de sources de métriques, de logs ou de traces opérationnelles.
• Nous recherchons une flexibilité visuelle maximale et souhaitons représenter les données à l’image de nos préférences les plus particulières.
• Nous disposons des ressources nécessaires pour exploiter une architecture composable constituée de plusieurs éléments.
• Nous travaillons avec des écosystèmes Prometheus, Kubernetes ou OpenTelemetry, qui nous offrent presque la passe décisive parfaite pour déployer Grafana et atteindre ce niveau supérieur d’observabilité tant recherché.

Une plateforme intégrée comme Pandora FMS convient mieux lorsque nous avons besoin de centraliser au sein d’une seule solution la collecte, la découverte et la supervision, avec ou sans agents, ainsi que les réseaux, les applications, les logs, les alertes, les rapports, l’inventaire, l’accès à distance et la gestion opérationnelle.
Avec une plateforme de supervision, tout se trouve sous un même toit, sans devoir assembler une demi-douzaine de projets et prier pour qu’ils continuent à communiquer entre eux au fil des versions. C’est la différence entre construire notre vaisseau pièce par pièce et monter à bord d’un appareil comme Pandora FMS, qui vole déjà à la vitesse de distorsion et dispose également de ses propres tableaux de bord entièrement personnalisables.

Pour comparer ces approches plus en détail, voici un comparatif des outils de supervision ainsi que la présentation des fonctionnalités de Pandora FMS.
La recommandation consiste donc à répondre honnêtement à cette question :

« Quel est notre véritable besoin dans la gestion quotidienne de l’IT ? ».
Nous avons chacun notre propre modèle opérationnel, des éléments auxquels nous ne pouvons pas renoncer, ainsi que des réglementations et des exigences opérationnelles qui déterminent la voie à suivre, et…

• Si nous disposons d’une équipe dédiée et d’un écosystème Prometheus bien établi, Grafana fera briller la lumière que nous apporte le titan Prométhée, qui donne son nom à l’outil.
• Si nous souhaitons une plateforme capable de presque tout faire sans devoir devenir des intégrateurs à temps plein, nous devons nous tourner vers une solution déjà intégrée, comme Pandora FMS ou une autre plateforme de supervision.

Et bien entendu, rien ne nous empêche d’utiliser les deux, comme nous l’avons vu. En réalité, si nous ne sommes soumis à aucune restriction, il s’agit généralement de la meilleure solution.

Questions fréquentes

Nous avons parcouru beaucoup de terrain. Rassemblons donc les questions les plus courantes afin de consolider les points essentiels et de repartir avec une vision précise du sujet.

Grafana est-il un outil de supervision ?

Pas à lui seul, mais il peut faire partie d’un système de supervision, avec des fonctions d’alerte, d’exploration et de visualisation. Pour cela, il a besoin de sources qui lui fournissent les données, car Grafana ne supervise rien par lui-même.

Grafana stocke-t-il des données ?

Normalement, non. Il interroge des données stockées dans des systèmes externes. Certains produits de son écosystème, comme Loki, Tempo ou Mimir, fournissent en revanche les backends de stockage. Cela vaut pour la télémétrie, qui correspond à ce que 90 % des personnes veulent dire lorsqu’elles posent cette question. La configuration propre de Grafana est une autre affaire, car les tableaux de bord, les utilisateurs, les autorisations et les règles d’alerte sont bien stockés dans une base de données interne à Grafana. Par défaut, il s’agit de SQLite, mais MySQL ou PostgreSQL peuvent également être utilisés.

Grafana est-il gratuit ?

Grafana OSS est open source et peut être utilisé sans coûts de licence, tout en gardant à l’esprit ce qu’implique le déploiement d’un logiciel libre et le fait que, pour l’assistance dont nous pourrions avoir besoin par la suite, nous dépendrons de notre propre ingéniosité et de la communauté. Il existe également des éditions Enterprise et Cloud, qui sont payantes et comprennent des fonctionnalités ainsi qu’un support supplémentaires. Elles sont idéales pour les entreprises qui ont impérativement besoin d’un accompagnement fiable en cas de difficultés.

Grafana fonctionne-t-il sans Prometheus ?

Oui. Prometheus est une source de données très populaire, mais Grafana prend également en charge des bases de données, des plateformes cloud et d’autres systèmes de supervision sans aucune difficulté.

Quelle est la différence entre Grafana et un tableau de bord ?

Grafana est la plateforme, tandis qu’un tableau de bord est un ensemble organisé de panneaux et de visualisations au sein de celle-ci. La plateforme contient les tableaux de bord, mais pas l’inverse.

Grafana peut-il superviser des réseaux ?

Une nouvelle fois, il est important de bien nuancer les concepts. Grafana peut visualiser des données réseau et générer des alertes à partir de celles-ci lorsqu’il reçoit les informations d’une source adaptée, mais il n’intègre pas nativement toutes les fonctionnalités d’une plateforme spécialisée de supervision réseau.

Conclusion

Rendons-nous un instant dans le centre de commandement de notre vaisseau IT. Grafana y est un écran extraordinaire, cet immense écran principal situé sur la passerelle de l’Enterprise et capable d’afficher des vaisseaux ennemis, des phénomènes stellaires ou tout autre élément nécessaire. Dans le même esprit, Grafana interroge, explore, visualise et génère des alertes mieux que presque tout le monde. Mais sa valeur dépend entièrement des capteurs qui l’alimentent et de l’ordinateur qui stocke ce qu’il affiche. Si nous lui fournissons des données de qualité, Grafana nous apportera une clarté enviable. Mais si nous lui fournissons du silence, il nous renverra ces zéros aussi élégamment dessinés qu’inutiles. Grafana peut donc servir d’interface à tout un écosystème d’observabilité, et il accomplit ce travail à merveille : à chacun sa spécialité. Ce qu’il ne fait pas, par conception, c’est remplacer une plateforme complète capable de collecter, de découvrir, de corréler et de piloter la supervision de chaque recoin de notre infrastructure IT. C’est pourquoi Grafana et Pandora FMS ne sont pas tant en concurrence qu’ils ne se complètent. Pandora collecte et gère les données, tandis que Grafana ajoute une manière supplémentaire de les observer, particulièrement attrayante à une époque où l’expérience utilisateur est essentielle et où ces utilisateurs ne sont, en outre, plus uniquement des profils techniques. Si nous recherchons une couverture complète, nous voudrons une plateforme intégrée de supervision et d’observabilité qui ne nous oblige pas à assembler nous-mêmes les différentes pièces du puzzle. Dans ce cas, le chemin de briques jaunes nous conduit vers Pandora FMS —ou vers n’importe quelle autre solution de supervision, puisque nous ne craignons de nous mesurer à personne. Et si nous choisissons Grafana, nous savons désormais exactement ce que cet écran observe et ce qui se trouve derrière lui lorsqu’il s’allume.