Ein Bild sagt mehr als tausend Worte, oder in unserem Fall: Zahlen. Grafana [1] ist dafür bekannt und beliebt, aus langen Zahlenketten schöne Grafiken zu zaubern, die den Anwendern einen schnellen Überblick verschaffen. Operatoren überwachen Systeme und Netzwerke, Investoren betrachten Börsenkurse und private Nutzer senden Sensordaten ihrer Heimautomatisierung an das Tool. Eine einzelne Grafana-Instanz kann auch locker alle drei genannten Datentypen in verschiedene Dashboards packen.

Hinter dem Tool Grafana steht das Unternehmen Grafana Labs, das kommerziellen Support und einen Clouddienst als professionelle Dienstleistung offeriert. Grafana selbst ist Open Source und frei verwendbar. Grafana Labs ergänzt die Funktionen dabei nicht nur um weitere Darstellungen. Um Grafana herum entstehen zusätzliche Projekte, wie beispielsweise der Logaggregator "Loki" [2].

Viele dürften sich fragen, warum ein Tool für die Darstellung von Metriken ausgerechnet mit einem Logaggregator daherkommt, wo es doch seit langem leistungsstarke und etablierte Tools wie Logstash, Fluentd und Elasticsearch gibt. Der Ansatz von Loki ist dabei jedoch ein anderer, denn Logs dienen hier als Quelle für Metriken. Mit der Version 8 verbessert Grafana besonders die Integration von Loki und auch dessen Alert-Funktion, was Administratoren durchaus gefallen dürfte.

Etablierte Logsammler wie Logstash greifen unstrukturierte Logs ab und indizieren diese in Elasticsearch. Damit durchsuchen Anwender ihre Logs nach diversen Kriterien. Allerdings brauchen Elasticsearch und Logstash als Java-Applikationen viel Speicher und CPU-Zeit. Loki verfolgt einen anderen Ansatz. Es indiziert nur wenige Metadaten der ankommenden Logs, wie Host und Applikation, und sichert den Loginhalt roh in so genannten "Chunks". Dies kann in einem lokalen Dateisystem oder einem S3-Speicher erfolgen.

Loki selbst ist in Go geschrieben und kommt als simples, statisch gelinktes Binary daher. Bevorzugt betreibt der Anwender Loki in einem oder mehreren Containern. Einmal gestartet, exportiert Loki lediglich einen API-Port. Über den kann Grafana Informationen mit einer Log-Query (ählich der von Prometheus) abfragen. Loki sammelt keine Logs ein, sondern erwartet, dass Clients wie Promtail ihre Daten an der Loki-API abliefern. Die Integration von Loki in Grafana wandelt über Log-Queries die Loginformationen in aussagekräftige Metriken um. Ein praktisches Beispiel wäre die Logabfrage

rate({app="nginx"}|="error"[5m])

Sie erzeugt einen Metrikwert aus der Anzahl der Logeinträge aller überwachten nginx-Server, die das Wort "error" erhalten, über einen Zeitraum von fünf Minuten. Damit steht dem Administrator nun eine Grafik "Nginx-Fehlerrate" zur Verfügung. Somit lassen sich anhand von Logdaten Metriken zu Applikationen generieren, die von sich aus gar keine Metriken liefern. Passend dazu kann Loki auch Alerts definieren. Liegt beispielsweise die Fehlerrate der nginx-Server über einem Schwellenwert, benachrichtigt Loki einen Alertmanager. Grafana ist seit Version 8 in der Lage, direkt Loki-Alerts abzufangen.

Damit die Logs zu Loki kommen, bedarf es eines Log-Shippers. Das kann eine bestehende Installation beispielsweise mit Logstash übernehmen, die Sie um das Plug-in "Loghstash-Output-Loki" erweitern. Alternativ liefert Grafana das recht simple "promtail". Auch dieses Tool ist in Go geschrieben und kommt als statisch gelinktes einzelnes Binary für diverse CPU-Architekturen unter Linux oder Windows. Die Konfigurationsdatei zu Promtail gibt die Adresse des Loki-Servers und eine oder meherere Logquellen an. Promtail verbindet sich dabei mit einem Systemd-Journal ebenso wie mit einem Syslog-Dienst. Im simpelsten Fall liest es Logdateien aus. Wer beispielsweise das Auditlog überwachen möchte, um Loginfehler nachzuverfolgen, schreibt Folgendes in die Datei "promtail.yaml":

Die Logs kommen dann mit dem Label "local_audit" bei Loki an. Nun können Sie Grafana-Panels wie "Gescheiterte Log-ins pro 10 Minuten" erstellen und erkennen, wenn Ihr Server ins Visier der im Internet üblichen SSH-Attacken geraten ist.

Für diesen Artikel haben wir unter anderem eine lokale Installation auf einem Fedora-34-Host verwendet. Das Setup läuft in Containern mit Podman [3] und den Rollout der Umgebung steuert Ansible. Das Ganze läuft, dank Podman, mit Benutzerrechten und benötigt weder "root" noch "sudo". In der Vorbereitung legen Sie ein Unterverzeichnis im Home-Directory des Benutzers an, in unserem Fall ist das "~/podman/grafana". Darunter generieren Sie drei Verzeichnisse für drei Container: "daten" für die Grafana-Daten. Damit bleibt Ihre Konfiguration auch nach einem Neustart des Containers erhalten. Das Verzeichnis "loki" enthält die Konfiguration von Loki und der Ordner "prom" die von Prometheus. Innerhalb des "loki"-Directories können Sie auch noch ein "rules"-Verzeichnis anlegen, um dort Loki-Alert-Definitionen abzulegen. Laden Sie nun die Demokonfiguration von Loki mit

Wenn Sie Loki-Alerts testen möchten, öffnen Sie die Datei im Editor, suchen nach dem Abschnitt "rules:" und ändern darunter die Zeile "directory:" so ab, dass sie "directory: /etc/loki/rules" lautet. Dann liest Loki die Regeln aus dem Ordner "~/podman/grafana/loki/rules" des Hosts ein. Dort können Sie, auch während der Container läuft, Regeln einfügen oder ändern. Nach dem Anpassen kopieren Sie die Datei unter dem Namen "local-config.yaml" in das zuvor angelegte Loki-Verzeichnis.

Legen Sie im "prom"-Verzeichnis eine Konfigurationsdatei für Prometheus "prometheus.yml" an. Die Prometheus-Dokumentation im Internet hat einige Beispiele parat. Wir verwenden eine minimale "überwache dich selbst"-Konfiguration:

Dann reicht ein simples Ansible-Playbook, um den kompletten Stack via Podman laufen zu lassen in Form von "grafana-test.yml":

Der Aufbau ist denkbar simel: Das Loop-Array enthält die Werte Container-Name, Image-URL, Port, Hostverzeichnis und Container-Verzeichnis. Möchten Sie den Test beispielsweise mit Influx oder Collectd durchführen, müssen Sie nur die passenden Variablen im Playbook ändern oder hinzufügen. Behalten Sie im Hinterkopf, dass Prometheus den Port 9090 nutzt, den auch die Web-Admin-GUI "Cockpit" belegt. Falls diese auf Ihrem Host aktiv ist, müssen Sie sie abschalten, deren Port ändern oder den Prometheus-Container auf einen andern Port als 9090 umkonfigurieren.

Viele Anwender, die sich für Grafana 8 interessieren, verfügen bereits über eine laufende 7.x-Konfiguration. Diese Administratoren möchten vor allem wissen, wie das Update funktioniert und welche Hindernisse sie erwarten. Für unseren Beitrag haben wir insgesamt vier Grafana-Installationen auf die Version 8 angehoben. Alle vier arbeiten mit mindestens einer Influx-Datenbank und zwei Setups sammeln Systemmetriken via Collectd ein. Die Setups laufen wahlweise in libvirt/ovirt-VMs oder LXC-Containern unter Fedora (32 bis 34) oder CentOS/RHEL 7/8.

Alle vier ziehen die Grafana-Version fehlerfrei über ein einfaches yum update von Version 7.x auf 8 aus dem Grafana-OSS-Repository. Eines der containerisierten Setups zeigte direkt nach dem Update kleinere Störungen. Hier und da blieben die Panels mit einem "No Data"-Fehler leer, zeigten aber nach wenigen Minuten wieder die volle Historie. Abhilfe schaffte in diesem Fall, in den Edit-Modus des Panels zu wechseln, eine Änderung auszuführen und das Panel neu zu speichern.

In der Regel modifizieren Sie Ihre Panels ohnehin nach dem Update. Das Standardpanel für Liniengrafiken der Versionen bis 7.x hört nun auf den Namen "Graph (old)". Diese Ansicht ersetzt das neue "time series panel", das bereits abGrafana 7.4 in einer Betaversion zur Verfügung stand. In der Praxis können Sie einfach im laufenden Betrieb die Darstellung von "Graph (Old)" zu "Time series" ändern. Farben, Schwellenwerte und Alarme bleiben dabei erhalten. Die Optik wirkt etwas glatter. Positiv fällt dabei auf, dass Dashboards mit "Time Series"-Panels spürbar schneller laden als die alten Graph-Panels.

Ein mit Grafana 8 neu eingeführtes Panel (noch im Betastatus) ist die "State Timeline", die bei vielen Administratoren klassische Linien-Grafiken ersetzen dürfte. Anstatt Werte in Kurven darzustellen, zeichnet Grafana in der State-Timeline pro Metrik einen breiten Balken, der seine Farbe je nach Wert ändert. Das gibt Operatoren einen raschen Statusüberblick vor allem bei Werten wie Service-Response-Times oder ähnlichen. Die State-Timeline kann dabei selbständig ein Rot-Grün-Schema abhängig vom Minimal- und Maximalwert der Darstellung nutzen oder der Nutzer definiert eigene Schwellenwerte und Farben.

Mit Grafana 8 kommt nun auch eine Funktion, die sich viele Nutzer seit langem wünschen: Library Panels. Sie können bestehende Panels in die Library konvertieren und diese dann parallel in verschiedenen Dashboards nutzen. Ändern Sie die Ansicht in der Bibliothek, ändert sich auch automatisch deren Erscheinen in allen Dashboards, die darauf zugreifen. Das erspart nervige Copy-und-Paste-Aktionen von Panels, die in mehreren Dashboards zum Einsatz kommen sollen.

Nach einem Update auf die Version 8 bleibt das "Alert"-Panel zunächst einmal unverändert, obwohl Grafana genau dort die meisten Änderungen verspricht. Sie müssen die neuen Logfunktionen explizit in der Datei "grafana.ini" angeben, sonst bleibt alles wie gehabt. Der Hersteller möchte damit offenbar vermeiden, dass die neuen Alerts im Zweifelsfall mit alten Definitonen kollidieren und dann "klassische" Alerts nicht auslösen. Um die neuen Funktionen zu aktivieren, fügen Sie in "/etc/grafana/grafana.ini" die folgende Zeile hinzu:

Danach starten Sie den Grafana-Dienst neu. In unserem Setup war dieser Schritt stets reversibel. Wer das Feature ausschaltet, setzt sein System auf die klassischen Alarme zurück. Diese funktionierten in unserer Umgebung weiterhin ohne Änderung. Das neue Alert-Panel verbessert jedoch den Umgang mit den Alarmen. Bislang waren Alarme direkt an Panels und deren Werte gebunden.

Mit dem neuen Alarmsystem kann Grafana jetzt aber auch Alerts ohne direkten Bezug zu den Panels auslösen. In der aktuellen Version beschränken sich diese Alarmquellen auf die eingangs erwähnten Loki-Alerts und Cortex-Alerts aus Prometheus. Die neue Architektur erlaubt Grafana Labs jedoch, in Zukunft weitere Quellen zum Alerting hinzuzufügen.

Das aufpolierte Grafana 8 gefällt vor allem durch neue Graph-Typen und damit auch eine flottere Oberfläche. Das neue Alerting wirkt vielversprechend, auch wenn die Logkollektion und Integration via Loki vielleicht noch nicht bei allen Installationen angekommen ist. Das Konzept, aus Loginformationen Metriken zu generieren, dürfte vielen Administratoren gefallen, wobei es in vielen Rechenzentren wohl bereits eine bestehende Log-Collect-Lösung geben dürfte. Aber hier spricht ja nichts dagegen, die bestehenden Setups mit Export-Plug-ins wie etwa "Loghstash-Output-Loki" zu erweitern.

Positiv fällt ebenfalls auf, dass das Major-Update von Grafana 7 auf 8 in unseren Installationen zu keinen nennenswerten Störungen geführt hat. Auch die alten Alerts funktionierten wie gehabt. Für die anstehende Version 8.1 hat Grafana Labs bereits weitere Neuerungen angekündigt. So soll es ein Geo-Map-Panel mit Kartendarstellung geben. Dann kann Grafana ähnlich wie Kibana nicht nur die Zahl der fehlerhaften SSH-Logins aus den Loki-Logs grafisch darstellen, sondern auch gleich anzeigen, woher die Angriffe stammen.