Die letzten beiden Artikel zum Thema Grafana haben den generellen Umgang mit der Anwendung im Entwicklungsumfeld behandelt.
Dabei sind wir allerdings noch nicht auf den Einsatz in komplexeren Umgebungen eingegangen, was wir in diesem Teil nachholen wollen.

In großen Umgebungen mit vielen Entwicklern in unterschiedlichen Teams ist es, mit Blick auf die technischen Ressourcen, nicht sehr sinnvoll, dass jeder Entwickler seine eigene Grafana Instanz betreibt.
Daher wollen wir in diesem Artikel darauf eingehen welche Möglichkeiten Grafana hinsichtlich Multimandantenfähigkeit bietet, aber auch welche Probleme dabei entstehen können.
Außerdem stellen wir noch zwei Methoden vor, die Dashboards (bzw. Teile davon) wiederverwendbar machen.

Als Vorbereitung auf diesen Artikel solltest Du Teil 1 und Teil 2 sowie den Beitrag zu Helm gelesen haben.

\

Ausgangssituation

Um den Arbeitsaufwand pro Dashboard gering zu halten und die Koordination der Entwicklerteams einfacher zu machen, gibt es sowohl seitens des Inhalts als auch bei der Kennzeichnung der Dashboards Konzepte, die dies möglich machen. Ein paar davon möchten wir Dir hier vorstellen.

\

Strukturierung von Dashboards

Zuerst gehen wir darauf ein wie Du Dashboards generischer gestalten kannst, sodass sie für mehr als eine Anwendung/ein Deployment/ein Cluster verwendet werden können.
\

Variabilität

Im vorherigen Teil haben wir das Thema Variablen schon kurz angeschnitten, aber welches Potential steckt tatsächlich darin?
Um den gesamten Umfang an Möglichkeiten abzudecken, die bei der Definierung und Verwendung von Variablen bestehen, bräuchte es mindestens einen eigenen Blogartikel, daher fassen wir hier zunächst die Grundlagen zusammen.

Variablen können in Panel-Titeln und bei der Abfrage von Metriken verwendet werden. Dabei gibt es Grundsätzlich zwei Arten eine Variable einzubinden:

1. $variable, einfacher zu lesen/schreiben
   Bsp.: http_requests_total{handler=~"$handler"}

2. [[variable]], kann innerhalb eines Wortes verwendet werden
   Bsp.: Kubernetes [[name]]dashboard

Bei der Erstellung der zugehörigen Variablen steht eine Vielzahl von Möglichkeiten zur Verfügung.
Von “versteckten” Konstanten zur einfacheren Änderung vieler Queries, über Nutzereingaben, bis hin zur dynamischen Befüllung durch Datasource-Queries.

Grafana formatiert die Belegung der Variablen bei der Interpolation nach Mustern, die auf die jeweilige Datasource angepasst sind. Falls das einmal nicht Deinen Anforderungen gerecht werden sollte, kannst Du über ${variable:format} ein anderes Format angeben.

Ein weiteres Feature lässt sich nutzen, sobald Du in der Konfiguration einer Variable “Multi-value” aktiviert hast. Dann bietet Grafana unter [Panel] > General > Repeating die Möglichkeit das Panel in Abhängigkeit dieser Variable wiederholt einzufügen - für jeden gewählten Wert ein Mal.

Eine ausführliche Erklärung zu Variablen, findest Du in der Dokumentation von Grafana.
\

Templatisierung

Eine Methode, die es ermöglicht Dashboards schneller zu erstellen und sich auch mit Variablen kombinieren lässt, ist die Templatisierung von sich häufig wiederholenden Dashboard-Elementen.
Dafür bieten sich Bibliotheken wie grafana-dash-gen (JavaScript) oder grafanalib (Python) an.

Beide bieten die Möglichkeit sich mit der Zeit eigene Template-Teile zu definieren, was die Erstellung neuer Dashboards erheblich beschleunigen kann, da es mit etwas Übung nicht mehr notwendig ist das Dashboard in der UI von Grafana zu sehen.

Die Benutzung der Bibliotheken ist in den jeweiligen Repositories am besten beschrieben.

\

Organisation von Entwicklerteams

Wie oben beschrieben ist es nicht sehr effizient, wenn jeder Entwickler seine eigene Grafana-Instanz betreibt. Während es kein Problem ist eine einzige Prometheus-Instanz zu nutzen, gestaltet sich dies bei Grafana schwieriger.

Zwar ist es, dank des in Grafana und Helm - Teil 2 erwähnten Sidecars für Doshboards, sehr einfach neue Dashboards einzufügen und diese zu bearbeiten ohne das Grafana Deployment anzufassen, allerdings entsteht dabei ein anderes Problem.
Hat man beispielsweise die drei Stages Development, Testing und Production und pro Stage ein Grafana, besteht - je nach Anzahl an Entwicklern in der Stage - die Gefahr die Übersicht über die Dashboards zu verlieren.

Zunächst sei gesagt, dass es nicht die Lösung gibt um dieses Problem zu beheben, wir möchten hier lediglich ein paar Anregungen liefern, um eine den individuellen Bedürfnissen angepasste Lösung zu finden.

Um eine vernünftige Struktur in die Dashbaords zu bringen ist es ein guter Anfang Tags zu benutzen. Anhand dieser kannst Du die Dashboards später filtern und so die Übersichtlichkeit verbessern.
Tags eignen sich allerdings nicht zur Zugriffskontrolle!

Aus Grafana und Helm - Teil 1 erinnerst Du Dich vielleicht an die Labels zur Selektion der zu importierenden Dashboards. Helm bietet die Möglichkeit diese zu variabilisieren und beispielsweise in Abhängigkeit von values.yaml unterschiedliche Labels zu setzen. Dabei kommt es darauf an welche Bezeichnung das Label hat und nicht welchen Wert.
Doch auch dies lässt sich nicht zur Zugriffskontrolle nutzen, allerdings kann es im weiteren Verlauf helfen ohne großen Aufwand unterschiedliche Sets von Dashboards zusammen zu deployen.

Wenn Du den Zugriff auf die Dashboards beschränken möchtest, geht das gut über Rollen und Ordner sowie Ordnerzugriffsrechte.
Darüber kannst Du unterschiedlichen Teams jeweils ihre eigenen “Arbeitsbereiche” zuweisen, ohne dass sie mit anderen kollidieren.
Allerdings hat auch diese Methode ihre Nachteile. Dashboards können nicht über ihr JSON Model einem Ordner zugewiesen werden, sondern müssen entweder immer wieder manuell verschoben werden - was offensichtlich keine realistische Alternative ist - oder Du benutzt das API. Letzteres kann Dashboards identifizieren und in Ordner verschieben. Am einfachsten ist es wahrscheinlich ein kleines Script zu entwickeln, was diesen Vorgang automatisiert.
Außerdem ist hierbei zu beachten, dass die Restriktionen den Zugriff betreffend nur für eine laufende Grafana Instanz gelten und nicht für den Code.

Soweit unsere Erfahrungen mit Multimandantenfähigkeit bei Grafana. Mehr dazu kannst Du in der oben bereits erwähnten Grafana Dokumentation nachlesen.

\

Good-To-Know

An dieser Stelle möchten wir noch kurz auf ein paar Dinge hinweisen, die auf den ersten Blick vermutlich nicht direkt klar sind.

• Gerade bei der kombinierten Verwendung von Variablen und Templatisierungs-Bibliotheken, kann es unter Umständen sehr aufwändig sein den Überblick zu behalten bzw. Änderungen vorzunehmen.

• Datasources werden zur Laufzeit nicht automatisch über das Sidecar erkannt. Nimmt ein Entwickler Änderungen an einer Datasource vor, muss Grafana neu deployt werden, um die Änderungen wirksam zu machen.

• Plugins lassen sich nur von der offiziellen Grafana Plugin Sammlung oder über extraVolumeMounts einbinden. Keine der Möglichkeiten unterstützt eine Angabe der gewünschten Version.
  
  \

Fazit

Abschließend können wir sagen, dass Grafana in Kombination mit Helm viele gute Möglichkeiten bietet, die einem das Development der Dashboards vereinfachen können. Sobald es allerdings um den Einsatz in einem komplexeren Umfeld geht, steigt der Aufwand eine akzeptable Lösung zu finden stark an.
In solch einem Fall bietet sich vermutlich ein Mittelweg zwischen “Eine Instanz pro Entwickler” und “Eine Instanz für alle” an.

Du hast wenig Erfahrung im Umgang mit Grafana, Helm und Kubernetes und möchtest das ändern? Dann würden wir uns freuen Dich in einem unserer Trainings begrüßen zu dürfen.

- Jan