LibreNMS mit Docker Compose: SNMP-Netzwerk-Monitoring für KMU selbst hosten

Wer ein kleines Firmennetz betreibt, kennt das Problem: Der Switch im Serverraum meldet sich nicht, ein Uplink ist seit Tagen auf 100 MBit statt 1 GBit gefallen, und die USV hat schon vor zwei Wochen einen Batteriefehler gemeldet. Nur hat es niemand gesehen, weil niemand dauerhaft hinschaut. Genau diese Lücke schließt LibreNMS. Das Projekt sammelt per SNMP automatisch Daten von Switches, Routern, Firewalls, Servern, Druckern und USV-Anlagen, erkennt Interfaces, Sensoren und Temperaturen selbständig und zeichnet den Verlauf über Monate auf.

Diese Anleitung führt durch die Inbetriebnahme mit dem offiziellen Docker-Compose-Beispiel des Projekts. Der beschriebene Stack wurde am 18.09.2026 auf einem Ubuntu-Host mit Docker 29.1.3 und Docker Compose 2.40.3 tatsächlich gestartet, ein Gerät wurde per SNMPv2c aufgenommen und abgefragt, und Datenbanksicherung samt Wiederherstellung wurden geprüft. Wo etwas nur aus der Dokumentation stammt und hier nicht selbst getestet wurde, steht das ausdrücklich dabei.

Was LibreNMS leistet und wo die Grenzen liegen

LibreNMS ist ein klassisches Netzwerk-Management-System. Der Kern ist Autodiscovery über SNMP: Man gibt einem Gerät eine Community-Zeichenkette oder SNMPv3-Zugangsdaten mit, LibreNMS fragt es ab und legt danach von allein Ports, VLANs, Sensoren, Prozessoren, Speicher und Temperaturwerte an. Die Werte landen in RRD-Dateien, daraus entstehen Langzeitgraphen. Dazu kommen Alarmregeln, ein Syslog-Empfänger und ein SNMP-Trap-Empfänger.

Das ist die Stärke, gleichzeitig markiert es die Grenze. LibreNMS denkt in Geräten und deren SNMP-Sicht. Es ist kein Werkzeug für Anwendungs-Tracing, keine Log-Analyseplattform und kein Metrik-Lager für selbstgeschriebene Software. Wer wissen will, warum eine PHP-Anwendung langsam antwortet, braucht etwas anderes.

• Passt gut: Managed Switches, Router, Firewalls, Access Points, USV-Anlagen, NAS-Systeme, physische Server mit SNMP-Agent, alles was klassisch SNMP spricht.
• Passt bedingt: Linux- und Windows-Server. LibreNMS holt CPU, RAM, Festplatten und Interfaces per SNMP-Agent ab. Für tiefere Betriebssystemmetriken ist ein spezialisiertes Werkzeug oft angenehmer.
• Passt nicht: Container-Metriken, Anwendungs-Performance, verteiltes Tracing, zentrale Logauswertung mit Volltextsuche, synthetisches Monitoring von Webseiten aus Kundensicht.
• Nicht geeignet als Uptime-Melder für Außenstehende: LibreNMS ist ein internes Betriebswerkzeug, keine öffentliche Statusseite.

In der S-EDV-Praxis ergänzen sich diese Werkzeuge eher, als dass sie konkurrieren. LibreNMS deckt die Netzwerk- und Geräteebene ab, ein Uptime-Melder deckt die Erreichbarkeit von Diensten aus Kundensicht ab, und eine Metrikplattform deckt Anwendungen ab. Wer alles in ein System zwingen will, bekommt in keiner Disziplin ein gutes Ergebnis.

Voraussetzungen und Ressourcenbedarf

Der Stack besteht aus mehreren Containern: der LibreNMS-Weboberfläche, einem Dispatcher als Poller, einer MariaDB-Datenbank, Redis für Sperren und Sitzungen, einem SMTP-Relais sowie optional Syslog-ng und snmptrapd. Alle LibreNMS-Container nutzen dasselbe Image, unterscheiden sich nur über Umgebungsvariablen.

Im Test lief der Stack auf einem Host mit zwei CPU-Kernen und 8 GB RAM. Nach dem Start und einer Abfrage eines Geräts zeigte docker stats für die LibreNMS-Container zusammen rund 668 MiB belegten Arbeitsspeicher, davon rund 379 MiB für MariaDB, 99 MiB für den Webcontainer, 70 MiB für Syslog-ng, 61 MiB für den Dispatcher, 50 MiB für snmptrapd und jeweils rund 4 MiB für Redis und das SMTP-Relais. Auf der Platte belegte das MariaDB-Verzeichnis nach der Erstinitialisierung rund 201 MB, das LibreNMS-Datenverzeichnis zunächst nur 84 KB.

Ressource	Empfehlung für KMU-Betrieb	Bemerkung
CPU	2 Kerne, bei über 50 Geräten 4 Kerne	Im Test genügten 2 Kerne für ein Gerät problemlos
RAM	4 GB Minimum, 8 GB komfortabel	Leerlauf des Stacks im Test rund 668 MiB
Speicher	40 GB, bei vielen Ports mehr	MariaDB nach Erstinitialisierung rund 201 MB, RRD-Daten wachsen mit Portanzahl
Docker	Docker Engine mit Compose-Plugin v2	Getestet mit Docker 29.1.3 und Compose 2.40.3
Netz	UDP 161 ausgehend zu den Geräten	Ohne SNMP-Erreichbarkeit funktioniert nichts
Zeit	NTP synchronisierte Hostuhr	LibreNMS prüft beim Selbsttest, ob PHP- und Datenbankzeit übereinstimmen

Zu den Plattformen: Das offizielle Image wird laut Projekt-README für linux/amd64, linux/arm/v7, linux/arm64, linux/ppc64le und linux/s390x gebaut. Getestet wurde hier ausschließlich linux/amd64. Der ARM-Betrieb auf einem Raspberry Pi ist laut dieser Angabe möglich, wurde hier aber nicht selbst überprüft.

Projekt- und Versionsstand mit Beleg

Für die Beurteilung, ob ein Projekt tragfähig ist, zählt der Pflegezustand mehr als die Sternezahl. Beide Repositories wurden am 18.09.2026 über die GitHub-API abgefragt.

Merkmal	librenms/librenms	librenms/docker
Sterne	4891	859
Letzter Push	17.09.2026	15.09.2026
Letztes Release	26.8.2 vom 31.08.2026	folgt den LibreNMS-Versionen
Archiviert	nein	nein
Lizenz laut API	NOASSERTION, Projekt nennt GPL	MIT
Forks	2802	nicht abgefragt

Die im Test gestartete Version meldete sich im Selbsttest als LibreNMS 26.8.2 mit Erstellungsdatum 31.08.2026, PHP 8.4.21, Python 3.12.14, MariaDB 10.11.19, RRDTool 1.9.0 und Net-SNMP 5.9.5.2. Das deckt sich mit dem per API ermittelten Release-Stand. Ein Hinweis zur Lizenz: Die GitHub-API liefert für das Hauptrepository NOASSERTION, weil die Lizenzdatei nicht automatisch erkannt wird. Das Projekt selbst führt eine LICENSE.txt im Repository, die im Container unter /opt/librenms/LICENSE.txt liegt. Wer Lizenzfragen rechtssicher klären muss, sollte diese Datei lesen und sich nicht auf das API-Feld verlassen.

Vollständige compose.yml und env-Dateien

Das Projekt liefert unter examples/compose im Repository librenms/docker eine fertige Vorlage aus vier Dateien. Sie sollten diese Dateien nicht abschreiben, sondern direkt beziehen. Legen Sie ein Arbeitsverzeichnis an, üblicherweise /opt/librenms oder /var/librenms auf dem Host.

# Arbeitsverzeichnis anlegen und betreten
sudo mkdir -p /opt/librenms
cd /opt/librenms

# Die vier offiziellen Vorlagendateien direkt aus dem Repository holen
sudo curl -sL -o compose.yml https://raw.githubusercontent.com/librenms/docker/master/examples/compose/compose.yml
sudo curl -sL -o .env https://raw.githubusercontent.com/librenms/docker/master/examples/compose/.env
sudo curl -sL -o librenms.env https://raw.githubusercontent.com/librenms/docker/master/examples/compose/librenms.env
sudo curl -sL -o msmtpd.env https://raw.githubusercontent.com/librenms/docker/master/examples/compose/msmtpd.env

Die Datei compose.yml definiert sieben Dienste. Der folgende Auszug zeigt die drei Kerndienste im Originalzustand der Vorlage, gekürzt um die Sidecar-Dienste, die weiter unten erklärt werden.

name: librenms

services:
  db:
    image: mariadb:10
    container_name: librenms_db
    command:
      - "mysqld"
      - "--innodb-file-per-table=1"
      - "--lower-case-table-names=0"
      - "--character-set-server=utf8mb4"
      - "--collation-server=utf8mb4_unicode_ci"
    volumes:
      - "./db:/var/lib/mysql"
    environment:
      - "TZ=${TZ}"
      - "MARIADB_RANDOM_ROOT_PASSWORD=yes"
      - "MYSQL_DATABASE=${MYSQL_DATABASE}"
      - "MYSQL_USER=${MYSQL_USER}"
      - "MYSQL_PASSWORD=${MYSQL_PASSWORD}"
    restart: always

  redis:
    image: redis:7.2-alpine
    container_name: librenms_redis
    environment:
      - "TZ=${TZ}"
    restart: always

  librenms:
    image: librenms/librenms:latest
    container_name: librenms
    hostname: librenms
    cap_add:
      - NET_ADMIN
      - NET_RAW
    ports:
      - target: 8000
        published: 8000
        protocol: tcp
    depends_on:
      - db
      - redis
      - msmtpd
    volumes:
      - "./librenms:/data"
    env_file:
      - "./librenms.env"
    environment:
      - "TZ=${TZ}"
      - "PUID=${PUID}"
      - "PGID=${PGID}"
      - "DB_HOST=db"
      - "DB_NAME=${MYSQL_DATABASE}"
      - "DB_USER=${MYSQL_USER}"
      - "DB_PASSWORD=${MYSQL_PASSWORD}"
      - "DB_TIMEOUT=60"
    restart: always

Der Dispatcher ist der eigentliche Poller. Er nutzt dasselbe Image, bekommt aber SIDECAR_DISPATCHER=1 gesetzt. Ohne mindestens einen laufenden Dispatcher werden keine Geräte abgefragt, die Oberfläche bleibt dann leer. Die Sidecars für Syslog-ng und snmptrapd folgen demselben Muster mit SIDECAR_SYSLOGNG=1 beziehungsweise SIDECAR_SNMPTRAPD=1.

  dispatcher:
    image: librenms/librenms:latest
    container_name: librenms_dispatcher
    hostname: librenms-dispatcher
    cap_add:
      - NET_ADMIN
      - NET_RAW
    depends_on:
      - librenms
      - redis
    volumes:
      - "./librenms:/data"
    env_file:
      - "./librenms.env"
    environment:
      - "TZ=${TZ}"
      - "PUID=${PUID}"
      - "PGID=${PGID}"
      - "DB_HOST=db"
      - "DB_NAME=${MYSQL_DATABASE}"
      - "DB_USER=${MYSQL_USER}"
      - "DB_PASSWORD=${MYSQL_PASSWORD}"
      - "DB_TIMEOUT=60"
      - "DISPATCHER_NODE_ID=dispatcher1"
      - "SIDECAR_DISPATCHER=1"
    restart: always

Die Datei .env im Arbeitsverzeichnis steuert Zeitzone, Benutzerkennungen und die Datenbankzugangsdaten. Die Vorlage bringt ein Beispielpasswort mit, das zwingend ersetzt werden muss. Die folgenden Werte sind Platzhalter und dürfen so nicht produktiv übernommen werden.

# .env im Arbeitsverzeichnis, Platzhalter ersetzen
TZ=Europe/Berlin
PUID=1000
PGID=1000

MYSQL_DATABASE=librenms
MYSQL_USER=librenms
# HIER_EIN_EIGENES_LANGES_PASSWORT_EINSETZEN
MYSQL_PASSWORD=BITTE_ERSETZEN

Ein sicheres Passwort erzeugen Sie am schnellsten direkt auf dem Host und tragen es dann ein. Speichern Sie es zusätzlich im Passwortverwalter der Firma, sonst ist ein späteres Wiederherstellen der Datenbank unnötig kompliziert.

# Zufälliges Passwort erzeugen und anzeigen
openssl rand -base64 30

Die Datei librenms.env enthält die Anwendungseinstellungen. Wichtig ist hier vor allem die SNMP-Community des Containers selbst, die Redis-Anbindung und die PHP-Grenzwerte.

# librenms.env, Anwendungseinstellungen
MEMORY_LIMIT=256M
MAX_INPUT_VARS=1000
UPLOAD_MAX_SIZE=16M
OPCACHE_MEM_SIZE=128
REAL_IP_FROM=0.0.0.0/32
REAL_IP_HEADER=X-Forwarded-For
LOG_IP_VAR=remote_addr

CACHE_DRIVER=redis
SESSION_DRIVER=redis
REDIS_HOST=redis

# Community des LibreNMS-Containers selbst, bitte ändern
LIBRENMS_SNMP_COMMUNITY=BITTE_EIGENE_COMMUNITY_SETZEN

LIBRENMS_WEATHERMAP=false
LIBRENMS_WEATHERMAP_SCHEDULE=*/5 * * * *

Die vierte Datei msmtpd.env konfiguriert das SMTP-Relais für Alarmmails. Tragen Sie hier den Mailserver Ihres Unternehmens ein, nicht die Beispielwerte der Vorlage. Auch hier gilt: echte Zugangsdaten gehören in den Passwortverwalter und nicht in ein Versionsverwaltungssystem.

# msmtpd.env, Platzhalter ersetzen
SMTP_HOST=mail.ihre-domain.example
SMTP_PORT=587
SMTP_TLS=on
SMTP_STARTTLS=on
SMTP_TLS_CHECKCERT=on
SMTP_AUTH=on
SMTP_USER=BITTE_ERSETZEN
SMTP_PASSWORD=BITTE_ERSETZEN
SMTP_FROM=monitoring@ihre-domain.example

Die wichtigsten Parameter im Überblick

Die Vorlage bringt viele Schalter mit, die im Alltag selten angefasst werden. Die folgende Tabelle fasst diejenigen zusammen, die bei einer KMU-Installation tatsächlich relevant sind. Die Standardwerte stammen aus dem README des Repositories librenms/docker, abgerufen am 18.09.2026.

Parameter	Datei	Standard	Bedeutung
TZ	.env	UTC	Zeitzone aller Container. Auf Europe/Berlin setzen, sonst stimmen Graphenzeiten nicht mit der Uhr im Büro überein.
PUID und PGID	.env	1000	Benutzer- und Gruppenkennung, unter der LibreNMS im Container läuft. Muss zum Eigentümer des Datenverzeichnisses passen.
MYSQL_PASSWORD	.env	Beispielwert	Datenbankpasswort. Zwingend ersetzen, wird an Datenbank und Anwendung gleichzeitig übergeben.
DB_TIMEOUT	compose.yml	60	Sekunden, die LibreNMS auf die Datenbank wartet. Verhindert Startabbrüche, wenn MariaDB beim ersten Start noch initialisiert.
SIDECAR_DISPATCHER	compose.yml	0	Auf 1 gesetzt macht diesen Container zum Poller. Ohne mindestens einen Dispatcher werden keine Daten erhoben.
DISPATCHER_NODE_ID	compose.yml	leer	Eindeutige Kennung des Pollers. Bei mehreren Pollern muss jeder eine eigene Kennung haben.
CACHE_DRIVER und SESSION_DRIVER	librenms.env	database bzw. file	In der Vorlage auf redis gesetzt. Nötig, sobald mehr als ein Dispatcher läuft.
LIBRENMS_SNMP_COMMUNITY	librenms.env	librenmsdocker	SNMP-Community des LibreNMS-Containers selbst, damit er sich selbst überwachen kann. Unbedingt ändern.
LIBRENMS_BASE_URL	librenms.env	/	Öffentliche Adresse der Instanz. Setzen, wenn LibreNMS hinter einem Reverse Proxy unter einer eigenen Domain läuft.
APP_TRUSTED_PROXIES	librenms.env	leer	IP-Bereiche, denen Weiterleitungs-Kopfzeilen geglaubt wird. Nur die Adresse des eigenen Reverse Proxy eintragen.
REAL_IP_FROM	librenms.env	0.0.0.0/32	Netz, aus dem der Reverse Proxy kommt. Damit stehen echte Client-Adressen im Zugriffsprotokoll.
MEMORY_LIMIT	librenms.env	256M	PHP-Speichergrenze. Bei vielen Geräten und großen Berichten erhöhen.
RRDCACHED_SERVER	librenms.env	leer	Optionaler RRDcached-Server zur Entlastung der Platte. Laut Dokumentation sinnvoll ab vielen hundert Geräten, hier nicht getestet.

Installation und erster Start

Der Start ist ein einzelner Befehl, dauert beim ersten Mal aber deutlich länger als erwartet, weil mehrere Images geladen werden. Im Test verging vom Aufruf bis zum fertig erstellten Container gut sechs Minuten, davon fiel der überwiegende Teil auf den Download des LibreNMS-Images.

# Im Arbeitsverzeichnis mit der compose.yml
cd /opt/librenms

# Stack im Hintergrund starten
docker compose up -d

# Fortschritt verfolgen, mit Strg und C verlassen
docker compose logs -f librenms

Nach dem Start zeigt docker compose ps im Test folgendes Bild, hier gekürzt auf die relevanten Spalten. Die Portangaben im Beispiel weichen bewusst vom Standard ab, weil der Teststack auf hohe Hostports gelegt wurde.

NAME                  IMAGE                      STATUS
librenms              librenms/librenms:latest   Up 21 seconds
librenms_db           mariadb:10                 Up 24 seconds
librenms_dispatcher   librenms/librenms:latest   Up 19 seconds
librenms_msmtpd       crazymax/msmtpd:latest     Up 24 seconds (healthy)
librenms_redis        redis:7.2-alpine           Up 24 seconds
librenms_snmptrapd    librenms/librenms:latest   Up 19 seconds
librenms_syslogng     librenms/librenms:latest   Up 19 seconds

Wichtig für die Nerven: Unmittelbar nach dem Start antwortet die Weboberfläche noch nicht. Im Test lieferte ein Abruf von Port 8000 zunächst gar keine Antwort, weil der Container noch seine Initialisierungsskripte abarbeitete und die Datenbankstruktur anlegte. Erst rund anderthalb Minuten später meldete sich nginx im Protokoll mit fpm is running beziehungsweise ready to handle connections, und der Abruf lieferte eine Weiterleitung. Dieses Zeitfenster ist normal und kein Fehler.

Erstkonfiguration: Admin-Benutzer und erstes Gerät

Beim ersten Aufruf leitet LibreNMS auf einen Einrichtungsassistenten weiter. Im Test führte ein Abruf der Wurzeladresse zuverlässig auf den Pfad /install/user mit HTTP 200 und der Überschrift zum Anlegen eines Administrators. Dort legen Sie den ersten Benutzer im Browser an. Rufen Sie also die Adresse Ihrer Instanz im Browser auf und folgen Sie dem Assistenten.

Alternativ geht das auch auf der Kommandozeile, was bei automatisierten Installationen praktisch ist. Dieser Weg wurde im Test verwendet und funktionierte. Beachten Sie die Anführungszeichen um das Passwort, sonst interpretiert die Shell Sonderzeichen.

# Administrator anlegen, Rolle admin
docker compose exec -u librenms librenms \
  lnms user:add -p 'IHR_SICHERES_PASSWORT' -r admin -e admin@ihre-domain.example adminname

Die erwartete Ausgabe im Test lautete Successfully added user: adminlokal. Ein anschließender Blick in die Anwendung bestätigte, dass genau ein Benutzer existierte und die Rolle admin trug.

Ein Hinweis aus dem Test, der in der Dokumentation nicht deutlich steht: Wenn Sie den Administrator ausschließlich über die Kommandozeile anlegen, gilt der Installationsassistent noch nicht als abgeschlossen. Im Test leiteten anschließend auch /login und /device/1 weiterhin mit HTTP 302 auf den Installationspfad um, weil in der Anwendungskonfiguration weiterhin INSTALL=user,finish stand. Der saubere Weg ist deshalb, den Assistenten einmal im Browser bis zum Ende durchzuklicken. Wer den Benutzer per Kommandozeile angelegt hat, erkennt ihn im Assistenten wieder und muss nur noch den Abschlussschritt bestätigen.

Danach folgt das erste Gerät. Für einen ersten Test eignet sich der LibreNMS-Container selbst, weil er einen SNMP-Agenten mitbringt und die Community aus librenms.env nutzt. Der Befehl lautet auf der Kommandozeile:

# Gerät mit SNMPv2c aufnehmen
docker compose exec -u librenms librenms \
  lnms device:add --v2c --community IHRE_COMMUNITY hostname-oder-ip

# Gerät sofort einmal abfragen
docker compose exec -u librenms librenms \
  lnms device:poll hostname-oder-ip

Im Test meldete der erste Befehl Added device librenms (1). Die anschließende Abfrage lieferte eine detaillierte Statistik, unter anderem Polled librenms (1) in 6.808 seconds, dazu 35 SNMP-Abfragen in 3,74 Sekunden, 81 SQL-Operationen und 126 RRD-Operationen, davon 63 Neuanlagen von RRD-Dateien. Genau diese Neuanlagen sind der Beleg dafür, dass die Datenerfassung funktioniert.

In der Weboberfläche fügen Sie Geräte über den Menüpunkt zum Hinzufügen eines Geräts hinzu. Dort tragen Sie Hostname oder IP-Adresse, die SNMP-Version und die Zugangsdaten ein. Für SNMPv3 hinterlegen Sie Benutzername, Authentifizierungs- und Verschlüsselungspasswort sowie die gewählten Verfahren. SNMPv3 ist die einzige Variante mit Verschlüsselung und gehört in jedem Netz bevorzugt, in dem SNMP-Verkehr über nicht vertrauenswürdige Strecken läuft.

Funktions- und Healthcheck mit konkreten Befehlen

LibreNMS bringt einen eigenen Selbsttest mit. Er ist das wichtigste Diagnosewerkzeug und sollte nach jeder Änderung laufen. Achten Sie auf den Benutzer: Als root verweigert das Skript die Arbeit.

# Selbsttest als Anwendungsbenutzer ausführen
docker compose exec -u librenms librenms php /opt/librenms/validate.php

Im Test lieferte das folgende Kopfzeilen, die den gesamten Versionsstand auf einen Blick zeigen:

Component | Version
--------- | -------
LibreNMS  | 26.8.2 (2026-08-31T23:34:20+02:00)
DB Schema | 2026_07_30_162514_add_device_refresh_config_permission (397)
PHP       | 8.4.21
Python    | 3.12.14
Database  | MariaDB 10.11.19-MariaDB-ubu2204
RRDTool   | 1.9.0
SNMP      | 5.9.5.2

Darunter folgt die eigentliche Prüfliste. Im Test standen dort unter anderem Bestätigungen, dass die Datenbank verbunden und das Schema aktuell ist, dass Zeichensätze und Sortierungen stimmen, dass Sperren funktionieren, dass Redis erreichbar ist, dass das RRD-Verzeichnis beschreibbar ist und dass die Zeiten von MySQL und PHP übereinstimmen. Zwei Warnungen sind im frischen Docker-Betrieb normal und kein Problem: der Hinweis, dass noch kein Gerät angelegt ist, und der Hinweis, dass Aktualisierungen über das offizielle Image verwaltet werden.

• Weboberfläche prüfen: curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/. Erwartet wird 302 mit Weiterleitung auf den Anmelde- oder Installationspfad. Eine leere Antwort bedeutet, dass der Container noch startet.
• Poller prüfen: docker compose logs --tail 20 dispatcher. Im Test erschienen dort wiederkehrend Zeilen wie Alerting(INFO):Checking alerts und Completed alerting run for alerts in 4.06s. Bleiben diese Zeilen aus, läuft kein Poller.
• SNMP direkt testen: docker compose exec -u librenms librenms snmpget -v2c -c IHRE_COMMUNITY -t 2 -r 1 ZIEL sysDescr.0. Im Test lieferte das bei korrekter Community eine Systembeschreibung, bei falscher Community die Meldung Timeout: No Response from librenms.
• RRD-Dateien prüfen: ls DATENVERZEICHNIS/librenms/rrd/GERAETENAME/ | head. Nach der ersten Abfrage lagen im Test dort Dateien wie poller-perf.rrd.
• Ressourcen prüfen: docker stats --no-stream zeigt, ob ein Container ungewöhnlich viel Speicher oder CPU zieht.

Persistente Daten, Volumes und Rechte

Die Vorlage nutzt bewusst keine benannten Docker-Volumes, sondern zwei Verzeichnisse neben der compose.yml. Das macht Sicherungen einfacher, verlagert aber die Verantwortung für die Rechte auf Sie.

Pfad auf dem Host	Pfad im Container	Inhalt
./db	/var/lib/mysql	MariaDB-Datenbank mit Geräten, Ports, Benutzern, Alarmregeln und Ereignissen
./librenms	/data	Anwendungsdaten des Containers
./librenms/rrd	/data/rrd	RRD-Dateien mit den Messreihen, je Gerät ein Unterverzeichnis
./librenms/config	/data/config	YAML-Dateien für die Anfangskonfiguration
./librenms/logs	/data/logs	Anwendungsprotokolle
./librenms/.env	/data/.env	Anwendungsschlüssel und Knotenkennung, im Test 82 Byte groß

Zu den Rechten warnt das Projekt ausdrücklich: Das Datenverzeichnis muss dem Benutzer und der Gruppe gehören, die über PUID und PGID gesetzt sind, sonst startet der Container möglicherweise nicht. Im Test gehörte das Verzeichnis librenms dem aufrufenden Benutzer mit Kennung 1000, was zur Vorgabe passte, und alles lief. Wenn Sie den Stack unter einem anderen Benutzer betreiben, passen Sie die Werte an und korrigieren Sie den Eigentümer.

# Eigentümer des Datenverzeichnisses setzen, Kennungen an PUID und PGID anpassen
sudo chown -R 1000:1000 /opt/librenms/librenms

Das Datenbankverzeichnis ./db gehört dagegen dem Benutzer des MariaDB-Containers. Im Test war es für den normalen Hostbenutzer nicht lesbar, ein du darauf scheiterte mit einer Rechteverweigerung. Das ist korrekt so und kein Fehler. Sichern Sie die Datenbank deshalb niemals durch bloßes Kopieren dieses Verzeichnisses im laufenden Betrieb, sondern über einen ordentlichen Datenbankabzug.

Sichere Netzwerkfreigabe, Reverse Proxy und TLS

Der Stack veröffentlicht Port 8000 unverschlüsselt. Das ist für einen ersten Test in Ordnung, gehört aber nicht so ins Firmennetz und schon gar nicht ins Internet. Der erste Schritt ist, die Veröffentlichung auf die Loopback-Adresse zu begrenzen, damit nur ein lokaler Reverse Proxy zugreifen kann.

    ports:
      - target: 8000
        published: 8000
        host_ip: 127.0.0.1
        protocol: tcp

Davor setzen Sie einen Reverse Proxy mit gültigem Zertifikat. Das folgende nginx-Beispiel entspricht dem üblichen Muster und setzt die Kopfzeilen, die LibreNMS für korrekte Client-Adressen und Weiterleitungen braucht. Die Zertifikatspfade stammen aus einer Let's-Encrypt-Installation und müssen angepasst werden. Diese Proxy-Konfiguration wurde im Rahmen dieses Tests nicht selbst aufgesetzt.

server {
    listen 443 ssl;
    http2 on;
    server_name monitoring.ihre-domain.example;

    ssl_certificate     /etc/letsencrypt/live/monitoring.ihre-domain.example/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/monitoring.ihre-domain.example/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name monitoring.ihre-domain.example;
    return 301 https://$host$request_uri;
}

Damit LibreNMS die weitergeleiteten Kopfzeilen akzeptiert, ergänzen Sie in librenms.env die Adresse des Proxy und die öffentliche Basisadresse. Tragen Sie bei REAL_IP_FROM und APP_TRUSTED_PROXIES ausschließlich die Adresse Ihres eigenen Proxy ein. Ein zu weit gefasster Bereich erlaubt es Angreifern, beliebige Kopfzeilen vorzutäuschen, was das Projekt im README ausdrücklich als Risiko benennt.

# Ergänzungen in librenms.env für den Betrieb hinter einem Reverse Proxy
LIBRENMS_BASE_URL=https://monitoring.ihre-domain.example
REAL_IP_FROM=127.0.0.1/32
APP_TRUSTED_PROXIES=127.0.0.1

Für die Sidecars gilt dasselbe Prinzip. Syslog-ng lauscht auf Port 514, snmptrapd auf Port 162, beides auch per UDP. Diese Ports gehören ausschließlich in das interne Verwaltungsnetz und niemals ins Internet. Wenn Sie weder Syslog-Empfang noch SNMP-Traps brauchen, kommentieren Sie die beiden Dienste in der compose.yml einfach aus. Das spart im Test rund 120 MiB Arbeitsspeicher und reduziert die Angriffsfläche.

Ergänzend gehört SNMP selbst abgesichert. SNMPv2c überträgt die Community-Zeichenkette im Klartext. Nutzen Sie nach Möglichkeit SNMPv3 mit Authentifizierung und Verschlüsselung, und beschränken Sie auf den überwachten Geräten den SNMP-Zugriff per Zugriffsliste auf die IP-Adresse des LibreNMS-Hosts.

Backup und Wiederherstellung

Eine Sicherung von LibreNMS besteht immer aus zwei Teilen. Die Datenbank enthält Geräte, Benutzer, Alarmregeln und Ereignisse. Die RRD-Dateien enthalten die Messreihen, also die eigentlichen Graphen. Wer nur die Datenbank sichert, hat nach einem Ausfall zwar alle Geräte wieder, aber keine Historie.

Der Datenbankabzug wurde im Test durchgeführt und funktionierte. Der Abzug umfasste 165 Tabellen bei einer Dateigröße von 238 KB für eine frische Installation mit einem Gerät.

# Zielverzeichnis für Sicherungen
sudo mkdir -p /var/backups/librenms
cd /opt/librenms

# Datenbank sichern, Passwort aus der .env verwenden
docker compose exec -T db \
  mariadb-dump -u librenms -p'IHR_DB_PASSWORT' --single-transaction librenms \
  > /var/backups/librenms/librenms-db-$(date +%F).sql

# Anwendungsdaten inklusive RRD-Dateien sichern
sudo tar czf /var/backups/librenms/librenms-data-$(date +%F).tar.gz -C /opt/librenms librenms

Die Option --single-transaction ist wichtig: Sie erzeugt einen konsistenten Abzug, ohne die Tabellen zu sperren, sodass das Monitoring während der Sicherung weiterläuft. Prüfen Sie nach jeder Sicherung, ob die Datei plausibel groß ist und Tabellendefinitionen enthält.

# Sicherung grob prüfen
ls -lh /var/backups/librenms/
grep -c "CREATE TABLE" /var/backups/librenms/librenms-db-$(date +%F).sql

Die Wiederherstellung wurde ebenfalls getestet, und zwar als echter Durchlauf. Dazu wurde das angelegte Gerät bewusst gelöscht, sodass die Anwendung anschließend null Geräte meldete. Nach dem Einspielen des Abzugs meldete sie wieder ein Gerät mit dem ursprünglichen Hostnamen. Der Ablauf im Ernstfall sieht so aus:

cd /opt/librenms

# Anwendung und Poller anhalten, Datenbank läuft weiter
docker compose stop librenms dispatcher syslogng snmptrapd

# Datenbankabzug einspielen
docker compose exec -T db \
  mariadb -u librenms -p'IHR_DB_PASSWORT' librenms \
  < /var/backups/librenms/librenms-db-2026-09-18.sql

# Anwendungsdaten zurückspielen, vorhandenes Verzeichnis vorher sichern
sudo mv /opt/librenms/librenms /opt/librenms/librenms.alt
sudo tar xzf /var/backups/librenms/librenms-data-2026-09-18.tar.gz -C /opt/librenms
sudo chown -R 1000:1000 /opt/librenms/librenms

# Dienste wieder starten
docker compose start librenms dispatcher syslogng snmptrapd

# Anschliessend den Selbsttest laufen lassen
docker compose exec -u librenms librenms php /opt/librenms/validate.php

Ein wichtiger Punkt zur Datei /data/.env im Anwendungsverzeichnis: Sie enthält den Anwendungsschlüssel. Geht dieser Schlüssel verloren, sind verschlüsselt abgelegte Werte in der Datenbank nicht mehr lesbar. Diese Datei gehört deshalb zwingend in die Sicherung, was durch das Archivieren des gesamten Verzeichnisses automatisch geschieht.

Planen Sie die Sicherung als Cron-Auftrag und prüfen Sie mindestens einmal im Quartal, ob die Wiederherstellung auf einem Testsystem funktioniert. Eine Sicherung, die nie zurückgespielt wurde, ist nur eine Vermutung.

Updates und Rollback-Grenzen

Aktualisierungen laufen über das Image. Das Projekt beschreibt im README den folgenden Ablauf, bei dem LibreNMS die Datenbankstruktur beim Start selbständig anhebt. Dieser Ablauf wurde hier nicht selbst durchgespielt, da der Test mit einer frischen Installation begann.

cd /opt/librenms

# Vor jedem Update sichern, siehe Abschnitt zu Backup
docker compose exec -T db mariadb-dump -u librenms -p'IHR_DB_PASSWORT' --single-transaction librenms \
  > /var/backups/librenms/vor-update-$(date +%F).sql

# Stack anhalten, neue Images holen, wieder starten
docker compose down
docker compose pull
docker compose up -d

# Ergebnis prüfen
docker compose exec -u librenms librenms php /opt/librenms/validate.php

Nun zur unbequemen Wahrheit über Rückschritte. Ein Rollback ist bei LibreNMS nicht einfach das Zurücksetzen auf ein älteres Image. Beim Start hebt die Anwendung die Datenbankstruktur auf den Stand der neuen Version. Diese Anpassungen sind nicht darauf ausgelegt, rückwärts zu laufen. Startet man danach wieder ein älteres Image auf derselben Datenbank, passt das Schema nicht mehr zum Programmcode.

• Einziger verlässlicher Rückweg: altes Image starten und gleichzeitig den vor dem Update erstellten Datenbankabzug zurückspielen. Ohne diesen Abzug gibt es keinen sauberen Rückweg.
• Feste Version statt latest: In der compose.yml statt librenms/librenms:latest ein konkretes Versionsschild eintragen. Dann entscheiden Sie, wann aktualisiert wird, statt es dem nächsten Neustart zu überlassen.
• Änderungen vorher lesen: Die Veröffentlichungshinweise des jeweiligen Releases im Hauptrepository prüfen, bevor produktiv aktualisiert wird.
• Nicht mehrere Versionen überspringen: Größere Sprünge über viele Releases hinweg erhöhen das Risiko bei der Schemaanhebung spürbar.
• Zeitfenster einplanen: Während der Schemaanhebung ist die Oberfläche kurzzeitig nicht erreichbar, und der Poller erhebt in dieser Zeit keine Daten.

Typische Fehler mit Diagnose und Lösung

Die folgenden Punkte stammen teils aus dem Test, teils aus der Dokumentation. Die Herkunft ist jeweils angegeben.

Die Weboberfläche antwortet direkt nach dem Start gar nicht. Im Test lieferte ein Abruf unmittelbar nach dem Containerstart überhaupt keine Antwort, obwohl docker compose ps alle Container als laufend anzeigte. Ursache ist die Initialisierung: Der Container legt Konfiguration, Cron-Aufträge und Datenbankstruktur an, bevor nginx bereitsteht. Diagnose über docker compose logs -f librenms. Sobald dort ready to handle connections steht, antwortet die Oberfläche. Im Test dauerte das rund anderthalb Minuten. Nicht vorzeitig neu starten.

Der Selbsttest verweigert die Ausführung. Ein Aufruf von validate.php ohne Benutzerangabe brach im Test mit der Meldung Do not run validate.php as root ab. Lösung: den Befehl mit -u librenms ausführen. Dasselbe gilt für die meisten lnms-Aufrufe.

Anmeldung nicht möglich, alles leitet auf die Installation um. Im Test führten nach dem Anlegen des Administrators über die Kommandozeile weiterhin sämtliche Pfade, auch /login und Geräteseiten, mit HTTP 302 zurück auf den Installationspfad. Ursache war der noch nicht abgeschlossene Assistent, erkennbar am Eintrag INSTALL=user,finish in /opt/librenms/.env im Container. Ein Versuch, den Abschlussschritt per einfachem HTTP-Aufruf auszulösen, scheiterte im Test mit HTTP 419, weil der Sitzungsschutz greift. Lösung: den Assistenten im Browser durchklicken statt per Skript zu umgehen.

Gerät lässt sich nicht hinzufügen. Im Test lieferte der Versuch, eine nicht erreichbare Adresse aufzunehmen, die klare Meldung Could not ping 192.0.2.99 mit dem Hinweis auf die Option --force. Das ist eine Sicherheitsprüfung, kein Fehler. Prüfen Sie zuerst, ob das Gerät überhaupt erreichbar ist, und erzwingen Sie die Aufnahme nur, wenn Sie wissen, warum ein Ping nicht durchkommt.

Falsche SNMP-Zugangsdaten. Dieses Fehlerbild wurde im Test gezielt erzeugt. Mit korrekter Community lieferte snmpget die Systembeschreibung des Ziels. Mit falscher Community lautete die Antwort Timeout: No Response from librenms. Entscheidend ist: SNMP meldet bei falschen Zugangsdaten keinen Zugriffsfehler, sondern schweigt. Eine Zeitüberschreitung bedeutet also entweder falsche Community, blockierendes Paketfilter-Regelwerk oder deaktivierten SNMP-Agenten auf dem Ziel. Prüfen Sie in dieser Reihenfolge.

Keine Graphen, obwohl Geräte angelegt sind. Fast immer fehlt ein laufender Poller. Prüfung über docker compose logs --tail 20 dispatcher. Im funktionierenden Fall erschienen im Test regelmäßig Zeilen wie Completed alerting run for alerts in 4.06s. Bleiben sie aus, prüfen Sie, ob der Dienst überhaupt läuft und ob SIDECAR_DISPATCHER=1 gesetzt ist. Das Projekt warnt im README ausdrücklich, dass ohne mindestens einen Dispatcher kein Poller läuft.

Container startet nicht wegen Rechten am Datenverzeichnis. Laut Projektdokumentation muss das Volume dem Benutzer und der Gruppe aus PUID und PGID gehören, sonst startet der Container möglicherweise nicht. Dieser Fall trat im Test nicht auf, weil die Kennungen passten. Lösung laut Dokumentation: Eigentümer korrigieren und den Container neu starten.

Ports bereits belegt. Wenn auf dem Host bereits ein Dienst auf Port 8000, 514 oder 162 lauscht, scheitert der Start. Im Test wurden die Hostports der Vorlage bewusst auf hohe freie Werte gelegt. Für den produktiven Betrieb ist es sauberer, Port 8000 nur auf der Loopback-Adresse zu veröffentlichen und den Zugriff über den Reverse Proxy zu führen.

Saubere Deinstallation

Beim Entfernen gilt besondere Vorsicht. Der Befehl docker compose down -v entfernt Container und Netzwerke. Da die Vorlage Verzeichnisse statt benannter Volumes nutzt, bleiben die Daten in ./db und ./librenms zunächst liegen. Das eigentliche Risiko steckt im anschließenden Löschen dieser Verzeichnisse.

Achtung, dieser Schritt ist nicht umkehrbar. Mit dem Löschen des Datenbankverzeichnisses verlieren Sie sämtliche Geräte, Benutzer und Alarmregeln, mit dem Löschen des Anwendungsverzeichnisses zusätzlich alle RRD-Dateien und damit die komplette Messhistorie sowie den Anwendungsschlüssel. Ohne vorherige Sicherung ist nichts davon wiederherstellbar. Legen Sie vor dem Löschen eine Sicherung an und prüfen Sie, ob diese lesbar ist.

cd /opt/librenms

# Zuerst sichern, falls die Daten noch gebraucht werden könnten
docker compose exec -T db mariadb-dump -u librenms -p'IHR_DB_PASSWORT' --single-transaction librenms \
  > /var/backups/librenms/final-$(date +%F).sql
sudo tar czf /var/backups/librenms/final-data-$(date +%F).tar.gz -C /opt/librenms librenms

# Container, Netzwerke und anonyme Volumes entfernen
docker compose down -v

# Erst nach geprüfter Sicherung: Daten endgültig löschen
sudo rm -rf /opt/librenms/db /opt/librenms/librenms

# Ungenutzte Images aufräumen
docker image rm librenms/librenms:latest mariadb:10 redis:7.2-alpine crazymax/msmtpd:latest

Im Test wurde der Stack nach Abschluss aller Prüfungen mit docker compose down -v entfernt und das Testverzeichnis gelöscht.

Einordnung für den Betrieb im Unternehmen

LibreNMS ist kein Werkzeug, das man am Freitagnachmittag aufsetzt und danach vergisst. Der Einstieg über die offizielle Compose-Vorlage ist unkompliziert, im Test lief die Installation ohne inhaltliche Hürden durch. Der Aufwand steckt danach: SNMP muss auf jedem Gerät eingerichtet und abgesichert werden, Alarmregeln wollen durchdacht sein, und Alarme ohne Empfänger sind wertlos.

Für ein Unternehmen mit einer Handvoll Switches, einer Firewall, ein paar Access Points und einer USV ist der Nutzen dennoch schnell greifbar. Ein Portfehler, der über Wochen langsam ansteigt, ein Uplink, der auf halbe Geschwindigkeit fällt, oder ein Lüfterausfall in einem Switch fallen ohne Dauerbeobachtung erst auf, wenn etwas ausfällt. Genau diese schleichenden Entwicklungen macht LibreNMS sichtbar.

Zwei organisatorische Punkte sollten von Anfang an geklärt sein. Erstens: Wer schaut auf die Alarme, und über welchen Kanal erreichen sie diese Person auch außerhalb der Bürozeiten? Zweitens: Die Sicherung muss vor dem ersten produktiven Gerät stehen, nicht danach. Ein Monitoringsystem ohne geprüfte Wiederherstellung verliert im Ernstfall genau die Historie, die man zur Fehlersuche gebraucht hätte.

Passende Anleitungen auf S-EDV

• Zabbix-Server aufsetzen und Hosts überwachen: die agentenbasierte Alternative, wenn der Schwerpunkt auf Servern statt auf Netzwerkgeräten liegt.
• Uptime Kuma mit Docker und Nginx Proxy Manager installieren: schlanke Erreichbarkeitsprüfung für Dienste und Webseiten, gute Ergänzung zur Geräteebene von LibreNMS.
• Checkmk auf Synology für IT-Monitoring: Vergleichsmöglichkeit, wenn das Monitoring direkt auf einem vorhandenen NAS laufen soll.

Quellen

• librenms/docker auf GitHub: offizielles Image-Repository mit README, Umgebungsvariablen, Volumes, Ports und Aktualisierungsablauf, abgerufen am 18.09.2026.
• Offizielles Compose-Beispiel im Repository: Quelle der hier verwendeten Dateien compose.yml, .env, librenms.env und msmtpd.env, abgerufen am 18.09.2026.
• librenms/librenms auf GitHub: Hauptrepository, Projektstand und Releases, per API abgerufen am 18.09.2026.
• Offizielle LibreNMS-Dokumentation: Referenz zu Installation, Geräteverwaltung, SNMP-Trap-Verarbeitung und Fehlersuche.