Im Februar diesen Jahres habe ich einen ersten Beitrag zu meinem kleinen k3s Homelab geschrieben. Seit dem ist echt viel passiert und vieles hat sich verändert und ist hinzu gekommen. Direkt von Anfang an gilt ein großer dank der k8s-at-home Community!

k3s homelab Hardware

Fangen wir wieder mit der Hardware an. Damals primär nur Raspberry Pis ist es jetzt ein Architekturmix geworden. Als Master laufen dreiRaspberry Pi (externer Link) 4 mit 4 GB RAM. Daetcd (externer Link) die SD-Karten zum Frühstück fressen würde, bin ich hier auf128 GB SSDs (externer Link) gewechselt die mittels einesUSB zu SATA Adapters (externer Link) angeschlossen sind.

Als Worker habe ich mir in den letzten Monaten gebrauchte Lenovo Thin Clients gekauft. Zwei davon sind mit 4-Kern Intel i5-6500T, 8 GB RAM, einer 128er SSD für das OS und einer 512 GB NMVe für ceph ausgestattet. Die zwei anderen mit einem Intel i3-6100T, 8 GB RAM und einer 128 GB SSD für das OS. Diese Hardware reicht völlig für ein k3s Homelab aus.

Software

Diese hat sich kaum geändert. Damals Ubuntu 20.04 LTS, heute Ubuntu 21.04 (non-LTS). Die Raspberry Pis haben natürlich die jeweilige 64bit Variante für ARM installiert bekommen.

Cluster-Ressourcen

CSI – Cluster Storage Interface

Longhorn (externer Link) habe ich den Rücken gekehrt. Für kleine Cluster ziemlich brauchbar. Sobald der aber etwas größer wird, bzw. viele Dateien verändert werden kam die Replikation nicht mehr hinterher. Entsprechend vielen häufiger Volumes aus und mussten aus dem sehr gut funktionierenden Backup wiederhergestellt werden.

Als CSI nutze ich mittlerweilerook-ceph. (externer Link) Ceph als unterliegendes verteiltes Dateisystem und rook als Tool um darauf zugreifen zu können. Einige in der Community verwenden auch einen externen Ceph Cluster, z. B. via Proxmox. Rook-ceph ist schön leichtgewichtig, schnell und zuverlässig!

Derzeit ist der Cluster leider „degraded“, weil meine virtuelle Node auf meinem Proxmox Host fehlt.

CNI – Cluster Network Interface

Als CNI benutze ich das default Netzwerk von k3s: flannel. Allerdings lege ich ein LoadBalancer noch oben drüber.

Damals gar nichts dazu geschrieben. Ich gehe mal davon aus das ich auch zu diesem Zeitpunkt bereitsMetalLB (externer Link) verwendet habe. MetalLB stellt mir IP-Adressen zur Verfügung damit externe Geräte auf bestimmte Dienste direkt zugreifen können, ohne Reverse Proxy.

Ingress Controller

Auch hier gab es einen Wechsel. Damals noch ingress-nginx (externer Link) werden heute sämtliche HTTPS Seiten mittelsTraefik (externer Link) publiziert.Traefik liefert mit allerdings nicht die Zertifikate, dies wird weiterhin vom cert-manager übernommen. Natürlich via Let’s encrypt.

Monitoring

Im Bereich Monitoring hat sich am Cluster nichts geändert. Weiterhin wird er kube-prometheus-stack verwendet. Auch wenn der etwas Ressourcenfressend ist, gibt es kaum eine andere Lösung. Prometheus selbst hält die Daten allerdings nur noch sechs Stunden vor. Anschließend werden sie in Thanos bereit gestellt. Grafana greift entsprechend direkt auf Thanos als auf Prometheus zu.

Benachrichtigt werde ich via Alert Manager in einem separatenDiscord (externer Link) -Server. Dieser schickt mittels Webhook entsprechende Informationen über Fehler und deren Behebungsstatus.

Was läuft in meinem k3s Homelab?

Eigentlich alles was ich im Homelab immer so laufen hatte. NAS und Firewall sind weiterhin separiert. Alles andere läuft als Container im Cluster. Ein paar Beispiele

• Home-Assistant (externer Link) incl.Mosquitto (externer Link) MQTT undzwavejs2mqtt (externer Link)
• Teslamate (externer Link) um die Daten unseres Model 3 abzufragen
• Paperless-NG (externer Link) als DMS
• FreshRSS (externer Link) als RSS Reader
• Jellyfin (externer Link) als Mediaplayer
• blocky (externer Link) als Netzwerk Werbeblocker
• u. v. m.

Deployment

Im Februar wollte ich noch nichts zum Deployment der Anwendungen und Container schreiben. Mittlerweile finde ich das Thema sehr interessant und wollte es ganz kurz vorstellen.

Ich verfolge mit dem k3s-homelab einen GitOps Ansatz. Heißt meine komplette Konfiguration aller Container und Dienste befindet sich in einemGitHub Repository (externer Link) . Allerdings nicht als einzelne Kind-Defintionen sondern alsHelm (externer Link) Datei. Sobald ich ein neuen commit im Main-Branch mache wird dies durchFluxCD (externer Link) von meinem Cluster gepullt und die Änderungen übernommen.

Ein Webhook benachrichtigt mich dann viaDiscord (externer Link) über entsprechende Änderungen oder Fehler.

Bei Fragen und Anregungen versuche ich dir natürlich gern zu helfen.

Ich dachte mir, dass ich mal ein paar Worte zu meinem mittlerweile angewachsenen Kubernetes Homelab schreibe. Nicht, dass das irgendwas weltbewegendes wäre, aber sicherlich für den einen oder anderen ein kleiner Denkanstoß oder Inspiration für eigenes.

Hardware

Hardware wird keine dedizierte eingesetzt. Ich habe auf meinem Proxmox Server vier virtuelle Maschinen erstellt. Dazu gesellen sich allerdings derzeit noch zweiRaspberry Pi (externer Link) 4 mit 4 GB RAM.

Software

Als Betriebssystem setze ich durchgehend auf Ubuntu 20.04 LTS. Bei den virtuellen Maschinen natürlich die amd64 und bei denRPi (externer Link) arm64 Variante.

Der Cluster selbst läuft mit Ranchersk3s (externer Link) anstatt eines vollen k8s.

Kubernetes Cluster

Allgemein

Der Cluster selbst besteht aus einem Master und fünf Worker. Ein Multimaster-Setup habe ich mir überlegt, allerdings für den Anfang verworfen. Auch wenn es mit k3s eigentlich ziemlich einfach gehen würde. Zumindest mit externer Datenbank.

Storage

Als Storage setze ich aufLonghorn (externer Link) . Longhorn, auch von Rancher, ist ein distributed block storage welches iSCSI im Hintergrund nutzt. Je Storage Node wird eine dedizierte Festplatte (so zumindest der empfohlene Weg) an den Cluster gereicht und alle Dateien werden entsprechend verteilt. Zwei Hosts sind hier das Minimum. Bei mir werden alle 4 virtuellen Maschinen dafür verwendet.

Ingress

In meinem kleinen k3s Tutorial habe ichTraefik (externer Link) als Ingress eingerichtet. Für meinen produktiven Cluster im Homelab allerdings setze ich aufNGINX (externer Link) . Es liegt einfach an der leichteren Konfiguration für Einsteiger. Traefik ist wie unter Docker sehr mächtig, allerdings hat mich das etwas überfordert, sodass ich mit dem leichteren Beginnen wollte.

Monitoring

Auch hier nutze ich den klassichen Weg und verwende denkube-prometheus-stack (externer Link) . Bohrte den allerdings noch mit etwasLoki (externer Link) auf. Loki ist ein Software um Logdateien aufzubereiten. Ähnlich wie man es vlt. vom Elastik Stack (ELK) kennt.

Ein Alerting via Alertmanager ist noch nicht im Einsatz. Dafür informiert mich Botkube über diverse Cluster-Ereignisse auf einen dedizierten Server.

Besonderheiten

Ich wollte von Anfang an nicht stur yaml-Dateien schreiben und diese mit kubectl in den Cluster jagen. Ich bin früh auf diek8s@home (externer Link) Community gestoßen die sich Rund um das Thema GitOps und Kubernetes im Homelab beschäftigen. Entsprechend wird mein Cluster auch komplett aus einemGitHub Repository (externer Link) gespeist. FluxCD zieht sich diese Daten und deployt sie im Cluster. Alles via Helm.

Das Problem ist noch, dass ich mich noch nicht um das Thema Secrets bemüht habe. Das steht für die nächste Zeit auf der Roadmap. Dann ist es auch möglich Tokens, Zertifikate und ähnliches aufGitHub (externer Link) zu speichern. Im können fast alle Dienste nur aus dem internen Netzwerk heraus erreicht werden.

Was hoste ich?

Ich würde diese Liste einfach mal nach Namespaces aufteilen. Ich liste allerdings nur weitere Software auf die nicht oben beschrieben sind.

home

• Home Assistant mit code-server
• Mosquitto
• Heimdall

network

• MetalLB
• cloudflare-ddns
• ntp

media

• Gaps
• Ombi
• Tautulli
• Plex

Viele meiner Leser wissen es bereits: Ich nutze sehr gerneICINGA2 (externer Link) als meine Monitoring Software. Vor vielen Jahren bin ich von Nagios damals zu ICINGA 1 gewechselt und sehr zeitnah zu Version 2. Entsprechend ist klar, dass mein Homelab Monitoring primär von ICINGA2 durchgeführt wird.

Wie sieht für mich Monitoring aus?

Bevor ich dir mein Homelab Monitoring zeige, möchte ich erst mal auf die Frage eingehen, wie das ganze überhaupt für mich aussehen soll, bzw. was für mich der Sinn und Zweck eines Monitoring ist.

Privat als auch im beruflichen Leben weiß ich gern vor meinen Kunden (Partner:in, Kolleg:innen, externe Kund:innen) ob etwas nicht funktioniert. Realistisch betrachtet gibt es Dinge die man nicht vor anderen wissen kann: zum Beispiel ob das Internet noch funktioniert. 🤷‍♂️ Allerdings ist es im Rahmen der Kommunikation immer ein wesentlicher Vorteil schon zu wissen ob/was nicht richtig funktioniert. Die Kunst ist es hier eine Balance zu finden zwischen Dingen die sinnvoll überwacht werden können und welche einfach nur interessant sind zu wissen. Entsprechend versuche ich viele Dinge zu überwachen und mit sauberen Schwellwerten zu versehen um möglichst frühzeitig ein Problem zu sehen oder gar vor einem Problem eingreifen zu können.

Das gerade angesprochene Beispiel mit der Internetleitung ist so ein Thema. Das Monitoringsystem kann ein Ping auf einen externen Dienst absetzen der quasi immer Verfügbar ist, z. B. Google oder Cloudflare. Auf Grund der Auslastung des Monitoringservers wird der Ping nur nicht durchgehend abgesetzt wie wir es z. B. unter Windows mit dem Parameter-t kennen. Stattdessen wird alle paar Sekunden (oder Minuten) eine Reihe von Pings abgesetzt und hieraus dann ermittelt ob die Internetleitung (bzw. wird ja der Service überprüft) verfügbar ist.

Was monitore ich im Homelab?

Nun kommen wir zur spannenden Frage was ich denn im Homelab überwache. Wie oben bereits geschrieben gibt es für mich kein Grund die Verfügbarkeit der Internetleitung zu überwachen. Es ist immer jemand im Haus der das vor mir erkennen würde. Zudem müsste ich für eine entsprechende Benachrichtigung eine zweite Internetleitung bereit stellen oder ein SMS Gateway anschaffen. Beides für daheim zu großer overhead.

Ansonsten versuche ich alle Infrastrukturdienste zu überwachen, sofern sie durch die jeweilige Software überwachbar sind. Mein DHCP Server ist z. B. in derUnifi (externer Link) USG integriert, hier kann ich den Dienst nicht sauber überwachen, da die Firmware ein geschlossenes System ist.

Anders sieht es z. B. beim Thema Smart Home aus. Hier überwache ich sämtliche Dienste (Home Assistant, zwave to mqtt, zigbee to mqtt, etc) auf deren Ausführung. Ausführung heißt in diesem Falle aber nicht ob die ausführbare Datei gestartet ist, sondern ob der Service wirklich läuft. Ist z. B. das Webfrontend erreichbar oder nimmt der Service auf einem bestimmten Port auch Daten entgegen. Ob das relevante Daten sind, ist hier uninteressant, es geht schließlich einzig und allein um die Verfügbarkeit.

Dazu kommen natürlich noch alle anderen Bereitstellungen wie DMS, Netzwerkspeicher und so weiter. Überall werden, sofern es Sinn macht, natürlich auch Metriken wie CPU oder RAM Auslastung mit protokolliert und grafisch dargestellt.

Homelab Monitoring – Die Software

Wie bereits geschrieben nutze ichICINGA2 (externer Link) als Software. Diese setzt zum Betrieb eine SQL Datenbank voraus. Ich für meinen Teil nutze wo immer es auch geht MariaDB, einfach als persönliche Präferenz.

Alle Metriken bzw. Performancedaten werden in eineInfluxDB Datenbank gespeichert. Die Grafen in ICINGA Web 2 sowohl als auch eigenständige Dashboard werden mittels Grafana realisiert. Dieses greift auf die Influx Datenbank zu und stellt nach meinen Wünschen die Werte grafisch dar.

Wenn du mir schon länger folgst weißt du, dass ich mein Homelab mit ICINGA2 monitore und damit alles im Blick behalte. Seit kurzem setze ich auch FreeIPA als Identity Management ein, also musste ich noch ICINGAWEB2 mitFreeIPA (externer Link) verbinden. Anfangs kein so leichtes unterfangen. Dieses Tutorial hilft dir aber bei deiner ICINGAWEB2 FreeIPA Konfiguration.

Die Installation vonICINGAWEB2 (externer Link) kann ganz regulär nachoffizieller Anleitung (externer Link) durchgeführt werden. Spannend wird es erst, wenn wir das Frontend einrichten möchten. Als Backend nehmen wir entsprechend LDAP und lassen im nächsten Schritt auch schon über Eingabe der Domäne alle Einstellungen suchen.

Eines noch Vorweg: Das ICINGA2 Buch hat mir immer sehr geholfen das System besser zu verstehen und viele Konfigurationen und Anpassungen leicht zu meistern. Solltest du frisch in das Thema einsteigen empfehle ich dir das Buch zu kaufen.

Dies funktioniert natürlich am Besten, wenn man FreeIPA auch direkt als DNS Server einsetzt. Andernfalls kann es sein, dass die Daten nicht korrekt gezogen werden. Eine Anpassung desDNS am ICINGA2 Host ist anschließend notwenig.

Die Einrichtung kann man sogar, wenn man nichts besonderes konfigurieren möchte, einfach immer weiter klicken. Die Konfiguration erfolgt mit dem neuen ICINGAWEB2 Installer fast automatisch.

Nach komplett abgeschlossener Einrichtung müssen wir allerdings noch dieroles.ini Datei anpassen.

[Administrators]
users = "username@domain.tld"
permissions = "*"

Wer möchte passt natürlich noch die Berechtigungen an. In diesem Beispiel ist das mein Administrator-Benutzer, der soll natürlich alle Berechtigungen haben.

Nun können wir über das Frontend bei ICINGAWEB2 anmelden. Als Benutzername müsst ihr den vollqualifizierten Nutzername verwenden. Wie oben in der roles.ini also z. B.

username@domain.tld

Mit dem entsprechenden Passwort zusätzlich eingegeben, habt ihr ein erfolgreichen Login bestritten. Zum Vergleich zeige ich euch noch meine anderen Konfigurationsdateien.

Meine ICINGAWEB2 FreeIPA Konfiguration

Zum Vergleich zeige ich euch noch meine anderen Konfigurationsdateien. Damit sollte es für dich auch möglich sein eine korrekte Verbindung zu FreeIPA durchzuführen.

authentication.ini

[icingaweb2]
user_class = "inetOrgPerson"
filter = ""
user_name_attribute = "uid"
backend = "ldap"
base_dn = "dc=example,dc=com"
domain = "example.com"
resource = "icingaweb_ldap"

groups.ini

[icingaweb2]
resource = "icingaweb_ldap"
user_backend = "icingaweb2"
group_class = "group"
group_filter = ""
group_name_attribute = "gid"
group_member_attribute = "
member"base_dn = ""
backend = "ldap"

ressources.ini

[icingaweb_ldap]
type = "ldap"
hostname = "dc.example.com"
port = "389"
encryption = "none"
root_dn = "dc=example,dc=com"
bind_dn = ""
bind_pw = ""
timeout = "5"

Anschließend sollte der Login problemlos klappen.

Um das Docker Monitoring sollte man sich nicht drücken, denn es ist wichtig zu sehen, welche Auslastung die einzelnen Container verursachen. Zum einen um etwaige Probleme festzustellen und zum anderen um die Leistung des Docker Hosts evtl. anpassen zu können.

In meinemdocker-homelab (externer Link) Repository aufGithub (externer Link) habe ich vor kurzem ein Docker Compose Stack hinzugefügt, welche genau dies macht. Über die Monitoring ToolsPrometheus (externer Link) ,Node Exporter (externer Link) undcAdvisor (externer Link) werden die Daten erfasst und mittelsGrafana (externer Link) ansprechend dargestellt.

Docker Monitoring einrichten

Um das ganze wie im oben gezeigten Dashboard zu realisieren kann man sich meinerdocker-compose.yaml (externer Link) Datei bedienen. Am einfachsten ist es natürlich man verwendet das komplette Repository, weil dort auch alle anderen Dateien für das Docker Monitoring vorhanden sind.

Grundsätzlich reicht es dann mit einem einfachen

docker-compose up -d

den kompletten Monitoring Stack zu starten. Solltest du keinTraefik als Reverse Proxy nutzen kannst du in der docker-compose.yaml Datei auch den Bereich der Labels sowie die Netzwerkdefinition weg lassen.

Anschließend verbindet man sich über den gewünschten Browser mit dem Grafana Dashboard und loggt sich mitadmin/admin dort ein.

Im ersten Schritt muss man nun die Datenquelle hinzufügen. Im Dashboard bedarf es hier nur ein klick. Als Datenquelle verwenden wir entsprechend Prometheus.

Es müssen dann nur die Felder Name und URL gefüllt werden. Sollte das vordefinierte Dashboard aus dem Repository verwendet werden, sollte die Datenquelle den Namen „Prometheus“ tragen. Als URL wirdhttp://mon_prometheus:9090

eingetragen. Es sollte bei dir dann analog zu diesem Screenshot aussehen:

Sobald man aufSave & Test geklickt hat, sollte ein grüner Balken erscheinen der die erfolgreiche Verbindung bestätigt.

Grafana Dashboard importieren

Nun müssen wir nur noch das Grafana Dashboard importieren um das Docker Monitoring zu vervollständigen.

Hierfür klickt man links aufDashboard und anschließend aufmanage.

Über den Button importieren kann man nun diedashboard.json (externer Link) Datei hinzufügen. Es muss dann nur noch die korrekte Datenquelle angegeben werden und schon sollte das Dashboard entsprechend Werte anzeigen.

EinSYNOLOGY (externer Link) NAS mitICINGA2 (externer Link) überwachen erfordert nicht unbedingt ein gesondertes Plugin, da die Systeme auch ohne Probleme direkt via SNMP überwacht werden können. Fertige Plugins haben allerdings den Vorteil, dass sie schneller zum Einrichten und zum anderen übersichtlicher sind.

Bis vor kurzem habe ich immer mit dem Plugin check_synology gearbeitet. Allerdings hatte das bei mir unter verschiedenen Systemen immer mal wieder zu aussetzern geführt. Aus diesem Grund habe ich mich vor ein paar Tagen auf die Suche nach einem neuen CheckPlugins gemacht und bin natürlich fündig geworden.

SYNOLOGY NAS MIT ICINGA2 ÜBERWACHEN

check_synology.py (externer Link) funktioniert ausschließlich mit SNMPv3, bietet also noch mehr Sicherheit als lediglich über SNMPv2 oder gar v1.

Nach dem herunterladen des Plugins und einfügen des CheckCommands (Pluginersteller liefert das glücklicherweise mit), kann man schon anfangen die Service Checks zu schreiben. Meine sehen derzeit so aus:

apply Service "syno-load" {
check_command = "check_synology"
vars.synology_mode = "load"
vars.synology_host = "$address$"
vars.synology_warning = "$synology_load_w$"
vars.synology_critical = "$synology_load_c$"
assign where host.vars.os_type == "DSM"
}
apply Service "syno-memory" {
check_command = "check_synology"
vars.synology_mode = "memory"
vars.synology_host = "$address$"
vars.synology_warning = "$synology_load_w$"
vars.synology_critical = "$synology_load_c$"
assign where host.vars.os_type == "DSM"
}
apply Service "syno-status" {
check_command = "check_synology"
vars.synology_mode = "status"
vars.synology_host = "$address$"
vars.synology_warning = "$synology_load_w$"
vars.synology_critical = "$synology_load_c$"
assign where host.vars.os_type == "DSM"
}
apply Service "syno-disks" {
check_command = "check_synology"
vars.synology_mode = "disk"
vars.synology_host = "$address$"
vars.synology_warning = "$synology_load_w$"
vars.synology_critical = "$synology_load_c$"
assign where host.vars.os_type == "DSM"
}

Anschließend noch die Host Definition

object Host "synology.int.casalani.de" {
check_command = "hostalive"
address = "10.0.1.21"
vars.os_type = "DSM"
vars.synology_snmp_user = "icinga2"
vars.synology_snmp_authkey = "strenggeheim"
vars.synology_snmp_privkey = "strenggeheim"
}

Anschließend noch die config validieren undICINGA2 neu laden. InICINGA (externer Link) Web 2 sieht es dann so aus:

Nach jetzt mehreren Tagen Test, kann ich sagen, dass das Plugin hervorragend funktioniert. Entsprechend meine Weiterempfehlung.

Wer ein Homelab betreibt kommt früher oder später an den Punkt an dem einzelne Dienste vom Teststadium in die Produktion übergehen. Das passiert einfach zwangsläufig und ist auch gern Gang und Gäbe in Unternehmen.

Sobald aber ein Dienst wichtig wird, sollte man ihm auch die nötige Aufmerksamkeit widmen und dafür sorge tragen, dass dieser Dienst auch eine hohe Verfügbarkeit hat.

Am Besten lässt sich das mit diversen Monitoringlösungen realisieren. Ich möchte euch in diesem Beitrag allerdings den ersten Schritt des Verfügbarkeitsmonitorings überspringen und direkt ins Performancemonitoring einsteigen.

Hierfür eignet sich hervorragend der sog. TIG-Stack.
(T)elegraf (externer Link) ,(I)influxDB (externer Link) und(G)rafana (externer Link) bilden hier eine Einheit um einzelnen Metriken der Systeme zusammen, speichern und grafisch aufzubereiten. Ich zeige euch eine beispielhafte Installation unter Ubuntu 16.04 LTS.

Installation der Komponenten

Telegraf und InfluxDB können wir direkt mittels WGET herunter laden.

cd /tmpwget https://dl.influxdata.com/telegraf/releases/telegraf_1.6.2-1_amd64.debwget https://dl.influxdata.com/influxdb/releases/influxdb_1.5.2_amd64.deb```

Anschließend kurz installiert

dpkg -i telegraf_1.6.2-1_amd64.debdpkg -i influxdb_1.5.2_amd64.deb

Die Programme enthalten in der Installation die systemd Skripte und starten beim nächsten Systemstart automatisch mit. Ein manuelles Starten nach der Installation ist nicht notwenig.

Nun installieren wir noch Grafana. Hier empfielt es sich das offizielle Repository einzubinden um es bei Updates leichter zu haben.

vim /etc/apt/sources.list.d/grafana.list

Hier kommt dann folgender Inhalt rein:

deb https://packagecloud.io/grafana/stable/debian/ stretch main

Anschließend noch den PGP Schlüssel installieren

curl https://packagecloud.io/gpg.key | apt-key add -

Nun können wir Grafana installieren und starten

apt update&& apt install grafanasystemctl daemon-reloadsystemctl start grafana-serversystemctl status grafana-server

Einrichtung der Tools

Fangen wir mit der Datenbank an. InfluxDB ist eine sogenannte Time Series Database und entsprechend genau für den Anwendungsfall des Monitorings entwickelt. Wir verbindungen uns mit dem Server:

influx

und erstellen eine neue Datenbank.

create database Telegraf;exit;

Das wars auch schon. Einfach, nich? Dann weiter zu Teletraf.

Telegraf speichert seine Einstellungen in einer Konfigurationsdatei unter /etc/telegraf

vim /etc/telegraf/telegraf.conf

Hier kommentieren wir in Zeile XXX die Verbindung zu InfluxDB aus.

Das Grafana Dashboard

Nun können wir das Grafana Dashboard einrichten. Hierzu öffnet ihr mit eurem Browser die Seite eures Servershttp://{IP}:3000

Zugangsdaten sind bei der Erstinstallationadmin:admin.

Grafana führt einem direkt durch die Einrichtung und die notwendigen Schritt. Als ersten brauchen wir natür eine Datenquelle

Name: Telegraf
Type: Telegraf
HTTP Url: http://127.0.0.1:8086
InfluxDB Details Database: Telegraf

Anschließend aufSave & Test klicken. Es sollte ein grüner Balken auftauchen, dass die Verbindung erfolgreich hergestellt worden ist.

Der nächste Schritt ist ein neues Dashboard anzulegen. Wir starten in diesem neuen Dashboard mit einem Graphen. Klicken oben aufPanel Title und wählenedit aus.

Erstellt eine Abfrage welche anschließend diesen Aufbau hat:

FROMdefaultcpuWHEREcpu=cputotalSELECTfield(usage_system)GROUPBYtime($interval)

Die restlichen Felder könnt ihr leer lassen. Ihr solltet dann oben in der Vorschau auch schon die Anfänge eines Graphen sehen.

Wenn gewünscht können wir nun unterAxes dieUnit aufPercent (0-100) stellen. Weitere Anpassungen können natürlich je nach Wunsch gerne angepasst werden.

Habt ihr das alles soweit eingestellt, klickt ihr oben rechts in der Ecke auf den Pfeil nach links. Anschließend solltet ihr euer Dashboard oben mit der Diskette noch abspeichern. Je nach Wunsch könnt ihr nun die weiteren Werte die Telegraf ausliest noch als Graphen hinzufügen.