Netdata: Open Source Monitoring und Überwachung für Linux Server
Wer auf Basis von Open Source ein sehr leistungsfähiges und professionelles Monitoring inkl. Überwachung für seine Server sucht, sollte sich das Projekt Netdata mal genau anschauen. Das Programm verbraucht kaum Ressourcen und ist sehr detailliert. Den kompletten Sourcecode dazu findet man unter GitHub.
Netdata ist quasi konfigurationsfrei und lässt sich auf allen Linux Systemen sehr einfach installieren. Das Monitoring sieht dabei verdammt gut aus und wird fast in Echtzeit angezeigt. Anbei ein Screenshot von meinem Testrechner (der Bildschirm ist hier hochkant gedreht).
Um mehrere Server zu verwalten hat das Programm eine öffentliche oder lokale Registry
Will man netdata permanent beim Booten des Rechnern starten:
Generell funktioniert alles Out of the box. Will man trotzdem ein paar Sachen anpassen, findet man alle Konfigurationsdateien unter "/etc/netdata/".
Alternativ kann man über die "netdata" CLI die Daten abrufen (netdata -h).
Um z.B. eine E-Mail Benachrichtigung durch einen Alarm zu bekommen (über sendmail ), muss man die Datei "/etc/netdata/health_alarm_notify.conf" anpassen und seine E-Mail Adresse einpflegen.
Mit einem "|critical" direkt hinter der E-Mail Adresse bekommt man nur die kritischen Benachrichtigungen. Danach sollten man den Dienst unter Fedora mit "sudo systemctl restart netdata.service" neu starten.
Folgende Benachrichtigungen sind möglich:
Viel Spaß beim Testen
Demnächst werde ich mich noch mit der lokalen Registry von Netdata beschäftigen und einen weiteren Erfahrungsbericht dazu schreiben.
Erfahrungen von anderen User sind immer willkommen.
Gruß
Frank
Netdata ist quasi konfigurationsfrei und lässt sich auf allen Linux Systemen sehr einfach installieren. Das Monitoring sieht dabei verdammt gut aus und wird fast in Echtzeit angezeigt. Anbei ein Screenshot von meinem Testrechner (der Bildschirm ist hier hochkant gedreht).
Um mehrere Server zu verwalten hat das Programm eine öffentliche oder lokale Registry
Netdata Installation:
Siehe dazu: https://github.com/firehol/netdata/wiki/InstallationBeispiel EPEL 7 oder Fedora 27:
sudo dnf copr enable recteurlp/netdata
sudo dnf install netdata
systemctl start netdata
systemctl enable netdata
Generell funktioniert alles Out of the box. Will man trotzdem ein paar Sachen anpassen, findet man alle Konfigurationsdateien unter "/etc/netdata/".
Aufruf
Netdata wird direkt im Browser unter folgender Url aufgerufen:http://127.0.0.1:19999/
Benachrichtigungen
Es sind von Anfang an schon sehr viele Alarm-Einstellungen gesetzt, man kann sie zusätzlich mit eigenen ergänzen. Eine Übersicht findet man unter "Alarms" im Webinterface.Um z.B. eine E-Mail Benachrichtigung durch einen Alarm zu bekommen (über sendmail ), muss man die Datei "/etc/netdata/health_alarm_notify.conf" anpassen und seine E-Mail Adresse einpflegen.
EMAIL_SENDER="user@domain.tld"
# enable/disable sending emails
SEND_EMAIL="YES"
Mit einem "|critical" direkt hinter der E-Mail Adresse bekommt man nur die kritischen Benachrichtigungen. Danach sollten man den Dienst unter Fedora mit "sudo systemctl restart netdata.service" neu starten.
Folgende Benachrichtigungen sind möglich:
- Pushover user tokens
- Telegram chat ids
- Slack channels
- Flock rooms
- Discord channels
- Hipchat rooms
- SMS phone numbers
- pagerduty.com (pd) services
Viel Spaß beim Testen
Demnächst werde ich mich noch mit der lokalen Registry von Netdata beschäftigen und einen weiteren Erfahrungsbericht dazu schreiben.
Erfahrungen von anderen User sind immer willkommen.
Gruß
Frank
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 363089
Url: https://administrator.de/contentid/363089
Ausgedruckt am: 23.11.2024 um 08:11 Uhr
15 Kommentare
Neuester Kommentar
Hallo,
ja, klingt interessant. Mit Icinga2 haben die ja leider Gottes ein vielversprechendes Projekt in den Sand gesetzt.
Gruß,
Jörg
ja, klingt interessant. Mit Icinga2 haben die ja leider Gottes ein vielversprechendes Projekt in den Sand gesetzt.
Gruß,
Jörg
Hallo,
zum Einen ist die Dokumentation "strategisch" ausgesprochen schlecht aufgebaut. Es fehlt schlichtweg der rote Faden. Erschwerend kommt hinzu, dass die Dokumentation nur in Englisch erhältlich ist(*) und augenscheinlich von mehreren Personen verfasst wurde, die ein völlig unterschiedliches Verständnis von der optimalen Konfiguration haben.
Für jemanden mit meinem Schulenglisch (Realschule Abgangsklasse 1986) ist es schlichtweg unmöglich, sich über das "fucking Manual" einzuarbeiten.
Icinga2 ist etwas ganz Anderes als Icinga. Der Fokus liegt bei Icinga2 wesentlich intensiver auf einer Art Objektorientierung und der damit verbundenen Vererbung. Es gibt kaum Kompatibilitäten - weder in der Konfiguration, noch in der grundlegenden Strategie.
Gerade für die Strategie bräuchte es ein Tutorial, wie man so etwas grundlegend aufbaut ohne sich "festzufahren". In der offiziellen Dokumentation findet man "Codeschnipsel", weiß aber nie, auf welchen Ideen die letztendlich fußen. Wenn ich zwei Zeilen Code poste, können die entweder zu einem Linux-Kernel oder zu einer Office-Suite gehören - ohne den Kontext sind die wertlos.
Die Namensgebung ist extrem unglücklich: Wenn Du z.B. via Google nach "Icinga Problem 4711" suchst, findest Du irgend etwas über Icinga oder Icinga2 (die sich wie gesagt grundlegend unterscheiden). Von welcher Software letztendlich die Rede ist, findet man dann nur über ausprobieren hinaus.
Letztendlich wirkt das Ganze auf mich wie eines von diesen "wir müssen halt den Code veröffentlichen" Open-Source-Projekten, dass in erster Linie Produkt von einer handvoll Systemhäuser ist - die das Ganze dann natürlich lieber selber installieren und betreiben.
Aber es gibt ja, wie wir oben sehen, gute Alternativen
Gruß,
Jörg
(*) Das habe ich mit einigen (deutschsprachigen) Entwicklern diskutiert. Damals hieß es: "Die deutschsprachige Dokumentation fehlt nicht, es wird schlichtweg keine deutschsprachige Dokumentation geben weil das zuviel Pflegeaufwand ist. Punktaus."
zum Einen ist die Dokumentation "strategisch" ausgesprochen schlecht aufgebaut. Es fehlt schlichtweg der rote Faden. Erschwerend kommt hinzu, dass die Dokumentation nur in Englisch erhältlich ist(*) und augenscheinlich von mehreren Personen verfasst wurde, die ein völlig unterschiedliches Verständnis von der optimalen Konfiguration haben.
Für jemanden mit meinem Schulenglisch (Realschule Abgangsklasse 1986) ist es schlichtweg unmöglich, sich über das "fucking Manual" einzuarbeiten.
Icinga2 ist etwas ganz Anderes als Icinga. Der Fokus liegt bei Icinga2 wesentlich intensiver auf einer Art Objektorientierung und der damit verbundenen Vererbung. Es gibt kaum Kompatibilitäten - weder in der Konfiguration, noch in der grundlegenden Strategie.
Gerade für die Strategie bräuchte es ein Tutorial, wie man so etwas grundlegend aufbaut ohne sich "festzufahren". In der offiziellen Dokumentation findet man "Codeschnipsel", weiß aber nie, auf welchen Ideen die letztendlich fußen. Wenn ich zwei Zeilen Code poste, können die entweder zu einem Linux-Kernel oder zu einer Office-Suite gehören - ohne den Kontext sind die wertlos.
Die Namensgebung ist extrem unglücklich: Wenn Du z.B. via Google nach "Icinga Problem 4711" suchst, findest Du irgend etwas über Icinga oder Icinga2 (die sich wie gesagt grundlegend unterscheiden). Von welcher Software letztendlich die Rede ist, findet man dann nur über ausprobieren hinaus.
Letztendlich wirkt das Ganze auf mich wie eines von diesen "wir müssen halt den Code veröffentlichen" Open-Source-Projekten, dass in erster Linie Produkt von einer handvoll Systemhäuser ist - die das Ganze dann natürlich lieber selber installieren und betreiben.
Aber es gibt ja, wie wir oben sehen, gute Alternativen
Gruß,
Jörg
(*) Das habe ich mit einigen (deutschsprachigen) Entwicklern diskutiert. Damals hieß es: "Die deutschsprachige Dokumentation fehlt nicht, es wird schlichtweg keine deutschsprachige Dokumentation geben weil das zuviel Pflegeaufwand ist. Punktaus."
Hallo,
Japp.
Bei Nagios waren wohl einige Entwickler unzufrieden, was zu alternativen, parallel entwickelten Projekten (Shinken, Icinga, Icinga2, Naemon) führte. Icinga2 wird da wohl am Häufigsten erwähnt.
Des Weiteren ist Nagios wohl ziemlich agressiv bezüglich der Verwendung seiner Namens- und Markenrechte, womit man sich in OpenSource Communities auch nicht gerade Freude macht. Zumal sich diese Agression wohl in erster Linie gegen diejenigen richtet, die auf ihren Internetseiten die oben aufgeführten Alternativprojekte erwähnen. Gefühlt läuft es bei Nagios halt nach dem Motto: "Erwähnst Du deren Existenz, kommen wir mit der juristischen Keule so dass Du uns nicht mehr erwähnen darfst" -> Kindergarten.
Dramatisch ist das deshalb, weil die Nagios-Community über Jahre diverse Plugins entwickelt hat. Die laufen, sind aber auf einer Codebasis (C) entwickelt, die sich als nicht optimal herausstellt bzw. in der man sich festgefahren hat.
Von Naemon hört man gelegentlich etwas, Shinken zeigt da mehr Aktivität - allerdings liegt ein Teil der Aktivitäten darin, Katzenvideos usw. über Twitter zu verbreiten... Wenigstens weiß man so, dass da noch jemand lebt
Das größte Potential zeigt wohl Icinga2, allerdings ist das Ganze nicht gerade einsteigerfreundlich. Im Zweifelsfall pumpt man die initialen Datenbanken mit irgendwelchen SQL-Statements händisch in den Server und betet dann, dass es läuft. Die Installationsanleitung unter https://www.icinga.com/docs/icinga2/latest/doc/02-getting-started/ zeigt recht deutlich, auf welchem Level man da anfängt. Und, wie gesagt: Eine halbwegs verständliche deutschsprachige Dokumentation wird so gnadenlos "runterdiskutiert", dass es schon fast den Eindruck einer konsequenten Ablehnung vermittelt. Die Community empfand ich auch nicht als besonders hilfsbereit, denen ging es in erster Linie darum, mit großen Zahlen (Anzahl der gemonitorten Objekte) zu posen und über irgendwelche Details zu fachsimpeln, statt Einsteigern hilfreich zur Verfügung zu stehen. Spätestens nach der dritten Frage bist Du der Troll, der einfach nicht genug englisch kann - glaub' es mir
Schade, dass es momentan so gar nichts gibt, was zum Einen vollständig und verständlich ist und zum Anderen "so lebt", dass man sich auch vorstellen kann in 5 Jahren damit zu arbeiten.
Gruß,
Jörg
Japp.
Bei Nagios waren wohl einige Entwickler unzufrieden, was zu alternativen, parallel entwickelten Projekten (Shinken, Icinga, Icinga2, Naemon) führte. Icinga2 wird da wohl am Häufigsten erwähnt.
Des Weiteren ist Nagios wohl ziemlich agressiv bezüglich der Verwendung seiner Namens- und Markenrechte, womit man sich in OpenSource Communities auch nicht gerade Freude macht. Zumal sich diese Agression wohl in erster Linie gegen diejenigen richtet, die auf ihren Internetseiten die oben aufgeführten Alternativprojekte erwähnen. Gefühlt läuft es bei Nagios halt nach dem Motto: "Erwähnst Du deren Existenz, kommen wir mit der juristischen Keule so dass Du uns nicht mehr erwähnen darfst" -> Kindergarten.
Dramatisch ist das deshalb, weil die Nagios-Community über Jahre diverse Plugins entwickelt hat. Die laufen, sind aber auf einer Codebasis (C) entwickelt, die sich als nicht optimal herausstellt bzw. in der man sich festgefahren hat.
Von Naemon hört man gelegentlich etwas, Shinken zeigt da mehr Aktivität - allerdings liegt ein Teil der Aktivitäten darin, Katzenvideos usw. über Twitter zu verbreiten... Wenigstens weiß man so, dass da noch jemand lebt
Das größte Potential zeigt wohl Icinga2, allerdings ist das Ganze nicht gerade einsteigerfreundlich. Im Zweifelsfall pumpt man die initialen Datenbanken mit irgendwelchen SQL-Statements händisch in den Server und betet dann, dass es läuft. Die Installationsanleitung unter https://www.icinga.com/docs/icinga2/latest/doc/02-getting-started/ zeigt recht deutlich, auf welchem Level man da anfängt. Und, wie gesagt: Eine halbwegs verständliche deutschsprachige Dokumentation wird so gnadenlos "runterdiskutiert", dass es schon fast den Eindruck einer konsequenten Ablehnung vermittelt. Die Community empfand ich auch nicht als besonders hilfsbereit, denen ging es in erster Linie darum, mit großen Zahlen (Anzahl der gemonitorten Objekte) zu posen und über irgendwelche Details zu fachsimpeln, statt Einsteigern hilfreich zur Verfügung zu stehen. Spätestens nach der dritten Frage bist Du der Troll, der einfach nicht genug englisch kann - glaub' es mir
Schade, dass es momentan so gar nichts gibt, was zum Einen vollständig und verständlich ist und zum Anderen "so lebt", dass man sich auch vorstellen kann in 5 Jahren damit zu arbeiten.
Gruß,
Jörg
Hallo,
Bezüglich Nagios:
- In C programmiert
- Langsame Entwicklungszyklen
- Entwickler "verprellt"
Man muss halt wissen, was man will und - wie gesagt - meine Erfahrungen sind jetzt auch schon 12 Monate her - da wird sich bei einem so jungen Projekt sicher eine Menge getan haben. Zum Beispiel gibt es jetzt wohl auch einen Icinga2-Director.
Im Grunde genommen "müsste man halt mal ganz neu draufgucken".
Gruß,
Jörg
Also ist dann eigentlich eh Nagios, überhaupt mit Check_MK das "Beste" für nicht Datenbank/Linux Profis?
Bezüglich Nagios:
- In C programmiert
- Langsame Entwicklungszyklen
- Entwickler "verprellt"
Man muss halt wissen, was man will und - wie gesagt - meine Erfahrungen sind jetzt auch schon 12 Monate her - da wird sich bei einem so jungen Projekt sicher eine Menge getan haben. Zum Beispiel gibt es jetzt wohl auch einen Icinga2-Director.
Im Grunde genommen "müsste man halt mal ganz neu draufgucken".
Gruß,
Jörg
Hallo,
Das Teil kann aber nur Linux-Rechner überwachen, oder? Ich eruiere gerade, was sich so die letzten 18 Monate bei Icinga2 getan hat
Gruß,
Jörg
Das Teil kann aber nur Linux-Rechner überwachen, oder? Ich eruiere gerade, was sich so die letzten 18 Monate bei Icinga2 getan hat
Gruß,
Jörg
Hallo,
Schade
Aber man soll die Hoffnung ja nicht aufgeben
Gruß,
Jörg
Schade
Aber man soll die Hoffnung ja nicht aufgeben
Gruß,
Jörg
Wenn ich es richtig verstanden habe analysiert netdata den Rechner auf dem es läuft und ggf. weitere netdata nodes.
Die Überwachung von snmp oder netflow Daten habe ich nicht gesehen??? Damit wäre es IMHO nur eingeschränkt nutzbar als reines Server Monitoring und nicht fürs Netz selbst (Switche) samt "Zubehör" (Windows Server, sonstige Endgeräte).
Oder hab ich was nicht gesehen?
Die Überwachung von snmp oder netflow Daten habe ich nicht gesehen??? Damit wäre es IMHO nur eingeschränkt nutzbar als reines Server Monitoring und nicht fürs Netz selbst (Switche) samt "Zubehör" (Windows Server, sonstige Endgeräte).
Oder hab ich was nicht gesehen?
Hallo Freak-On-silikon,
check_mk ist nicht umsonst, sondern je nachdem welche und wieviele Module richtig teuer.
Wir hatten vorher Nagios sind dann auf check_mk gewechselt was ein fataler Fehler war.
@Frank
ich habe das mal heute unter Susesorglos via packetmanager installiert das geht nicht und bricht mit fatalem Fehler ab und bei mac os ist es auch noch nicht in den portstree vorhanden. Hier muss man dann direkt auf den Server kompilieren, das gleich gilt eh fuer alle Unixe.
Hab das dann ueber curl direkt von github gezogen und das geht jetzt.
Sieht sehr Uebersichtlich aus und laesst sich sehr leicht konfigurieren.
Aber hammer ist das die Installation ohne root rechte (sudo) hier funktionierte.
Das muss ich nochmals hinterfragen den das koennte ja dann auch ein Sicherheitsproblem da stellen.
Gruss
check_mk ist nicht umsonst, sondern je nachdem welche und wieviele Module richtig teuer.
Wir hatten vorher Nagios sind dann auf check_mk gewechselt was ein fataler Fehler war.
@Frank
ich habe das mal heute unter Susesorglos via packetmanager installiert das geht nicht und bricht mit fatalem Fehler ab und bei mac os ist es auch noch nicht in den portstree vorhanden. Hier muss man dann direkt auf den Server kompilieren, das gleich gilt eh fuer alle Unixe.
Hab das dann ueber curl direkt von github gezogen und das geht jetzt.
Sieht sehr Uebersichtlich aus und laesst sich sehr leicht konfigurieren.
Aber hammer ist das die Installation ohne root rechte (sudo) hier funktionierte.
Das muss ich nochmals hinterfragen den das koennte ja dann auch ein Sicherheitsproblem da stellen.
Gruss