- La suite de produits Grafana abandonne ou remplace fréquemment ses composants majeurs à un rythme soutenu, ce qui crée une structure difficile à exploiter sur le long terme
- À chaque adoption d’une nouvelle solution, les méthodes de configuration, le DSL, les chart Helm et les Operator changent à répétition, rendant la maintenance stable difficile
- La compatibilité avec l’écosystème Prometheus Operator et les CRD n’est pas complète :
ServiceMonitor et PodMonitor fonctionnent, mais des fonctions essentielles comme AlertmanagerConfig restent non prises en charge
- Mimir 3.0 ajoute de manière imposée une dépendance à Apache Kafka, ce qui augmente fortement la complexité du cluster et la charge d’exploitation
- Dans Grafana Cloud ainsi que dans l’ensemble de la gamme Mimir, Loki et Grafana, l’emplacement des paramètres et les endpoints changent facilement, ce qui reproduit un schéma où il est difficile de construire une plateforme durable
Changements structurels fréquents dans la suite Grafana
- Des fonctions clés comme Grafana Agent, Flow Mode ou OnCall sont abandonnées ou remplacées en 1 à 3 ans, et ce scénario se répète
- L’interface Grafana basée sur Angular a été migrée vers React, ce qui a cassé une part importante des tableaux de bord existants
- Certains chart Helm ne sont désormais plus maintenus
Une complexité accrue avec l’adoption d’Alloy
- Grafana Alloy, présenté comme une solution tout-en-un, a remplacé l’Agent existant, mais a connu des problèmes de stabilité à ses débuts
- Il utilise son propre DSL (proche de HCL), rompant avec le flux de travail précédent basé sur YAML
- L’ajout d’un Alloy Operator complexifie encore davantage l’ensemble
Une compatibilité incomplète avec l’écosystème Prometheus Operator
- Les standards de monitoring K8s que sont
ServiceMonitor et PodMonitor sont pris en charge, mais
PrometheusRules nécessite une configuration supplémentaireAlertmanagerConfig n’est pas pris en charge- Mimir utilise son propre Alertmanager, ce qui entraîne des écarts de version et des incompatibilités de détail
L’introduction d’une dépendance à Kafka dans Mimir 3.0
- L’objectif était d’offrir une scalabilité supérieure à l’existant, mais
- Kafka devient un composant obligatoire au cœur de l’architecture, ce qui fait fortement monter la difficulté opérationnelle
- On passe d’une installation Helm unique à l’orchestration de multiples composants, avec une complexité qui augmente de façon exponentielle
Un écosystème difficile à utiliser de façon stable
- L’ingestion endpoint de Grafana Cloud est devenue plus difficile à localiser avec l’introduction d’un nouveau système d’administration
- Le rythme rapide de mise à niveau et d’abandon des composants clés ne convient pas aux organisations qui recherchent un « monitoring ennuyeux mais stable »
- Plus que la technologie elle-même, la manière de gérer les produits et la vitesse du changement constituent le principal facteur qui affaiblit la confiance
5 commentaires
Le tableau de bord fourni par défaut dans influxdb est aussi assez utilisable pour des besoins simples.
Je comprends les critiques sur Grafana, mais y aurait-il d’autres solutions recommandables qui prennent en charge autant de sources de données que Grafana ?
Il n’y a pas vraiment d’alternative, malheureusement.
On dirait qu’il y avait aussi chez Grafana pas mal de gens qui voulaient une promotion ou embellir leur CV.
Avis Hacker News
Pour les mêmes raisons que l’auteur, j’envisage sérieusement de laisser complètement tomber Grafana
Devoir refaire les dashboards chaque année, reconfigurer les alertes et suivre les nouvelles fonctionnalités, c’est épuisant
J’aimerais simplement être averti quand le service tombe, et pouvoir garder la même définition de dashboard pendant 10 ans tant que les sources de données ou les métriques ne changent pas
Avant, il n’y avait que 4 ou 5 liens importants dans la barre latérale, alors que maintenant il y a trop de sous-menus dans les menus, au point qu’il devient difficile de trouver les fonctions de base (dashboards, alertes)
Devoir réapprendre l’interface à chaque fois pour une UI qu’on ne regarde qu’une fois par mois est terriblement inefficace
Quand la durée de vie des services n’est que de 2 à 3 ans, empiler plusieurs produits donne au final l’impression de ne faire qu’agrandir une montagne de dette technique
La réalité où il faut remplacer quelque chose d’important chaque trimestre est pénible
Mimir est un système conçu pour traiter des métriques à une toute autre échelle
À ce niveau, Kafka est réellement nécessaire
Mais la plupart des utilisateurs n’ont pas besoin d’une telle scalabilité
Si vous ne faites pas tourner Mimir sur un cluster Kubernetes dédié, c’est une architecture excessive
Utiliser simplement Prometheus est plus réaliste
Même en mode instance unique, ça fonctionne étonnamment bien, et la montée en charge est très facile
Je l’ai utilisé dans plusieurs organisations et projets personnels, et j’en ai toujours été satisfait
Pourtant, Amazon Managed Prometheus d’AWS est basé sur Cortex, et OpenObserve tourne déjà à l’échelle du pétaoctet
L’idéal serait quelque chose de simple à déployer en binaire unique, compatible avec OpenTelemetry, et qui permette plus tard de migrer vers un autre fournisseur OTEL
Si on construisait une nouvelle solution sur une base OTEL, je me demande quelle alternative à Prometheus/Grafana serait la plus prometteuse
Il fallait en plus davantage de composants complexes pour gérer les logs et les traces
C’est comme ça que nous avons découvert GreptimeDB, qui permet une gestion unifiée des métriques, logs et traces
La collecte se fait avec OpenTelemetry et la visualisation avec Grafana
Le fait de pouvoir créer des dashboards en SQL correspond bien aux compétences de l’équipe
En tant qu’ingénieur plateforme, cette simplicité structurelle me satisfait
Il a été conçu pour résoudre la complexité de Grafana et d’Elastic, et peut tout gérer en conteneur unique : logs, métriques, traces, dashboards et alertes
(l’auteur du commentaire est mainteneur d’OpenObserve)
C’est open source, activement développé, et la communication de l’équipe est bonne
Beaucoup d’utilisateurs migrent pour éviter la complexité de Grafana, qui oblige à manipuler directement plusieurs backends
(l’auteur du commentaire est mainteneur de SigNoz)
Je ne comprends pas pourquoi les développeurs changent leur setup chaque semaine pour courir après les dernières technos
J’utilise le duo Grafana + Prometheus depuis 2017, et ça fonctionne toujours très bien
Je ne fais les mises à jour qu’une fois tous les 1 à 2 ans, uniquement vers des versions LTS
Les dashboards sont toujours parfaits, sans aucun problème
Pour la plupart des gens, cette combinaison ennuyeuse mais stable est la meilleure option
J’aimerais savoir si vous utilisez simplement encore une ancienne version
Existe-t-il un constructeur de dashboards open source capable de remplacer Grafana ? Mon entreprise aussi utilise largement Grafana
Sinon, on peut utiliser les templates de console Prometheus ou les dashboards intégrés de VictoriaMetrics, mais les fonctionnalités sont bien plus limitées
Les dashboards Grafana eux-mêmes restent assez agréables avec une combinaison VictoriaMetrics + ClickHouse
Je me souviens vaguement de noms comme RRD ou Nagios
Les changements permanents de Grafana ont fini par me rendre blasé
À chaque major release, les dashboards cassent ou l’UI change, mais on finit par s’y habituer
Le vrai problème, c’est le lock-in PromQL de Prometheus
Si on renomme les métriques, il faut modifier toutes les règles, alertes et dashboards
PromQL ne renvoie presque jamais d’erreur en dehors des erreurs de syntaxe, donc il faut valider avec des outils comme pint
Pour un déploiement sur serveur unique, j’utilise souvent Prometheus Pushgateway + Grafana avec un template docker-compose
C’est simple et ça fonctionne bien, mais dès que le volume de métriques augmente, la complexité explose
Si Prometheus avait conservé un format de transport plus efficace, ce problème serait moins sévère
Avec un format binaire de métriques compact au lieu du format texte, il pourrait probablement gérer sans difficulté des millions de labels
SigNoz est un bon choix et le projet est activement développé
Avant, je dépensais beaucoup pour des plateformes cloud d’observabilité, mais maintenant j’utilise SigNoz auto-hébergé sur une machine Hetzner pour 10 $ par mois
Prometheus et Grafana visaient chacun une solution full-stack, puis OTEL est arrivé et a complexifié le paysage
OTEL est un protocole pour les métriques, traces et logs, mais il n’existe pas de base de données unique qui prenne tout cela en charge
La plupart des gens combinent Prometheus (métriques) + OpenSearch (logs)
Au final, OTEL impose surtout de remplacer et reconfigurer les collecteurs