Grafana-Ablösung - Monitoring in Home Assistant

Seit über sechs Jahren ist das Monitoring ein fester Bestandteil meines Setups. Doch was 2020 als State-of-the-Art galt, fühlte sich Anfang 2026 zunehmend nach unnötigem Ballast an. In diesem Beitrag nehme ich dich mit auf meine Reise weg von der komplexen Kombination aus Telegraf, InfluxDB und Grafana, hin zu einer schlanken, effizienten Lösung direkt in Home Assistant. Ich zeige dir, wie ich meinen vServer bei Hetzner und meinen lokalen Raspberry Pi überwache, ohne unnötige Docker-Container zu füttern.

Rückblick: Warum das alte Setup ausgedient hat

Als ich im Juni 2021 mein damaliges Grafana Dashboard vorstellte, war die Welt des Monitorings noch eine andere. Ich nutzte die klassische „TIG-Stack“-Architektur: Telegraf fungierte als Agent auf den Endgeräten, InfluxDB diente als Zeitreihendatenbank und Grafana war das mächtige Werkzeug für die Visualisierung.

Dieses Setup lief jahrelang stabil auf meinem vServer unter Debian und auf meinem Raspberry Pi im Heimnetzwerk. Ich überwachte alles: CPU-Last, RAM-Verbrauch, Festplattenkapazitäten und sogar detaillierte Netzwerkstatistiken meiner Fritz!Box. Später kamen noch Ping-Abfragen auf verschiedene URLs hinzu, um die Stabilität meiner Internetverbindung zu protokollieren.

Die Erkenntnis: Overkill im Smart Home Alltag

Mit der Zeit änderte sich mein Nutzungsverhalten. Als meine PV-Anlage installiert wurde, bereitete ich die Daten des Wechselrichters zwar ebenfalls für Grafana auf, merkte aber schnell, dass ich im Alltag ausschließlich das Energie-Dashboard von Home Assistant nutzte. Die grafische Aufbereitung dort ist für den schnellen Check zwischendurch einfach unschlagbar.

Im letzten halben Jahr ertappte ich mich immer häufiger dabei, dass die dedizierten Grafana-Dashboards für die Internetleitung und die PV-Anlage verwaisten. Lediglich die Server-Gesundheitswerte meines Hetzner-Nodes und des lokalen Pis rief ich noch ab. Ende 2025 wurde mir klar: Für ein paar Graphen einen kompletten InfluxDB-Container und eine Grafana-Instanz laufen zu lassen, die signifikante Ressourcen auf dem vServer fressen, ist schlichtweg ineffizient. Es war Zeit für eine Konsolidierung.

Schritt 1: Internet-Monitoring mit Ookla Speedtest via HACS

Der erste Meilenstein der Umstellung war die Überführung der Internet-Überwachung. Früher erledigte das ein Skript, das die Daten in die InfluxDB schob. Da meine Kabel-Internet-Leitung in den letzten Monaten jedoch extrem stabil lief, reichte mir eine Integration in Home Assistant völlig aus.

Ich habe mich für die HACS-Integration Ookla Speedtest entschieden. Diese bietet gegenüber der Standard-Integration den Vorteil, dass sie stabiler läuft und mehr Konfigurationsmöglichkeiten bietet.

Installation und Einrichtung

Die Installation erfolgt gewohnt einfach über den HACS (Home Assistant Community Store). Nach dem obligatorischen Neustart von Home Assistant konnte ich die Integration hinzufügen und konfigurieren. Da ich nicht möchte, dass alle 60 Minuten ein Speedtest meine Bandbreite während eines Videocalls blockiert, habe ich die automatischen Updates deaktiviert und steuere den Test stattdessen über eine gezielte Automation.

Die Automatisierung für präzise Daten

Um eine saubere Datenbasis zu erhalten, führe ich den Test nun zu fest definierten Zeiten aus – etwa nachts oder wenn ich sicher weiß, dass keine großen Downloads laufen. Zudem triggere ich einen Test kurz nach jedem Neustart von Home Assistant.

Hier ist der YAML-Code meiner Automation:

YAML
alias: Speedtest
description: >-
  Führt zu spezifischen Uhrzeiten und 5 Minuten nach dem Systemstart einen
  Internet-Geschwindigkeitstest durch.
triggers:
  - alias: Uhrzeiten
    trigger: time
    at:
      - "01:00:00"
      - "03:00:00"
      - "05:00:00"
      - "12:00:00"
      - "19:00:00"
      - "21:00:00"
      - "23:00:00"
  - alias: Neustart
    trigger: homeassistant
    event: start
    id: boot_trigger
actions:
  - alias: Verzögerung nach Neustart
    if:
      - condition: trigger
        id: boot_trigger
    then:
      - delay: "00:05:00"
  - alias: Speedtest durchführen
    action: ookla_speedtest.run_speedtest
    data: {}

Durch diese Strategie belaste ich meine Leitung nicht unnötig und habe dennoch eine verlässliche Historie über die Performance meines Providers.

Schritt 2: Server-Monitoring – Von Telegraf zu Glances

Die größte Herausforderung war die Ablösung des Server-Monitorings. Ich wollte die Vitalwerte meines externen vServers und meiner lokalen Infrastruktur weiterhin im Blick behalten. Mein erster Versuch, die Daten weiterhin per Telegraf zu senden, scheiterte an der komplizierten Integration in die Home Assistant API ohne den Umweg über eine externe Datenbank.

Ich entschied mich daher für einen radikalen Wechsel zu Glances. Glances ist ein quelloffenes Überwachungstool, das extrem leichtfüßig agiert und – was am wichtigsten ist – eine hervorragende REST-API mitbringt.

Absicherung der Kommunikation

Ich installierte Glances auf meinem Debian-vServer und meinem Raspberry Pi. Da der vServer im Netz steht, war eine Absicherung der API unerlässlich. Glances bietet hierfür einen Passwortschutz und lässt sich zudem hervorragend hinter einem Reverse Proxy oder via Firewall-Regeln (IP-Whitelisting) absichern. In einem künftigen Beitrag kann ich gerne detaillierter auf das Hardening von Glances eingehen, falls dich das interessiert.

Integration via REST-API und Templates

Obwohl es eine offizielle Glances-Integration für Home Assistant gibt, stellte ich fest, dass diese nicht alle Sensoren anlegte, die ich benötigte – insbesondere die Load Average Werte der Systeme fehlten mir.

Die Lösung? Die direkte Abfrage der Glances-API über Template-Sensoren in der configuration.yaml. Das gibt mir die volle Kontrolle über die Daten, die ich wirklich sehen will. Hier ist ein Beispiel, wie ich die Load Average Werte meines Raspberry Pis einbinde:

YAML
rest:
  - resource: http://192.168.0.4:61208/api/4/load
    scan_interval: 60
    sensor:
      - name: "Raspberry Pi - Load 1"
        unique_id: "raspberry_pi_load_1"
        value_template: "{{ value_json.min1 | round(2) }}"
        icon: mdi:chart-line
      - name: "Raspberry Pi - Load 5"
        unique_id: "raspberry_pi_load_5"
        value_template: "{{ value_json.min5 | round(2) }}"
        icon: mdi:chart-line
      - name: "Raspberry Pi - Load 15"
        unique_id: "raspberry_pi_load_15"
        value_template: "{{ value_json.min15 | round(2) }}"
        icon: mdi:chart-line

Dieser Ansatz ist zwar initial etwas aufwendiger in der Konfiguration, spart aber massiv Ressourcen, da Home Assistant die Daten nun direkt per HTTP-Call abholt, statt auf einen Push-Dienst zu warten.

Schritt 3: Visualisierung mit Mini-Graph-Cards

Nachdem die Daten nun sauber als Sensoren in Home Assistant vorlagen, ging es an die Kür: Die Visualisierung. Grafana bietet zwar unendliche Möglichkeiten, aber für den täglichen Überblick im Smart Home ist das oft „Too Much“.

Ich nutze stattdessen die Mini-Graph-Card aus dem HACS. Diese Karten erlauben es, sehr kompakte, aber dennoch aussagekräftige Graphen direkt im Lovelace-Dashboard zu erstellen.

Mein Dashboard-Layout

Ich habe mir eine dedizierte „System-Monitoring“-Seite angelegt. Dort gruppiere ich die Daten in drei Sektionen:

Internet-Performance: Download, Upload und Ping (Historie der letzten 24 Stunden).
vServer: CPU, RAM, Dateisystem, Netzwerk Traffic, Docker Ressourcen und Uptime.
Raspberry Pi: CPU, RAM, Dateisystem, Netzwerk Traffic, Docker Ressourcen und Uptime.

Der Vorteil der Mini-Graph-Cards ist die farbliche Dynamik. Ich habe die Karten so konfiguriert, dass sich die Graphen von Blau zu Rot färben, sobald die CPU-Last über 80 % steigt oder der freie Speicherplatz knapp wird. Das bietet mir den gleichen visuellen Warneffekt, für den ich früher komplexe „Thresholds“ in Grafana definieren musste.

Fazit: Effizienz gewinnt

Der Umzug von einem dedizierten Monitoring-Stack hin zu einer integrierten Lösung in Home Assistant war für mich die richtige Entscheidung.

Die Vorteile auf einen Blick:

Ressourceneinsparung: Auf meinem vServer konnte ich zwei ressourcenintensive Docker-Container (InfluxDB & Grafana) komplett abschalten. Gerade die InfluxDB neigt dazu, sich über die Zeit ordentlich RAM und I/O-Performance zu genehmigen.
Zentralisierung: Ich habe alle wichtigen Daten an einem Ort. Ich muss nicht mehr zwischen verschiedenen Apps oder Browser-Tabs wechseln.
Wartungsarm: Weniger Container bedeuten weniger Updates und weniger potenzielle Sicherheitslücken.
Einfachheit: Dank Glances und Template-Sensoren ist das System extrem flexibel erweiterbar.

Natürlich hat Grafana seine Daseinsberechtigung, wenn es um extrem tiefgreifende Analysen über Monate oder Jahre hinweg geht. Aber für mein Ziel – die Überwachung der Systemstabilität und der Internetleitung – ist die Home Assistant-Lösung die deutlich elegantere Wahl. Mein System fühlt sich nun deutlich „entschlackter“ an, und die Performance-Gewinne auf dem vServer sind spürbar.

Hast du noch Fragen?

Hast du noch Fragen zu diesem Beitrag? Dann ab damit in die Kommentare oder schreib mich über Mastodon an.

Dies könnte dich auch interessieren…

Du möchtest weitere Inhalte von mir lesen? Schau doch mal hier: What’s on my Phone? – 2026

Grafana-Ablösung – Monitoring in Home Assistant