Netdata ist ein Monitoring-Werkzeug, das sich auf hohe Auflösung und sofortige Sichtbarkeit konzentriert. Es sammelt auf einem Host hunderte Metriken im Sekundentakt und zeigt sie in Echtzeit in einer automatisch aufgebauten Oberfläche – ohne dass ein Dashboard entworfen werden muss.
Der andere Ansatz
Klassisches Monitoring arbeitet mit Abfrageintervallen von 15 bis 60 Sekunden und vorgefertigten Dashboards. Netdata dreht beides um:
- Hohe Auflösung: Standard ist eine Sekunde pro Messpunkt. Damit sind kurze Spitzen sichtbar, die bei einem Minutenintervall vollständig zwischen den Messpunkten verschwinden.
- Automatische Entdeckung: Der Agent erkennt laufende Dienste in Containern und auf dem Host selbst und legt passende Diagramme an. Ein neuer Container wird ohne Konfiguration sichtbar.
- Automatische Alarmierung: Auf Basis von Verlauf und Ähnlichkeitsvergleich lernt Netdata, welches Verhalten normal ist, und meldet Abweichungen – ergänzend zu festen Schwellwerten.
Aufbau
- Netdata Agent: läuft auf jedem überwachten System. Er sammelt lokal, speichert in einer eigenen Zeitreihendatenbank (dbengine) und liefert ein Web-Dashboard auf Port 19999.
- Netdata Cloud: der optionale zentrale Dienst, der mehrere Agents zu einer Gesamtansicht zusammenführt und Zugriff ohne direkte Netzverbindung bietet.
- Eltern-Kind: Agents können Daten an einen übergeordneten Netdata weiterreichen (streaming), sodass ein zentraler Knoten Langzeithistorie und Auswertung übernimmt. Das funktioniert auch vollständig ohne Cloud.
# Installation des Agents
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh
# Prüfen und bedienen
systemctl status netdata
curl -s http://localhost:19999/api/v1/info | head -20
# Weboberfläche: http://<host>:19999Wichtige Eigenschaften im Betrieb
- Eigene Datenbank: Die dbengine speichert im Bereich von 30 bis 60 Byte pro Messpunkt und unterstützt mehrstufige Auflösung – detaillierte Daten für kurze Zeiträume, verdichtete für lange.
- Export: Netdata kann Metriken an Prometheus, Graphite, OpenTSDB oder einen OTLP-Empfänger weiterleiten. Damit lässt sich die hohe lokale Auflösung mit Langzeitarchivierung kombinieren.
- Alarme: Regeln werden in eigenen Konfigurationsdateien definiert. Die mitgelieferten Regelsätze sind umfangreich und decken die häufigsten Fehlerbilder ab; eigene Regeln ergänzen den Rest.
- Ressourcenbedarf: Der Agent ist vergleichsweise genügsam, aber die Sekundenauflösung kostet Speicher. Auf kleinen Systemen ist eine Anpassung des Umfangs sinnvoll.
Sicherheit
Die Weboberfläche auf Port 19999 hat standardmäßig keine Authentifizierung und liefert detaillierte Einblicke – bis hin zu Container-Namen und Prozesslisten. Sie gehört deshalb niemals ungeschützt ins Internet. Richtige Wege sind: Bindung an localhost oder ein internes Netz, Zugriff über SSH-Tunnel, ein Reverse-Proxy mit Authentifizierung oder der Weg über Netdata Cloud.
Einordnung
Netdata ist hervorragend, wenn ein Problem gerade jetzt auftritt und schnell eine Diagnose gebraucht wird: Man öffnet die Oberfläche und sieht sofort, welcher Bereich ausschlägt. Als alleinige Plattform für einen großen Bestand mit Langzeitanforderungen, Rollen und Änderungsmanagement ist es weniger geeignet. In der Praxis wird es deshalb oft ergänzend zu einem zentralen System betrieben: Prometheus oder Zabbix für den Überblick und die Aufbewahrung, Netdata auf dem Server für die Detailansicht im Störungsfall.
Verwandte Grundlagen: Monitoring, Observability, Prometheus, Uptime Kuma.