© andov / 123RF.com

Netdata will das Monitoring, Alerting und Trending vereinfachen. Es setzt dazu auf leichte Inbetriebnahme und einen gehosteten Cloud-Dienst. Neben grundlegenden Systemparametern lassen sich über 300 Dienste überwachen.

Monitoring, Alerting und Trending (MAT) zählen nur selten zu den Herzensthemen von Admins, lassen sich im Alltag aber nicht umgehen. Gerade gestandene Admins kennen die Probleme: So passten zwar Nagios und dessen zahlreiche Forks und Ableger früher zur vorherrschenden IT-Landschaft, ließen sich aber später nur schwer auf containerisierte Microservice-Architekturen übertragen.

Beim Monitoring hat sich mittlerweile aber viel getan: Immer mehr Lösungen erkennen ihre Ziele automatisch und nehmen diese selbstständig in ihre Konfiguration auf. Anstelle des klassischen Event-Monitorings kommt immer häufiger Trending zum Einsatz, bei dem das Event-Monitoring quasi als Nebenprodukt abfällt. Wer jedoch schon einmal mit Prometheus gearbeitet hat und dafür eine Strategie für das langfristige Speichern von Metrikdaten erarbeiten musste, wird das eher nicht für vergnügungssteuerpflichtig halten.

Netdata (Abbildung 1) tritt nun mit dem Versprechen an, es besser zu machen. Auf Grundlage einer bemerkenswert einfachen Architektur will es Administratoren die Überwachung der eigenen Infrastruktur ohne viel Aufwand ermöglichen. Dafür installiert der Administrator einfach den Netdata-Agenten auf den Devices seiner Infrastruktur, verbindet ihn mit der Netdata-Cloud und hat im Handumdrehen ein vollständiges Monitoring mit bunter GUI, funktionaler Anzeige und ordentlicher Alarmierung.

Abbildung 1: Netdata bietet umfassendes Monitoring für Dienste On-Premises und in der Cloud. Es generiert aus den gesammelten Metrikdaten übersichtliche UI-Ansichten.

Wer Netdata für einen kommerziellen Anbieter hält, liegt nur zum Teil richtig: Die Software steht vollständig unter einer freien Lizenz. Allerdings fallen für die Nutzung des Netdata-Cloud-Diensts Kosten an. Die bewegen sich jedoch in einem Rahmen, der gestandene Admins nicht ins Schwitzen bringt. Sie fallen auch deutlich günstiger aus als eine oder mehrere Vollzeitstellen für Betrieb und Wartung einer eigenen Monitoring-Lösung. Wir haben uns genau angesehen, wie Netdata funktioniert und was genau die Lösung bietet.

Lizenzfragen

Die Netdata-Website [1] spart nicht gerade mit Superlativen. Da ist die Rede von unendlicher Skalierbarkeit, keinen versteckten Kosten und höchster Kosteneffizienz. Das Ganze erweckt den Eindruck, dass man es hier eigentlich mit einem Silicon-Valley-Startup zu tun hat, das eine proprietäre Monitoring-Lösung vermarktet. Zumindest im Hinblick auf den Standort liegt man nicht ganz falsch: Netdata Inc. ist in San Francisco beheimatet. Und wie nicht anders zu erwarten, steckt auch in Netdata Investorengeld großer Kapitalgeber.

Das mit der proprietären Software stimmt allerdings nicht ganz. Netdata tänzelt bei der Erklärung des Lizenzmodells zwar etwas herum, im Grunde ist die Sache aber relativ simpel. Der Netdata-Agent, der unmittelbar auf den Kundensystemen läuft und dort die Daten der zu überwachenden Dienste abgreift, steht unter der GPLv3. Es handelt sich also um vollständig offene Software. Darauf weist der Anbieter auch explizit hin, wohl vor allem, um Sicherheitsbedenken bereits im Vorfeld zu zerstreuen.

Anders sieht die Sache mit den beiden Komponenten Netdata Cloud und Netdata UI aus. Sie machen die Sache erst richtig interessant. Zwar lässt sich der Netdata-Agent theoretisch lokal ohne eine Anbindung an Netdata Cloud und Netdata UI betreiben, doch praktisch übernehmen die beiden Komponenten die gesamten Analysefunktionen sowie die Aufbereitung der gesammelten Daten für Dashboards und Trending-Graphen (Abbildung 2). Keine der beiden Komponenten steht jedoch unter einer offenen Lizenz, es handelt sich um proprietäre Software.

Abbildung 2: Netdata hat mehrere Endpunkte seiner Cloud weltweit verteilt, darunter auch einen in Frankfurt. Alternativ ist es möglich, das Produkt On-Premises zu betreiben.

Wer Netdata nicht in der Cloud nutzen will, hat immerhin die Möglichkeit, es auf der eigenen Infrastruktur (On-Premises) zu installieren, sodass Bedenken hinsichtlich der DSGVO an Bedeutung verlieren. Von einer durchgehend quelloffenen und freien Lösung zu sprechen, wäre bei Netdata allerdings zu hoch gegriffen.

Aus der Struktur des Lizenzmodells ergibt sich immerhin implizit eine Erklärung der Funktionsweise beziehungsweise eher der Architektur von Netdata. Kunden rollen den Agenten auf der eigenen Infrastruktur aus und geben die gewünschte Netdata-Cloud-Plattform als Ziel an. Dann geht die Datensammelei los. Fast unmittelbar im Anschluss sorgen Netdata Cloud und Netdata UI für bunte Bilder und übernehmen die Überwachung der zum Teil auch automatisch erkannten Dienste auf den Zielsystemen.

Was Netdata überwacht

Aus Sicht eines Unternehmens, das ein einfaches, gut funktionierendes Monitoring-System benötigt, kann die Lizenzfrage freilich von untergeordnetem Interesse sein. Dann stehen vermutlich eher praktische Aspekte im Vordergrund, etwa die Frage, welche Monitoring-Ziele Netdata auf welche Weise überwachen kann. Die Entwickler von Netdata werben mit über 300 unterstützten Monitoring-Zielen. Darin sind die grundlegenden Metrikdaten einzelner Systeme wie CPU- und RAM-Auslastung, I/O, Netzwerk-Performance und so weiter noch gar nicht enthalten.

Grundsätzlich funktioniert Netdata eher als eine Art Zeitreihendatenbank denn als klassisches Monitoring-System. Seine Funktionsweise ähnelt also mehr der von Prometheus als jener von Zabbix oder Icinga. Der Agent sammelt auf den Zielsystemen diverse Daten zu grundlegenden Systemmetriken sowie spezifischen Diensten wie MySQL. Daraus zieht Netdata dann Rückschlüsse auf die Situation der Dienste und schlägt gegebenenfalls Alarm. Es würde den Rahmen des Artikels sprengen, an dieser Stelle auf jeden unterstützten Zieldienst einzugehen. Zu den Highlights zählen die klassischen Linux-Standarddienste für Autorisierung und Authentifizierung, also OpenLDAP, SSH, FreeRADIUS, HashiCorp Vault und einige mehr.

Daneben deckt Netdata klassische Netzwerkinfrastrukturdienste ab, darunter BIND, PowerDNS, die meisten DHCP-Server sowie gängige Datenbanken wie PostgreSQL, MySQL und MariaDB. Auch NTP und Chrony als Zeitserver kann Netdata ohne weitere Konfiguration nahtlos überwachen. Für Systemd gibt es eine komplett eigene Abteilung: Dessen Metriken überwacht das Werkzeug praktisch nahtlos, inklusive diverser Randdetails wie der Menge der insgesamt gestarteten Dienste oder die Anzahl der Dienste, die Systemd als »Failed« markiert.

Wer Hardware mit Netdata umfassend überwachen möchte, kann das tun. Die Software kann die meisten gängigen Hardwaresensoren auslesen, um die Daten zu aggregieren. Das erweist sich an verschiedenen Stellen als sehr hilfreich. So liest Netdata etwa die Werte von Temperatursensoren in Servern aus. Stirbt ein Gehäuselüfter, bekommt Netdata das einerseits mit, weil es die Daten des Lüfters selbst mitschneidet, andererseits aber (vermutlich) auch, weil die Temperatur im Server zumindest leicht ansteigt. Daneben lassen sich Hardwaresensoren auch außerhalb klassischer IT-Infrastruktur ansteuern und auslesen. Wer etwa im Rahmen seines Smart-Home-Setups Thermometer im Haus verbaut, kann sie mit Netdata ebenfalls überwachen.

Besonders praktisch: Netdata muss sich in Servern gar nicht unbedingt auf den Linux-Kernel oder die dortigen Treiber verlassen, um die Werte der verschiedenen Sensoren herauszufinden. Es vermag diese Werte auch mittels HP iLO, IBM RSA, Dell DRAC oder generisch per IPMI oder Redfish auszulesen. In Sachen Internet of Things schöpft Netdata ebenfalls aus dem Vollen. So kann sich der Dienst mit praktisch allen gängigen Open-Source-Lösungen zur Heimautomation verbinden. Bei OpenHAB funktioniert das direkt. Daneben stehen Verbindungen zu Adaptern wie Homebridge zur Verfügung, die sich an andere Lösungen wie FHEM anbinden lassen.

Wer viel mit Smart Home zu tun hat, kennt den Zirkus der verschiedenen Standards dort ohnehin bereits und weiß die Vielseitigkeit von Netdata zu schätzen. Über die Sammeldienste hinaus beherrscht es die direkte Kommunikation mit diversen IoT-Werkzeugen etablierter Hersteller. Mittels API-Token gelingt eine Verbindung zu Philips Hue ebenso wie zu Geräten von Netatmo oder Elgato. Wer zu Hause eine PV-Anlage oder einen Batteriespeicher betreibt, hat ebenfalls durchaus Chancen, deren Metrikdaten mit Netdata unmittelbar abzugreifen. Das klappt beispielsweise bei SolarEdge-Hardware oder SMA-Konvertern. Letztere sind nach der Firma SMA Solar Technology AG benannt, einem weltweit führenden Hersteller von Wechselrichtern und anderen Komponenten für Photovoltaikanlagen. Neben den Sammelwerkzeugen für Linux gibt es Pendants für FreeBSD und MacOS.

Grundsätzlich fällt auf, dass die Netdata-Entwickler offenbar sorgsam abwägen, woher sie ihre Daten beziehen wollen. Für eBPF, die In-Kernel-VM von Linux, die quasi beliebige Eingriffe in den Netzwerkverkehr ermöglicht, haben sie nämlich ein eigenes Modul zum Import von Metrikdaten geschrieben. Mit passenden virtuellen eBPF-Instanzen lässt sich praktisch der gesamte Zustand eines Netzwerks umfassend auslesen und interpretieren – eine andere Monitoring-Lösung, die das umfassend demonstriert, ist Coroot [2]. Dabei treiben es die Netdata-Programmierer sogar weiter als jene von Coroot: Im Netdata Dashboard steht eine KI-Funktion zur Verfügung, die Anomalien im Netzwerkverkehr auf Grundlage der Daten aus EBGP erkennen soll (Abbildung 3).

Abbildung 3: Via eBPF versucht sich Netdata an einer KI-gestützten Anomalieerkennung des Netzwerkverkehrs. Damit wandelt es auf den Spuren von Diensten wie Coroot.

Kubernetes-Support

Im Jahr 2025 wäre eine Monitoring-Lösung ohne Support für Kubernetes eine eigenartige Sache. Da ist es beruhigend, dass die Netdata-Entwickler ihren Agenten mittlerweile auch in containerisierter Form (Abbildung 4) anbieten und ihn gleich mit der passenden Integration in Kubernetes versehen.

Abbildung 4: Netdata kann nicht nur die Metriken einzelner Prozesse erfassen, sondern auch die Daten laufender Container.

Wer seine Setups vorrangig im Rahmen von Containern und im Gespann mit Kubernetes betreibt, zieht daraus diverse Vorteile. So lässt sich der Netdata-Agent in Kubernetes als native Ressource auch direkt über die Kubernetes-API steuern. Dadurch ist es möglich, ihn als Bestandteil eines Verbunds zusammen mit anderen Anwendungen auszurollen. Darüber hinaus gelingt es Netdata auf diese Weise, die gesammelten Metrikdaten mit den Metadaten von Kubernetes zu korrelieren.

Es wäre per se wenig hilfreich, nur zu wissen, dass auf irgendeinem System eine von Kubernetes gestartete Instanz von MySQL läuft. Damit wäre noch nicht klar, zu welchem konkreten Workload in Kubernetes sie gehört. Netdata dockt aber auch an die K8s-API an und liest dort die Metadaten zu jedem überwachten Container aus. Daher kann es in der Benutzeroberfläche eine kohärente Ansicht anzeigen, die neben Infos zum eigentlichen Dienst auch den Kubernetes-Kontext enthält, in dem er läuft (Abbildung 5).

Abbildung 5: Netdata verbindet sich unmittelbar mit der Kubernetes-API und liest die dort verfügbaren Metrikdaten aus. Die Informationen zeigt es aufbereitet im GUI an.

Darauf beschränken sich die Entwickler aber nicht. Stattdessen haben sie in Netdata auch Unterstützung für Erweiterungen integriert, die oft im Kubernetes-Kontext zum Einsatz kommen. Beispielsweise gilt Cilium [3] als eine der umfassendsten SDN-Lösungen für K8s. Netdata kann sowohl den Cilium-Agenten als auch den Cilium-Operator in K8s und den Cilium-Proxy nahtlos überwachen. Darüber hinaus lässt sich der Kubernetes-Manager Rancher inspizieren.

Zwar gilt K8s heute vielerorts bereits als Cloud; geht man aber von klassischen IaaS-Plattformen oder den Hyperscalern aus, ist das doch noch einmal eine andere Geschichte. Hier bringt Netdata umfassende Integration sowohl in AWS, Azure und GCP mit als auch Unterstützung für mehrere Private-Cloud-Produkte. Wer etwa die Dienste von Akamai als CDN nutzt, dockt Netdata an die dortige API an und erhält in Netdata das Gros seiner Metrikdaten. Dasselbe gilt für praktisch alle Standarddienste in AWS, darunter EC2, ECS und S3. Auch mit den grundlegenden Azure-Ressourcen kommt Netdata zurecht. Wer Nextcloud betreibt, überwacht es mit Netdata ebenso lückenlos wie die private Cloud-Umgebung OpenStack.

Gesprächiges Werkzeug

Wer Netdata in seinem Setup zum Einsatz bringen möchte, steht vor der Frage, ob er wirklich alle Metrikdaten in die Obhut von Netdata geben will. Dessen Entwickler geizen auch hier nicht mit Superlativen: “Unendliche Aggregation” etwa soll ein verschachteltes System mehrerer Netdata-Agenten erreichen. Dabei schicken einzelne Instanzen auf den Zielsystemen ihre Daten zunächst an Mittleragenten, die dann mit Netdata Cloud kommunizieren. Weil jedes Element dieses Konstrukts auf jeder Ebene in beliebig vielen Inkarnationen existieren darf, lässt sich das Ganze zumindest theoretisch unendlich skalieren.

Allerdings macht man sich durch die proprietären Komponenten Netdata Dashboard und Netdata Cloud vom Hersteller abhängig. Wer diesem Vendor-Lock-in entgehen möchte, muss seine Metadaten zusätzlich zum Speichern in Netdata Cloud auch lokal bevorraten. Es ist den Netdata-Entwicklern hoch anzurechnen, dass sie in ihrem Agenten dafür umfassende Schnittstellen vorgesehen haben. Wer parallel zu Netdata etwa eine lokale Prometheus-Instanz betreibt, die parallel zu Netdata Cloud die Metrikdaten aus der Installation erhalten soll, konfiguriert im Netdata-Agenten den passenden Prometheus-Endpunkt und braucht sich nicht weiter zu kümmern. Dasselbe gilt für andere bekannte Zeitreihendatenbanken wie InfluxDB, Gnocchi, M3 oder OpenTSDB.

Auch VictoriaMetrics [4] und Thanos kommen als Zielplattform infrage. Dabei greift der Netdata-Agent auf die Prometheus-Schnittstelle zurück, die sowohl VictoriaMetrics als auch Thanos verstehen; dasselbe gilt für Cortex. Falls Prometheus die präferierte Zeitreihendatenbank ist, braucht man ohnehin früher oder später M3, Cortex oder Thanos [5]. Ansonsten pumpt man ein lokales Prometheus mit Metrikdaten voll und macht es damit erfahrungsgemäß über die Zeit immer langsamer. So oder so: Wer eine halbwegs aktuelle Zeitreihendatenbank nutzt, hat keine Schwierigkeiten, Netdata seine Daten dorthin exportieren zu lassen. Wer Netdata dann später nicht mehr nutzen möchte, hat immerhin die Daten noch zur Verfügung und verwurstet sie in Grafana oder einer anderen UI entsprechend weiter.

Performance-Fragen

Gerade wer in jüngerer Vergangenheit Erfahrung mit Prometheus gemacht hat, erlebte möglicherweise auch dessen zeitweilige Performance-Engpässe. Gerade große Instanzen des Diensts arbeiten oft unerträglich langsam – und das berücksichtigt noch gar nicht die Belastung der überwachten Systeme.

Auch Prometheus setzt beim Sammeln von Metrikdaten auf eine Server-Agent-Architektur. Hier gibt es für viele Zieldienste aber eigene Agenten, die sogenannten Exporter. Je nach Art und Umfang des Datensammelns genehmigen sich einige Prometheus-Exporter durchaus ordentliche Schlucke aus den RAM- und CPU-Flaschen. Trotzdem ist Prometheus heute beliebt und weitverbreitet.

Wohl auch deshalb haben die Netdata-Entwickler es als Ziel für einen direkten Vergleich mit ihrer Software auserkoren. Die von Netdata beigesteuerten Zahlen sprechen für sich: Der Netdata-Agent soll als einzelnes, auf Effizienz getrimmtes Werkzeug im Schnitt 40 Prozent weniger CPU-Last erzeugen und maximal etwas mehr als die Hälfte an RAM nutzen. Das gilt wohlgemerkt unter der Prämisse, dass im zitierten Vergleich Netdata fast drei Tage mehr an Metrikdaten hielt als Prometheus.

Obendrein liefert Netdata eine deutlich höhere zeitliche Auflösung: In der Standardeinstellung liest der Agent die konfigurierten Metrikdaten im Sekundentakt aus, während die meisten Admins ihr Prometheus eher nur alle 20 Sekunden abfragen lassen. Objektiv erreicht Netdata damit eine deutlich höhere Detailgenauigkeit seiner Metrikdaten. Allerdings profitiert nicht jedes Setup davon im großen Stil.

Log Aggregation

Längst hat sich im Kontext moderner Systemüberwachung das Mantra etabliert, dass nicht nur Metrikdaten Teil des zu überwachenden Datensatzes sind, sondern auch Protokollmeldungen. Logisch: Die enthalten ja konkrete Informationen zu auftretenden Fehlern. Die Krux daran: Logs sind bis heute nicht standardisiert und deshalb auch nicht maschinell lesbar.

Seit über zehn Jahren ist das Feld der Log Aggregation am Markt heftig umkämpft. Als Platzhirsch gilt Splunk [6]: Keine andere Lösung vermag Logmeldungen so umfassend auszulesen und zu indizieren wie das US-Produkt. Allerdings lässt sich der Hersteller diese Funktionalität teuer bezahlen. Zwar gibt es Alternativen wie den ELK-Stack (Elasticsearch, Logstash, Kibana) oder Grafana Loki, die jedoch noch keine sehr hohe Verbreitung genießen.

Netdata wählt einen anderen Ansatz: Still und leise hat der Hersteller sein Werkzeug in den letzten zwölf Monaten um diverse Funktionen für Log Aggregation erweitert. Die Meldungen werden Teil der Metrikdaten, die der Agent an Netdata Cloud schickt. Der Dienst wertet sie gleich aus und macht sie zum Bestandteil der regelmäßigen Überwachung. Wer das Log-Aggregation-Feature von Netdata nutzt, erhält mithin bei den Protokollen Zugriff auf dieselben Funktionen wie bei den eigentlichen Metrikdaten. So gelingt die Suche nach bestimmten Details ebenso wie eine Alarmierung auf Grundlage bestimmter Logeinträge.

Von zentraler Bedeutung ist dabei die Integration zwischen Netdata und Systemd. Netdata liest das ohnehin auf praktisch jedem aktuellen Linux-System geführte Systemd-Journal permanent aus und leitet die Details an Netdata Cloud weiter. Über einen File-Agenten lassen sich darüber hinaus die Inhalte beliebiger Textdateien einsammeln. Für verschiedene ohnehin überwachte Dienste sammelt Netdata die Protokolle zudem von sich aus ein, sofern der Administrator nichts anderes festlegt. Ist die Log-Aggregation-Funktion einmal aktiviert und überwacht Netdata ohnehin MariaDB, übermittelt der Agent auch die zugehörigen Logs. Das hält den Konfigurationsaufwand gering.

Umfassendes Alerting

Das schönste Monitoring taugt nichts, wenn auftretende Probleme keine Alarme auslösen. Netdata lässt hier nichts anbrennen. Zunächst enthält es für praktisch jeden Collector in seiner Sammlung – also für die Module, die Metrikdaten eines bestimmten Diensts aggregieren – auch eine vorgefertigte Alerting-Konfiguration. Die fußt auf Best Practices und Standards des Herstellers. Dem Administrator fällt dann die Aufgabe zu, das Alerting-Modul von Netdata Cloud so zu konfigurieren, dass er tatsächlich Alarme erhält.

Die früher gängigen SMS sind in immer mehr Unternehmen heute nicht mehr in Mode. Im Fokus stehen stattdessen Cloud-Dienste. Hier kann sich die Kontaktfreudigkeit von Netdata durchaus sehen lassen. Es kann die großen US-Dienste wie Opsgenie oder PagerDuty ebenso kontaktieren wie Discord, Mattermost, Rocket.Chat, Splunk und Telegram. Und wer doch eine SMS versenden möchte, greift zum Webhook und verbindet ihn mit der API des eigenen SMS-Anbieters. Wer das zentralisierte Cloud-Prinzip für Alerting nicht nutzen möchte, lässt Alarme unmittelbar vom Netdata-Agenten versenden. Dabei gibt es sogar noch mehr Kontaktmöglichkeiten als bei der Cloud-Variante, darunter das gute alte IRC, den Versand per E-Mail sowie das Absenden einer SMS.

Insgesamt lässt sich mit Netdata schnell ein umfassendes Alerting realisieren, zumal die Standardeinstellungen des Diensts ausgesprochen klug gewählt sind. Sie wägen in manchen Situationen ab, ob eine Alarmierung wirklich nottut – etwa dann, wenn in einem Webserver-Setup einer von Dutzenden Webservern ausfällt. Die Standardkonfiguration sieht dann vor, eine Alarmierung nicht mitten in der Nacht zu versenden. Diese Einstellung kann der Administrator freilich anpassen.

Fazit

Zwei Dinge fallen bei der Arbeit mit Netdata auf: Das Programm ist unglaublich schnell am Start und funktioniert ohne weitere Konfigurationsvorgaben ausgesprochen gut. Das Versprechen der Entwickler, man komme mit kaum einer anderen Lösung so flott zu brauchbaren Ergebnissen, hält die Software uneingeschränkt.

Weniger erfreulich ist, dass man Netdata als Cloud-Dienst mit proprietären Komponenten betreiben muss, auch wenn Netdata Cloud durchaus auf eigener Infrastruktur laufen kann. Die rund 10 000 US-Dollar, die ein solches On-Premises-Setup kostet [7], dürften für die meisten Unternehmen dabei noch das kleinste Problem sein.

Schwerer wiegt, dass jede Firma, die Netdata einsetzt, damit einen Vendor-Lock-in für einen Teil der eigenen Infrastruktur in Kauf nimmt. Wer damit kein Problem hat, sollte Netdata jedenfalls auf der Liste haben. Das gilt besonders dann, wenn es darum geht, das eigene, in die Jahre gekommene Monitoring-System zu ersetzen oder zumindest zu erweitern. (jcb/jlu)