- Die Grafana-Produktfamilie stellt zentrale Komponenten in kurzen Abständen häufig ein oder ersetzt sie, wodurch eine Struktur entsteht, die für den langfristigen Betrieb ungeeignet ist
- Mit jeder neuen Lösung ändern sich Konfigurationsweise, DSL, Helm-Charts und Operatoren immer wieder, was eine stabile Wartung erschwert
- Im Prometheus-Operator-Ökosystem besteht keine vollständige CRD-Kompatibilität:
ServiceMonitor und PodMonitor funktionieren, aber bei Kernfunktionen wie AlertmanagerConfig entstehen Unterstützungslücken
- Mimir 3.0 führt Apache Kafka als erzwungene Abhängigkeit ein und erhöht damit die Cluster-Komplexität und den Betriebsaufwand erheblich
- In Grafana Cloud sowie in der gesamten Produktfamilie aus Mimir, Loki und Grafana ändern sich Konfigurationsorte und Endpoints leicht, sodass sich eine einmal aufgebaute Umgebung nur schwer langfristig nutzen lässt
Häufige strukturelle Änderungen in der Grafana-Produktfamilie
- Zentrale Funktionen wie Grafana Agent, Flow Mode und OnCall werden immer wieder innerhalb von 1–3 Jahren eingestellt oder ersetzt
- Die auf Angular basierende Grafana-Oberfläche wurde auf React umgestellt, wodurch ein erheblicher Teil der bestehenden Dashboards kaputtging
- Einige Helm-Charts werden nicht mehr gepflegt
Mehr Komplexität durch die Einführung von Alloy
- Grafana Alloy, das als All-in-one-Lösung vermarktet wird, hat den bisherigen Agent ersetzt, brachte anfangs jedoch Stabilitätsprobleme mit sich
- Es verwendet eine eigene DSL (ähnlich HCL) und trennt sich damit vom bisherigen YAML-basierten Ablauf
- Mit dem zusätzlichen Alloy Operator werden die Komponenten noch komplexer
Unvollständige Abstimmung mit dem Prometheus-Operator-Ökosystem
- Die K8s-Monitoring-Standards
ServiceMonitor und PodMonitor werden unterstützt, aber
PrometheusRules erfordert zusätzliche KonfigurationAlertmanagerConfig wird nicht unterstützt- Da Mimir einen eigenen Alertmanager verwendet, entstehen Versionsunterschiede und Detailinkompatibilitäten
Einführung der Kafka-Abhängigkeit in Mimir 3.0
- Obwohl eine höhere Skalierbarkeit als bisher angestrebt wird,
- wurde Kafka als Pflichtbestandteil der Kernarchitektur hinzugefügt, was den Betriebsaufwand deutlich erhöht
- die Komplexität wächst exponentiell: von einer einzelnen Helm-Installation hin zur Abstimmung mehrerer Komponenten
Ein Ökosystem, das sich nur schwer stabil betreiben lässt
- Der Ingestion-Endpoint von Grafana Cloud ist durch die Einführung eines neuen Verwaltungssystems noch schwerer zu finden
- Die Upgrade- und Abkündigungszyklen zentraler Komponenten sind so schnell, dass dies nicht zu Organisationen passt, die „langweilig stabiles Monitoring“ wollen
- Weniger die Technik selbst als vielmehr die Art des Produktmanagements und das hohe Veränderungstempo untergraben die Zuverlässigkeit
5 Kommentare
Das standardmäßig von influxdb bereitgestellte Dashboard ist auch ganz brauchbar, wenn man es nur einfach nutzen will.
Ich kann nachvollziehen, dass Grafana nicht besonders gut ist, aber gibt es außer Grafana etwas, das so viele Datenquellen unterstützt und das man empfehlen könnte?
Es gibt wohl nicht wirklich eine passende Alternative.
Anscheinend gibt es auch bei Grafana viele Leute, die befördert werden oder ihren Lebenslauf aufhübschen wollen.
Hacker-News-Kommentare
Ich überlege aus denselben Gründen wie der Autor ernsthaft, Grafana komplett aufzugeben
Jedes Jahr Dashboards neu bauen, Alerts neu konfigurieren und neuen Features hinterherlaufen zu müssen, ist ermüdend
Ich möchte eigentlich nur benachrichtigt werden, wenn ein Service ausfällt, und dieselbe Dashboard-Definition 10 Jahre lang beibehalten können, solange sich Datenquellen oder Metriken nicht ändern
Früher gab es in der Seitenleiste nur 4–5 wichtige Links, heute gibt es so viele Untermenüs in Menüs, dass selbst die Grundfunktionen (Dashboards, Alerts) schwer zu finden sind
Eine UI, die man vielleicht einmal im Monat sieht, jedes Mal neu lernen zu müssen, ist extrem ineffizient
Wenn Services nur eine Lebensdauer von 2–3 Jahren haben und man mehrere Produkte aufeinanderstapelt, wächst am Ende nur der Berg an Technical Debt
Dass man praktisch jedes Quartal etwas Großes austauschen muss, ist schmerzhaft
Mimir ist ein System, das für Metrikmengen in einer völlig anderen Größenordnung entwickelt wurde
Auf diesem Niveau wird Kafka tatsächlich benötigt
Aber die meisten Nutzer brauchen diese Skalierbarkeit nicht
Wenn man Mimir nicht auf einem dedizierten Kubernetes-Cluster betreibt, ist es überengineert
Dann ist es realistischer, einfach Prometheus zu verwenden
Selbst im Single-Instance-Modus läuft es erstaunlich gut, und skalieren lässt es sich sehr einfach
Ich habe es in mehreren Organisationen und persönlichen Projekten genutzt und war immer zufrieden
Aber AWS Amazon Managed Prometheus basiert auf Cortex, und OpenObserve läuft bereits im Petabyte-Bereich
Ideal wäre etwas, das sich als Single Binary einfach bereitstellen lässt, mit OpenTelemetry kompatibel ist und einen späteren Wechsel zu einem anderen OTEL-Anbieter erlaubt
Wenn man eine neue OTEL-basierte Lösung aufbauen würde: Welche Alternative zu Prometheus/Grafana wäre am vielversprechendsten?
Um Logs und Traces zu verarbeiten, brauchten wir zusätzliche komplexe Komponenten
Deshalb sind wir auf GreptimeDB gestoßen, womit sich Metriken, Logs und Traces integriert verarbeiten lassen
Die Erfassung läuft über OpenTelemetry, die Visualisierung über Grafana
Da sich Dashboards mit SQL bauen lassen, passt das gut zu den Fähigkeiten unseres Teams
Dank der einfachen Struktur ist das für uns als Platform Engineers sehr zufriedenstellend
Es wurde entwickelt, um die Komplexität von Grafana und Elastic zu lösen, und kann Logs, Metriken, Traces, Dashboards und Alerts in einem einzigen Container verarbeiten
(Der Verfasser ist Maintainer von OpenObserve)
Es ist Open Source, wird aktiv weiterentwickelt, und auch die Kommunikation des Teams ist gut
Viele Nutzer wechseln dorthin, weil sie die Komplexität von Grafana vermeiden wollen, bei dem man mehrere Backends direkt handhaben muss
(Der Verfasser ist Maintainer von SigNoz)
Ich verstehe nicht, warum Entwickler jede Woche ihr Setup ändern und dem neuesten Trend hinterherlaufen
Ich nutze die Kombination Grafana + Prometheus seit 2017, und sie funktioniert immer noch gut
Ich aktualisiere nur alle 1–2 Jahre auf eine LTS-Version
Die Dashboards sind immer noch perfekt, und es gibt keinerlei Probleme
Für die meisten Menschen ist diese langweilige, aber stabile Kombination die beste Wahl
Ich würde gerne wissen, ob ihr einfach weiter eine alte Version nutzt
Gibt es im Open-Source-Bereich einen Dashboard-Builder, der Grafana ersetzen kann? Auch bei uns im Unternehmen wird Grafana breit eingesetzt
Oder man nutzt Prometheus-Console-Templates oder die eingebauten Dashboards von VictoriaMetrics, aber die Funktionen sind deutlich eingeschränkter
Die Grafana-Dashboards selbst sind in Kombination mit VictoriaMetrics + ClickHouse durchaus angenehm zu nutzen
Ich erinnere mich nur noch vage an Namen wie RRD und Nagios
Die ständigen Veränderungen bei Grafana haben eher dazu geführt, dass man sich daran gewöhnt
Bei jedem Major Release gehen Dashboards kaputt oder die UI ändert sich, aber man nimmt es einfach hin
Das eigentliche Problem ist der PromQL-Lock-in von Prometheus
Wenn man Metriknamen ändert, muss man alle Regeln, Alerts und Dashboards anpassen
PromQL wirft außer bei Syntaxfehlern kaum Fehler aus, deshalb braucht man Werkzeuge wie pint zur Validierung
Für Deployments auf einem einzelnen Server nutze ich häufig Prometheus Pushgateway + Grafana als docker-compose-Template
Das ist einfach und funktioniert gut, aber sobald die Metrikmenge wächst, explodiert die Komplexität
Wenn Prometheus ein effizienteres Übertragungsformat beibehalten hätte, wäre dieses Problem weniger gravierend
Gäbe es statt des Textformats ein kompaktes binäres Metrikformat, könnte man auch Millionen von Labels problemlos verarbeiten
SigNoz ist eine gute Wahl und wird aktiv weiterentwickelt
Früher habe ich viel Geld für Cloud-Observability-Plattformen ausgegeben, heute betreibe ich self-hosted SigNoz auf einer Hetzner-Box und komme mit 10 US-Dollar im Monat aus
Prometheus und Grafana wollten jeweils zu einer Full-Stack-Lösung werden, und mit dem Auftauchen von OTEL ist die Lage noch komplizierter geworden
OTEL ist ein Protokoll für Metriken, Traces und Logs, aber es gibt keine einzelne DB, die all das unterstützt
Meist kombiniert man Prometheus (Metriken) + OpenSearch (Logs)
Letztlich bedeutet OTEL also, dass man den Collector austauschen und neu konfigurieren muss