Thomas Kramer

IT-COW | Monitoring mit Grafana

Monitoring mit Grafana

By Administrator at März 12, 2023 03:41
Filed Under:

Ende 2016 hatte ich den Lowend-Mini-PC Z83 II von Bqeel mit Intel Atom x5-Z8350-Prozessor gekauft, der PC verfügt über 2 GB RAM und 32 GB Flash. Die Beelink Z83 TV Box sieht äußerlich und von den technischen Daten her identisch aus, wahrscheinlich sind die beiden Geräte baugleich.

 

Die Benutzung mit dem vorinstallierten Windows 10 wurde mir dann aber doch zu langsam, und der geringe Speicher bereitete bei den Windows-Updates auch Probleme. So lag die Box dann jahrelang ungenutzt im Keller herum. Vor ein paar Monaten habe ich dann aber nach einem sinnvollen Einsatzzweck für das Gerät gesucht.

 

Zuerst hatte ich Batocera auf dem Gerät getestet, das führte aber zu plötzlichen Hängern im Betrieb. Danach hatte ich mal Linux Mint auf dem Gerät installiert, das zeigte aber dieselbe Symptomatik – Freezes nach spätestens einer Stunde Betriebszeit. Ich vermutete eine grundlegende Inkompatibilität mit Linux, daher hatte ich mal nach alternativen Betriebssystemen gesucht.

 

Ich stieß auf interessante FreeBSD-Derivate wie GhostBSD und NomadBSD, von denen ich noch nie zuvor gehört hatte. Interessant ist auch Tribblix, das auf Illumos basiert, einem Fork von OpenSolaris. Anders als die anderen Illumos-Distributionen wie OmniOS und OpenIndiana adressiert Tribblix eher den Einsatz als Desktop-Distribution und wird von nur einer Person entwickelt.

 

Den Systemen war gemein dass sie Treiber-Probleme mit der Hardware hatten und den integrierten Flash-Speicher nicht erkennen konnten, das System sich also nicht installieren ließ. Für den Desktop-Einsatz ist die Rechenleistung des PCs ohnehin zu gering, daher zog ich den Einsatzzweck als Server unter Ubuntu Server in Betracht. Denn terminal-basierende Server benötigen unter Linux erstaunlich wenig Rechenleistung; sie werden ja auch vielfach auf den Raspberries benutzt.

 

Dann habe ich Ubuntu 22.04 in der Server-Variante auf dem Gerät installiert. Irritierend war dabei zunächst, dass der Installer scheinbar automatisch zum nächsten Schritt übergeht, wenn keine Eingaben vorgenommen werden. Unter dem System läuft das Gerät aber seit Wochen stabil im Dauerbetrieb und erwärmt sich dabei kaum. Stabilitätsprobleme konnte ich keine mehr entdecken, aber mir ist aufgefallen dass Lesefehler geloggt wurden sobald ich eine SD-Karte in den Kartenleser steckte. Die Karte war dabei übrigens noch leer.

 

Ein Monitoring-System mit Prometheus und Grafana fiel mir als Einsatzzweck für den PC ein. Ich habe zwar auch einen Intel NUC unter Proxmox im Einsatz, aber es macht schon Sinn dass ein Monitoring-System auf einem anderen PC als die zu überwachenden Geräte läuft. Übrigens hatte ich vor 12 Jahren mal Icinga als Monitoring-System getestet, aber habe schon lange keine laufende Installation dazu mehr im Einsatz. Ein paar grundlegende Metriken bietet Proxmox natürlich auch direkt an, aber der Node Exporter unter Prometheus erfasst schon mehr Daten.

 

Konkret habe ich momentan zwei Monitoring-Szenarien im Einsatz:

1. Monitoring der VMs, die unter Proxmox laufen

2. Monitoring meiner Docker-Container, die in einem LXC-Container unter Proxmox laufen

 

Für das Monitoring der VMs werden als Techniken der Node Exporter zusammen mit der Prometheus-Datenbank benutzt, als Anleitungen habe ich die Artikel bei Geekflare, devopscube.com und natürlich bei der Prometheus-Seite benutzt. Die Installation von Prometheus war einfach, denn beim Aufsetzen von Ubuntu Server konnte man bereits zusätzliche Pakete auswählen.

 

Die Installation des Node Exporters geschieht natürlich auf den zu überwachenden virtuellen Maschinen. Bei der Installation des Node Exporters muss man den wget-Befehl aus der Anleitung natürlich auf die URL der aktuellen Version aus dem Github-Repository anpassen. Den Node Exporter runterladen, einen Betriebssystem-Benutzer anlegen unter dem der Dienst laufen soll und anschließend den systemd-Dienst selber anlegen, das geht recht schnell von der Hand. Der Befehl

systemctl enable node_exporter

fehlte noch in der Anleitung, damit der Dienst automatisch beim Reboot gestartet wird.

 

Prometheus greift die Daten ab, die der Node Exporter über http und den Port 9100 ausliefert. Unter Ubuntu Server musste ich erst die genaue Bezeichnung des Prometheus-Dienstes mit systemctl status auslesen, diese lautet snap.prometheus.prometheus.service. Entsprechend lässt sich mit “systemctl status snap.prometheus.prometheus.service” der Status des Dienstes auslesen, da es als Snap-Paket installiert wurde.

 

Die Einstellungsdatei prometheus.yml musste ich auch erst suchen, die liegt unter /var/snap/prometheus/86/prometheus.yml. Dort fügt man die Zeilen

 

- job_name: '$Name'
   static_configs:
     - targets: ['$IP:9100']

 

für jede zu überwachende VM hinzu und startet anschließend Prometheus mit

systemctl restart snap.prometheus.prometheus.service

neu. Anschließend kontrolliert man nochmal den Status des systemd-Dienstes direkt und über die Weboberfläche auf Port 9090 unter “Service Discovery”.

 

Um meine Docker-Container zu überwachen installierte ich InfluxDB und Telegraf auf meinem Server. Theoretisch reicht dafür ein einfaches “apt install influxdb”, aber in den Ubuntu-Repositories wird noch die veraltete Version 1.6.7 der InfluxDB angeboten obwohl es schon längst die Version 2.6.1 gibt. Die 2er-Version hat auch ein schönes Webinterface, ähnlich Grafana.

 

Die Anleitungen für die Installation der InfluxDB auf Seiten wie devconnected.com, zeropage.io, cyberithub.com oder computingforgeeks.com sind dabei zum Teil bereits veraltet, weil sich laut influxdata.com am 26.01.2023 der GPG-Key für den Zugriff auf ihr Repository geändert hat. Trotzdem sind die Anleitungen noch hilfreich, nachfolgend verlinke ich auch noch eine deutschsprachige Anleitung von howtoforge.

 

In den alten Anleitungen wird über

https://repos.influxdata.com/influxdb.key

der alte Key heruntergeladen, der neue Key ist aber über die Adresse

https://repos.influxdata.com/influxdata-archive_compat.key

herunterzuladen. Eventuell hätte man besser den neuen Key über die alte Internetadresse angeboten, denn so funktionieren die Anleitungen zum Teil nicht mehr, weil dann der apt install-Befehl mit einer Fehlermeldung fehlschlägt.

 

Die Information muss man erst einmal haben, aber danach ging die Installation ohne Probleme. Aber es wurde noch mehr seit der 1er-Version umgestellt, das CLI-Interface wurde geändert und auch die Konfigurationsdateien. Die alten Anleitungen sind daher zu größeren Teilen nicht mehr aktuell.

 

Ich hatte zuerst die 1er Version der InfluxDB installiert und wahrscheinlich deswegen lag noch eine Konfigurationsdatei influxdb.conf im Verzeichnis /etc/influxdb. Meine Änderungen an dieser Datei hatten auch nach einem Neustart des Dienstes aber überhaupt keine Auswirkungen.

 

Wenn man die Anleitungen der 1er-Version mit der 2er-Version gegenüberstellt sieht man auch dass sich das Format der Konfigurationsdatei zu YAML, TOML oder JSON-Dateien geändert hat:

 

image

 

In der Datei /etc/default/influxdb2 stand der Verweis

image

, die Datei war nach der Installation aber noch gar nicht vorhanden. Wahrscheinlich wird mit Defaultwerten gearbeitet, solange keine Datei vorhanden ist. Nachdem ich die Datei dort anlegte konnte ich aber Änderungen an den Einstellungen vornehmen.

 

Wenn Ihr nach Anleitungen zu InfluxDB sucht daher besser darauf achten dass die für die korrekte Version erstellt wurden. Bei der 2er-Version gibt es auch ein schickes Webinterface mit einem Installer für die Erstkonfiguration, das macht den Einstieg etwas einfacher. Auf der Dokumentationsseite zur Konfiguration kann man übrigens bei den Befehlen über Karteireiter zwischen den Formaten YAML, TOML oder JSON umschalten; die Syntax unterscheidet sich dabei.

 

Die Installation von Telegraf und Grafana war dagegen ganz einfach über apt install-Befehle. Telegraf sammelt Metriken ein und gibt sie weiter, Grafana ist für die Visualisierung. Telegraf hat eine ganze Menge an Input und Output-Schnittstellen, da werde ich später nochmal reinschauen.

 

Als ich die Konfigurationsdatei für Telegraf /etc/telegraf/telegraf.conf anschaute stellte ich fest, dass Telegraf auch Prometheus bei den Output-Plugins unterstützt. Die Installation einer zweiten Zeitreihendatenbank InfluxDB (zusätzlich zu Prometheus) ist damit wahrscheinlich unnötig gewesen, aber der RAM-Footprint von allem zusammen ist minimal.

 

Da bei InfluxDB offenbar mit der Version 2 sehr viel geändert wurde, wundert es mich auch nicht dass in der Telegraf-Konfigurationsdatei bei den Output-Plugins für InfluxDB v1 und v2 zwei getrennte Abschnitte aufgeführt sind, natürlich als auskommentierte Beispiele:

 

image

und

image

 

Telegraf muss natürlich mit der InfluxDB verknüpft werden, daher ein API-Token in der InfluxDB anlegen und dann in der Telegraf-Konfigurationsdatei die Einträge zu urls, token, organization und bucket auf sinnvolle Werte setzen. Das Ganze ist jetzt ein Gedächtnisprotokoll, daher notfalls auch bei den verlinkten Anleitungen reinschauen da meine Installation schon wieder ein paar Tage her ist.

 

Da es Output-Plugins bei Telegraf gibt, gibt es natürlich auch Input-Plugins. Mein Telegraf soll erstmal primär Statistiken über meine wichtigsten Docker sammeln und in der InfluxDB speichern. Wahrscheinlich werde ich das Ganze später noch erweitern.

 

Wie immer gibt es dazu mehrere Möglichkeiten. Wenn der Telegraf auf einer anderen Maschine als der zu überwachende Docker Daemon läuft, muss der Docker Daemon dazu im Netzwerk freigegeben (exposed) werden. Natürlich stellt das eine Sicherheitslücke dar, daher sollte man das nicht machen wenn der Server direkt und vollumfänglich ins Internet freigegeben wurde. Bei einem privaten Netzwerk schützt in der Regel die Firewall einer Fritzbox, sofern man seinen Server dort nicht als Exposed Host freigegeben hat.

 

Jedenfalls, wenn man den Docker-Daemon im Netzwerk freigeben will muss man dazu unter Ubuntu die Einstellungsdatei des systemd-Dienstes unter /etc/systemd/system/multi-user.target.wants/docker.service bearbeiten und bei dem Eintrag ExecStart den Parameter –H $IP:2376 ergänzen, abspeichern und natürlich den Docker-Dienst neu starten.

 

Dabei sollte man erstens 0.0.0.0 als IP-Adresse vermeiden, weil er dann von allen Netzwerkschnittstellen Anfragen ohne Authentifizierung entgegen nimmt und zweitens besser den verschlüsselten Port 2376 statt 2375 benutzen. Wenn man schon den Docker Daemon im Netzwerk freigibt sollte man ihn besser nur an eine lokale IP-Adresse binden, dann ist er durch die NAT-Translation eures Routers von außen geschützt. Nachfolgend verlinke ich noch die Dokumentationsseite von Docker.

 

Wahrscheinlich die bessere Möglichkeit ist es aber, den Telegraf direkt auf den zu überwachenden Maschinen zu installieren und die gesammelten Daten remote mit Authentifizierung in eine Datenbank zu schieben. Das ist aber auch mit etwas Aufwand verbunden, insbesondere wenn mehrere Docker-Hosts überwacht werden müssen. Mehr über die Gefahren der Netzwerkfreigabe des Docker-Daemons steht auf cdex.cloud.

 

Bei der Desktop-Variante von Ubuntu heißt der Dienst übrigens docker.service, aber bei der Server-Variante wird Docker als snap-Paket installiert und daher heißt der Service dort snap.docker.dockerd.service.

 

Die Grafana-Installation war ganz einfach, da das Paket direkt in den Ubuntu-Repositories vorhanden ist. Bei der Konfiguration von Grafana muss man sich aber entscheiden, ob man für die Anbindung an der InfluxDB als Query Language Flux oder das ältere InfluxQL nimmt. Laut der Anleitung von Howtoforge wird bei der Verwendung von InfluxDB 2.x davon abgeraten das ältere InfluxQL als Query Language zu verwenden, da es mit der neuen Version schwieriger einzurichten ist.

 

Bei Grafana gibt es vorkonfigurierte Dashboards je nach Datenquelle über die Angabe einer ID zum importieren. Welche Dashboards zur Auswahl stehen kann man über grafana.com einsehen. Speziell für Telegraf ist es dann wichtig kein zu altes Dashboard zu verwenden, um Fehlermeldungen zu vermeiden. Man kann z. B. die Stichworte “Telegraf Flux” oder “InfluxDB 2.x” bei der Suche verwenden.

 

Abschließend wollte ich noch die Anleitung von turbogeek.co.uk verlinken, wie man ein selbstsigniertes SSL-Zertifikat für Grafana mit openssl erstellt. Das ist nützlich wenn Ihr Grafana ins Internet freigeben wollt, weil dann die Kommunikation verschlüsselt wird. Bei selbstsignierten Zertifikaten müsst Ihr dazu aber erstmalig eine Warnung in eurem Webbrowser wegklicken. Die nächste Stufe wäre dann wahrscheinlich der certbot, um kostenlose Zertifikate von Let’s Encrypt zu erstellen.

 

Somit kann ich nun meine virtuellen Maschinen und Docker über Grafana monitoren. Dafür eignet sich der Atom Z83 ganz gut, weil er kaum warm wird und der RAM-Verbrauch minimal ist. An Stromverbrauch habe ich vier bis fünf Watt gemessen. Die Links habe ich auf mein Heimdall-Board verlinkt, ich muss mich also nicht immer durch Grafana durchklicken.

 

Das Ganze ist natürlich noch ausbaufähig, bei den Geek Freaks z. B. haben sie ein sehr umfangreiches Grafana-Board gezeigt. Aber so gefällt mir das für den Einstieg schon ganz gut.

   

Kommentar schreiben




  Country flag
biuquote
  • Kommentar
  • Live Vorschau
Loading


Tag-Wolke

Monats-Liste