Linux Server Monitoring mit Netdata

September 7, 2020 - Lesezeit: 7 Minuten

Über die Jahre habe ich die meisten meiner Linux Server per Hand und bei Bedarf überwacht. Viele der nützlichen Tools wie (h)top, netstat, vnstat oder auch das gerne von mir genutzte nmon sind nur wenige MB groß und oftmals direkt im Grundsystem der Distributionen oder zumindest immer in den offiziellen Paketquellen enthalten. Dazu werden viele Systeminformationen direkt vom Kernel im /proc Verzeichnis bereitgestellt und können dort abgerufen werden. Gleiches gilt für die Log Dateien in /var/log und die oftmals guten Dienstmeldungen per systemctl status oder auch im journalctl. Monitoring mit Boardmitteln hilft auch sich auf den eigenen Systemen besser auszukennen und mit kurzen Shell Scripten lassen sich auch Alarme, z.B. per Mail realisieren.

Im schlimmsten Fall ist ein "fancy" Monitoring Tool Teil des Problems, muss auch wieder regelmäßig Updates erhalten und frißt zudem nicht selten zusätzliche Ressourcen von 3-5%. Nicht die Welt, aber immerhin. Wer noch mit "richtiger" Hardware (und sei es nur ein Raspi) arbeitet kann über jedes Prozent weniger Last zufrieden sein, weil Skalierung ja oft nicht mal so eben geht und wer in der Cloud arbeitet weiß das jede zusätzliche Last oder nötige Skalierung bare Münze kosten kann.

Nun kann bei einer wachsenden Zahl von Servern aber auch jeder Admin irgendwann die Übersicht verlieren, nicht jeder Server lässt sich ständig oder bei Bedarf per Hand kontrollieren, vielleicht müssen auch Kollegen ohne Zugriffsrechte auf das CLI mal wichtige Infos abrufen können und effektiver in Bezug auf das eigene Zeitmanagement wäre es auch. Nun gibt es auf dem Markt seit Jahren etablierte, aber oftmals auch etwas angestaubte oder aufgeblähte Tools wie Nagios und Zabbix, viele kommerzielle Produkte und die momentan extrem beliebte Kombination aus Prometheus und Grafana. Letztendlich für mich aber alles ungeeigenet und viel zu aufwändig. Ok die Charts in Grafana sehen hübsch aus, aber der Konfigurationsaufwand und die Einarbeitung in Prometheus kosten mich unnötige Zeit. Vorgefertigte Dashboards von der Community helfen, erfordern aber bei Änderungen und Herstellerupdates in Prometheus auch wieder Änderungen in Grafana. Ein Traum ...

Netdata

Die einfache und vor allem gute Open Source Lösung ist für mich das auf python basierende netdata. Für mich mit folgenden Vorteilen:

  • ressourcenschonend, benötigt nie mehr als 1% CPU
  • einfache Installation und Konfiguration
  • Weboberfläche mit Dashboard, aber nur read-only, was vor allem Sicherheitstechnisch deutlich entspannter ist (Cockpit z.B. ermöglicht auch Systemkommandos per Webschnittstelle)
  • Die Daten von mehreren netdata Installationen/Servern lassen sich auf einem Server sammeln
  • Notifications über Alarme per Mail, Discord, Slack, Rocket.Chat, Teams usw.

https://github.com/netdata/netdata

Installation

Eine etwas ältere Version ist z.B. auch in den Paketquellen von Ubuntu enthalten. Empfehlen würde ich aber per curl den offiziellen Kickstarter herunterzuladen und zu verwenden. Dieser ist sehr gelungen und lässt einen die bei der Installation durchgeführten Schritte sehr schön mitverfolgen. Bash Shell wird benötigt, falls nicht eh im Einsatz.

cd /tmp
curl https://my-netdata.io/kickstart.sh -o kickstart.sh
chmod +x kickstart.sh
(sudo) ./kichstart.sh --stable-channel --disable-telemetry

Die Optionen für den Kickstart kann man auch weglassen, dann erhält man automatisch die nightly Builds und es werden anonyme Statistiken erhoben die den Entwicklern helfen Ihr Tool zu verbessern. Kann aber auch nachträglich noch angepasst werden.

Bildbeschreibung

Nach ein paar Minuten ist der Installer dann auch durch und im Prinzip ist man direkt startklar. Zum Abschluss gibt es noch die nötigsten Infos.

Bildbeschreibung

start | stop | status per systemctl

Die Weboberfläche erreicht man über

http://serverip:19999

Wenn das Netzwerk des Servers von außen erreichbar ist kann man das Dashboard zusätzlich absichern, dazu gibt es alle Infos hier:

https://learn.netdata.cloud/docs/agent/running-behind-nginx

Denkbar wäre auch eine Firewall Regel. Wer mit ufw arbeitet könnten z.B. folgende Regel ergänzen:

(sudo) ufw allow from EineIP to any port 19999

Konfiguration der Mail Benachrichtigung

Dafür muss der Server natürlich in der Lage sein Mails zu versenden, z.B. per Sendmail, Postfix etc. Funktioniert das bereits oder wird die interne Mailbox des root Users eh weitergeleitet, dann braucht man eigentlich gar nichts einstellen. Ansonsten die entsprechende Konfiguration aufrufen unter:

cd /etc/netdata/
sudo ./edit-config health_alarm_notify.conf

Dort nach dem Wert:

DEFAULT_RECIPIENT_EMAIL

schauen und eine Mailadresse einsetzen. Ich habe zusätzlich noch

EMAIL_CHARSET="UTF-8"

einkommentiert. Das war es dann auch schon. Man kann den Alarm auch testen:

sudo su -s /bin/bash netdata
/usr/libexec/netdata/plugins.d/alarm-notify.sh test

Mehr Infos und Optionen zu Notifications sind in der offiziellen Doku beschrieben:

https://learn.netdata.cloud/docs/agent/health/notifications

Ich habe z.B. noch für das von meinem Team verwendete Rocket.Chat einen WebHook angelegt und bekomme so mögliche Alerts per Mail und Chat. Dafür zuerst einen Webhook anlegen, wie das geht steht hier:

https://docs.rocket.chat/guides/administrator-guides/integrations

Dann die Netdata Config wie oben beschrieben aufrufen und diese Einstellungen anpassen:

SEND_ROCKETCHAT="YES"

ROCKETCHAT_WEBHOOK_URL="Webhook URL"

DEFAULT_RECIPIENT_ROCKETCHAT="@Username oder auch ein #Channel"

Mehrere Netdata Instanzen (Nodes) verwalten

Coming soon


GoAccess

April 21, 2020 - Lesezeit: ~1 Minute

Da ich auf den ganzen Wahnsinn der an der Nutzung eines Webanlytic Tools à la Google, Matomo usw. dranhängt keine Lust mehr habe bin ich einfach auf GoAccess umgestiegen. Ist eine super Sache und für meine Zwecke völlig ausreichend, die Webserverlogs hat man ja zudem doch meistens eh. Netter Nebeneffekt, hat man vorher selber gehostet spart man sich sogar die Datenbank und die doch recht massiven Anfragen.

"GoAccess is an open source real-time web log analyzer and interactive viewer that runs in a terminal in *nix systems or through your browser."

https://goaccess.io/


MSSQL Export unter Ubuntu Linux

Juni 19, 2019 - Lesezeit: 5 Minuten

1. Installation der MSSQL Tools

Man benötigt dazu die MSSQL-Tools, welche nicht Teil der offiziellen Ubuntu Repositories sind, aber von Microsoft bereitgestellt werden. Folglich muss APT eine neue Quelle hinzugefügt werden.

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | sudo tee /etc/apt/sources.list.d/msprod.list

Dieses Beispiel ist für einen Ubuntu Server 16, wer z.B. die 18.04 Version benutzt kann dies in der URL anpassen und 16.04 durch 18.04 ersetzten. MS supportert hier die aktuellen LTS Versionen.

Danach mit dem üblichen apt-get update die Quellen aktualisieren und die Tools sowie nötige ODBC Biblotheken installieren.

sudo apt-get update 
sudo apt-get install mssql-tools unixodbc-dev

Die nötigen Programme finden sich danach unter

/opt/mssql-tools/bin

Dieser Pfad ist üblicherweise nicht in den Umgebungsvariablen der Shell enthalten, man muss die Tools also direkt ansprechen. Wer es bequemer mag fügt einfach den Pfad zu seinen Shell Umgebungsvariablen hinzu. Dazu kann man die .profile im Homeverzeichnis verwenden oder auch die .bashrc, sofern man die Bash Shell benutzt.

echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
source ~/.bashrc

Der erste Befehl ergänzt die zwei Programme unter /opt/mssql-tools/bin in der PATH Varibale ohne die bereits bestehenden Einträge zu überschreiben. Der source Befehl führt die aktualisierte Umgebung direkt aus.

Checken ob alles geklappt hat kann man einfach indem man sql in die Shell tippt, gefolgt von der Tab Taste, es sollte dann direkt sqlcmd vervollständigt werden, bzw. zur Auswahl stehen. Nachfolgende kann man eine einfache Abfrage an den MSSQL Server schicken, z.B.

sqlcmd -S localhost -d <datenbankname> -U sa -P <passwort> -Q "SELECT user_id FROM users"

Localhost wird vermutlich in den meisten Fällen durch die IP Adresse des MSSQL Servers ersetzt. Nachdem -d Argument lässt sich der Name der Datenbank angeben, natürlich ohne die Tag Klammern. Nachdem -Q Argument kommt einfach das gewünschte SQL Query in Anführungszeichen.

Ein Nachteil lässt sich direkt erkennen. Im Gegensatz zu z.B. MySQL/Maria DB muss nachdem Argument -P das Passwort im Klartext folgen und kann nicht einfach vor der Ausführung der Abfrage eingegeben werden. Aus Sicherheitsgründen sollte man daher am besten die entsprechenden sqlcmd Befehle aus der Bash History wieder entfernen und/oder die History für die Dauer der sqlcmd Befehle deaktiveren. Eine weitere Alternative wäre einen Benutzer auf dem MSSQL Server einzurichten der nur entsprechende Leserechte auf die benötigten Tabellen hat.

Die Bash History findet sich unter ~/.bash_history und lässt sich mit einem Editor (vi /nano) bearbeiten. Deaktivieren kann man die History mit set +o history und wieder aktivieren mit set -o history. Vollständig leeren kann man die History übrigens auch mit history -c. Aber Achtung, bevor man die komplette History löscht, sollte man sich sicher sein das man darin keine Befehle hat, die man vielleicht noch wiederverwenden will und nicht auswendig kennt.

2. Export mit bcp

Neben sqlcmd wurde bcp (Bulk Copy Program) mit den MSSQL Tools installiert und damit lässt sich nun ein Export eines Datenbank Queries durchführen.

Folgender Befehl würde alle Inhalte der Tabelle Users aus der Datenbank Test_DB in die Datei user_export.txt exportieren.

bcp Users out user_export.txt -S localhost -U sa -P <passwort> -d Test_DB -c -t ','

Interessanter ist in meinen Augen aber nicht der Export einer ganzen Tabelle, sondern eines Querys. Dies geht wie folgt:

bcp "SELECT user_id, username FROM users" queryout users.txt -S localhost-U sa -P <-passwort> -d TEST_DB -c -t ','

Es werden zwei Felder aus der Tabelle users in die Datei users.txt exportiert und die Werte mit Komma getrennt.

Quellen:

https://docs.microsoft.com/de-de/sql/linux/sql-server-linux-setup-tools?view=sql-server-2017 https://docs.microsoft.com/de-de/sql/linux/sql-server-linux-migrate-bcp?view=sql-server-2017 https://docs.microsoft.com/de-de/sql/tools/bcp-utility?view=sql-server-2017


Linux Grundbefehle - Cheat Sheet

Oktober 3, 2018 - Lesezeit: ~1 Minute

Ein von mir erstelltes Cheat Sheet für ein Linux Grundlagen Seminar, findet sich unter folgendem Link:

https://www.cheatography.com/brice/cheat-sheets/linux-grundbefehle/


LVM

November 28, 2017 - Lesezeit: 3 Minuten

Hat man einen Linux Server mit LVM (Logical Volume Manager) und möchte z.B. eine weitere Partition oder eine neue Festplatte in den LVM aufnehmen, kann man dies wie folgt erledigen.
Achtung! Wie immer gilt, eine Sicherung kann nicht schaden, die Arbeit am Dateisysstem oder den Festplatten kann immer auch nach hinten losgehen. In meinem Szenario ging es vor allem darum eine neue Platte im LVM zu nutzen.

Um zu sehen was man überhaupt für Platten und Partitionen hat empfiehlt sich ein:

(sudo) fdisk -l

sowie ein Überblick über die bereits für den LVM verfügbaren Physical Volumes mit:

(sudo) pvs

und

(sudo) pvdisplay

Zuerst die gewünschte Platte oder Partition als PV (Physical Volume) initalisieren, in meinem Fall für /dev/sdb1 :

(sudo) pvcreate /dev/sdb1

Danach kann man mit pvs erneut nachsehen ob es auch geklappt hat. Jetzt hat man die Möglichkeit entweder eine vorhandene Volume Group (VG) zu erweitern (z.B. / oder /home) oder eine neue Volume Group anzulegen. Ähnlich wie oben gibt es auch hier wieder die Befehle vgs und vgdisplay.

Ich lege eine neue VG an mit (samba ist der Name der VG und kann beliebig sinnvoll benannt werden) und füge das gewünschte PV hinzu. Vorteil eine Volume Group kann aus mehreren Physischen Volumes bestehen und so in der Größe variieren:

(sudo) vgcreate samba /dev/sdb1

Jetzt muss in der VG ein Logical Volume erstellt werden, dies können wir dann später mit einem Dateisystem bestücken und damit arbeiten. Auch das LV kann später wieder erweitert werden und somit mehr Platz geschaffen werden.

(sudo) lvcreate -L 500G -n files samba

files ist der Name der LV und Samba der VG.

Dateisystem erstellen:

(sudo) mkfs.ext4 /dev/samba/files

Und mounten, dazu den LV Path benutzen (ggf. über lvdisplay rauszufinden)

(sudo) mount /dev/samba/files /samba

Vergrößern und erweitern kann man bei Bedarf. Dazu immer erst die VG erweitern mit vgextend, dann die LV erwietern mit lvextend, außer in der VG wäre noch Platz, dann reicht natürlich ein lvextend, z.B.

lvextend ‐L +10G files

Erweitert das LV um 10 GB. Lässt man das + weg kann man die gewünschte Gesamtgröße angeben oder auch +100%FREE für die maximale Größe verwenden.Jetzt sollte man auf jeden Fall mit resizefs -p /dev/name das Dateisystem auch erweitern um den neuen Platz nutzen zu können. Verkleinern geht auch, habe ich aber noch nie benutzt, dazu gibt es den Befehl lvreduce

Schön ist auch die Möglichkeit Snapshots zu erstellen, dazu ein ander Mal mehr.


Ubuntu 14.04 auf 16.04

September 26, 2017 - Lesezeit: 2 Minuten

Für September hatte ich mir vorgenommen einige Ubuntu Server von 14.04 LTS auf 16.04 LTS zu bringen. Die 14er LTS erhält zwar noch bis ca. April 2019 Updates, aber die 16er gibt es jetzt ja auch schon etwas über ein Jahr und bringt zudem offiziell PHP7 mit (ja ich weiß man kann es auch in der 14er installieren). Wie üblich empfiehlt sich ein Backup vom System und allen benötigten Daten auf dem Server zu haben. Neben den Backups habe ich das Glück das meine Ubuntu Server alle virtualisiert auf über ESX Server laufen und sich somit Snapshots anfertigen lassen.

Vor jedem Release upgrade sollte man das momentane System so aktuell wie möglich halten. Also vorher nochmal:

apt-get update
und
apt-get upgrade

durchführen. Außerdem empfiehlt sich auch ein

apt-get autoremove

um nicht mehr benötigte Pakete zu entfernen. Das lässt sich übrigens auch automatisieren.

Außerdem sollte man mit df -h auch mal schnell checken ob genügend Platz auf den Partitionen zur Verfügung steht. Auf einem Server war die /boot Partition so ziemlich voll und enthielt noch einige alte Kernel Versionen die ich dann vorher entfernt habe. Bevor man das macht sollte man sich aber mit uname -r vergewissern welcher Kernel aktuell verwendet wird und diesen natürlich auf keinen Fall entfernen.

Dann kann es mit

do-release upgrade

losgehen. Ubuntu leitet euch dann etwas durch den Vorgang und fragt bei neueren Configs nach ob diese eingebunden werden sollen oder lieber die alten verwendet werden sollen. Ich bleibe zu 99% bei den alten, sollten einige Dienste mit den alten Configs Probleme machen, lassen sich diese später noch verstehen und beheben, was ich deutlich besser finde als angepasste Configs zu verlieren.

Wenn das Upgrade durchgelaufen ist hatte ich meistens immer Probleme mit dem Netzwerk, was wohl auch an der Virtualisierung liegt. Auf jeden Fall wurde aus eth0 meistens irgendwas anderes. Mit ip link lässt sich aber schnell der neue Name der Netzwerkkarte rausfinden. Danach dann unter /etc/network/interfaces eth0 durch den neuen Namen ersetzen und das Netzwerk oder den Server neustarten. Danach sollte der Server wieder laufen und mann kann seine Dienste checken und z.B. PHP 7 installieren.