TeamSpeak 3 Server und TSDNS monitoren und autom. neustarten

  • Hallo,
    ich möchte euch hiermit gerne das TS3Monitor Skript vorstellen.


    Zitat von Offizielle Beschreibung

    Monitor your TeamSpeak 3 / TSDNS server instances using TS3Monitor.


    It will check the status of your TeamSpeak 3 / TSDNS server instance and if it has crashed, it will try to restart it.


    The TS3Monitor provides you also an autostart feature of the configured instances after a reboot or crash of the entire Root server/VPS/virtual machine.


    Zu gut deutsch:

    Zitat von Ins Deutsche übersetzt

    Monitore deine TeamSpeak 3 / TSDNS Server Instanzen mit Hilfe von TS3Monitor.


    Es prüft den Status deiner TeamSpeak 3 / TSDNS Server Instanz und wenn diese ausgefallen ist, versucht es, diese neuzustarten.


    TS3Monitor bietet auch die Funktion für einen Autostart für die konfigurierten Instanzen nach einem Neustart oder Ausfall des kompletten Root Servers/VPS/vServers.


    Hier im Forum wurde uns bereits "Supervisor" vorgestellt: TS3Server mit MariaDB Datenbank (Ubunut 14.04) Tutorial (siehe "5. Autostart")


    Supervisor hat diverse Vor- und auch Nachteile. Warum ich persönlich diese Software allerdings überhaupt nicht mag, habe ich im obigen Thema als Antwort verfasst: TS3Server mit MariaDB Datenbank (Ubunut 14.04) Tutorial


    Was kann TS3Monitor?


    Folgende "Hauptfunktionen" hat das Skript:

    • Prüfung des Status einer TeamSpeak 3 Server Instanz
    • Prüfung des Status einer TSDNS Server Instanz

    Neben diesen Hauptfunktionen, gibt es noch folgende speziellen Funktionen:

    • Es schreibt eine Log-Datei, um nach einem Neustart des (Linux) Servers z.B. nachverfolgen zu können, was es so zuletzt getrieben hat (oder, falls der Server keine E-Mails versenden kann/darf)
    • Es sendet E-Mail Benachrichtigung zu Status Änderungen oder auf Wunsch auch "immer"
    • Es startet eine TeamSpeak 3 und auch TSDNS Server Instanz neu, wenn sie z.B. ausgefallen (gecrashet) oder heruntergefahren wurde (dann aber nur, wenn man es per Einstellung vom Skript erzwingt)
    • Nach einem Neustart des Linux Servers, kann TS3Monitor auch autom. dafür sorgen, dass alle konfigurierten Instanzen - egal ob TS3 oder TSDNS - wieder selbstständig gestartet werden (Ersatz für LSBInitScript)

    Voraussetzungen


    Um das Skript betreiben zu können, müssen folgende Bedingungen erfüllt sein:

    • Linux (sollte auf den meisten Distributionen funktionieren)
    • Eine oder mehrere installierte TeamSpeak 3 oder TSDNS Server Instanzen auf einem Root Server, einer VPS oder einem vServer
    • Diverse Software Pakete (siehe GitHub Seite für aktuellste Informationen)
    • "root" Benutzer Zugriff auf dem Linux System (siehe README.md auf der GitHub Seite für mehr Informationen)

    Weitere Informationen zum Produkt findest du unter GitHub - TS3Tools/TS3Monitor: Monitor your TeamSpeak 3 and TSDNS server instances.


    Für Fragen stehe ich gerne zur Verfügung. :)

  • Irgendwie funktioniert dieses Script nicht.
    Es fängt schon mit der Installation an, es steht dort ich soll den Cronjob so hinzufügen:

    Code
    1. ./TS3Monitor ts3server --path /home/teamspeak/ --install-cronjob


    Aber leider ist der Befehl "--path" nur mit Enterprise Lizenz verfügbar.

  • Hallo @niro93,
    das Skript funktioniert einwandfrei.


    Diverse Funktionalitäten sind durch die Lizenzen entsprechend eingeschränkt. Siehe auch hier: GitHub - TS3Tools/TS3Monitor: Monitor your TeamSpeak 3 and TSDNS server instances


    Aus diesem Grund erhälst du die von dir genannte Meldung. Führe das Skript daher bitte wie folgt aus:

    Code
    1. ./TS3Monitor ts3server --install-cronjob
  • Es gibt einen deutlich einfacherer Weg.



    Code
    1. nano /etc/systemd/system/ts3server.service
    Code
    1. [Unit]Description=TeamSpeak 3 ServerAfter=network.target[Service]WorkingDirectory=/etc/teamspeak3-server_linux_amd64/User=teamspeakGroup=teamspeakType=forkingExecStart=/etc/teamspeak3-server_linux_amd64/ts3server_startscript.sh startExecStop=/etc/teamspeak3-server_linux_amd64/ts3server_startscript.sh stopPIDFile=/etc/teamspeak3-server_linux_amd64/ts3server.pidRestartSec=10Restart=always[Install]WantedBy=multi-user.targetAlias=teamspeak.service


    Code
    1. systemctl daemon-reloadsystemctl start ts3server.service


    Vorteil: Systemd ist extrem zuverlässig. Wieso also ein extra script für eine Funktion die das System auch so kann.
    Zusatzvorteil:

    Code
    1. systemclt enable ts3server.service

    Nun startet der teamspeak server nach dem network.target automatisch.


    Außerdem bei einem Absturz weswegen auch immer startet der Dienst automatisch nach 10 Sekunden durch.

  • systemd ist mehr oder weniger genauso nett wie supervisord, aber beide dieser Lösungen haben halt mehrere "Probleme":

    • systemd ist nicht in allen Betriebssystemen verfügbar - vor allem in etwas älteren, die aber noch LTS besitzen
    • Du brauchst pro TeamSpeak 3 Server Instanz einen neuen systemd Service: ts3server01.service, ts3server02.service, ..., ts3serverN.service
    • Wie bildest du in systemd den TSDNS Server ab? Dazu gibt es keine PID-Datei...
    • Was macht systemd, wenn eine TS3 Instanz crasht? systemd kann im Fehlerfall den Dienst neustarten, aber versuche die möglichen Problemszenarios mal systemd zu erklären.

      Außerdem bei einem Absturz weswegen auch immer startet der Dienst automatisch nach 10 Sekunden durch.


      Soweit ich weis, kannst du nur eine PID-Datei angeben und wenn es diese nicht mehr gibt, wird der Service neugestartet. Es gibt aber auch den Fall, dass die PID-Datei vom TS3 Server noch existiert, die Instanz allerdings gecrasht ist (z.B. Linux Reboot ohne TS3 Shutdown oder eingefrorener Host und entsprechender Neustart).

    Das Hauptziel des Skripts war ein Monitoring von TS3 und TSDNS Instanzen mit Erkennung von allen möglichen Fehlern. Zusätzlich sollte es auch E-Mails versenden, um den Admin über Ausfälle zu informieren. systemd versendet z.B. keine E-Mails.


    Zusätzlich bekam es dann halt noch das Feature, dass es auch gleich versucht, die Services entsprechend korrekt wieder zu starten. Das war allerdings anfangs nicht vorgesehen.

  • Zitat von Sebbo

    systemd ist nicht in allen Betriebssystemen verfügbar - vor allem in etwas älteren, die aber noch LTS besitzen


    Prinzipiell ist das richtig systemd ist ein, im Vergleich recht neues Konzept. Allerdings ist selbst bei den sehr langsamen Distros systemd längst angekommen. Without Systemd Die Liste der Distros die systemd nicht unerstützen ist lang, ja aber die Nutzerstatistiken zu den Distros sind genauso einstellig wie nicht vorhanden, ausgenommen slackware.


    Zitat von Sebbo

    Du brauchst pro TeamSpeak 3 Server Instanz einen neuen systemd Service: ts3server01.service, ts3server02.service, ..., ts3serverN.service


    Das stimmt wiederum nicht. Systemd funktioniert nicht nur für eine einzelne Instanz sondern kann genauso für mehrer Instanzen eingesetzt werden. Ich hab mal einige Links zusammen gestellt die genauer erklären wie das funktioniert. Systemd ist relativ kompliziert kann aber auch super einfach sein. :)



    Zitat von Sebbo

    Wie bildest du in systemd den TSDNS Server ab? Dazu gibt es keine PID-Datei...


    Systemd verlangt gar keine PID um einen Process zu starten. Es ist ohne Probleme möglich auch TSDNS via systemd zu regeln und hier geht natürlich auch systemctl enable tsdns.service um den service automatisch beim boot zu starten.



    Zitat von Sebbo

    Was macht systemd, wenn eine TS3 Instanz crasht? systemd kann im Fehlerfall den Dienst neustarten, aber versuche die möglichen Problemszenarios mal systemd zu erklären.


    Systemd zumindest in er Konfiguration wie ich sie gepostet habe würde beim Status failed den Dienst herunterfahren, bzw den Status auf stopped setzen, die PID löschen und dann den Dienst mit der beschriebenen ExecStart neu starten.
    Das dabei keine Rücksicht auf missing files oä genommen wird. Klar das ist ein System Programm und kein SysAdmin.


    Zitat von Sebbo

    Es gibt aber auch den Fall, dass die PID-Datei vom TS3 Server noch existiert, die Instanz allerdings gecrasht ist (z.B. Linux Reboot ohne TS3 Shutdown oder eingefrorener Host und entsprechender Neustart).


    Selbst wenn der reboot angeordnet wird sogar per Hardware press wird das multi-user.target benachrichtig das ein shutdown ansteht und der service wird beendet und die PID gelöscht. Selbst wenn nicht, teamspeak löscht die pid automatisch, wenn eine Instanz startet und noch eine PID vorhanden ist.


    Zitat von Sebbo

    systemd versendet z.B. keine E-Mails.


    Es ist genauso möglich eine Notification zu bekommen, falls ein System Dienst den Status failed hat : Systemd status mail on unit failure | Northern Light Labs


    Zitat von Sebbo

    Zusätzlich bekam es dann halt noch das Feature, dass es auch gleich versucht, die Services entsprechend korrekt wieder zu starten. Das war allerdings anfangs nicht vorgesehen.


    Ich sage nur systemctl enable tsdns.service macht genau das.


    Systemd ist ein Programm das von RedHat entwickelt wird, einem System das für seine Stabilität bekannt ist. Die Funktionalität von supervisord ist halt ein Bruchteil von systemd und ist auch gar nicht dafür designed systemd zu Verdrängen oä.


    Ich muss allerdings den Punkt geben das systemd nicht auf alles System zur Verfügung steht vorallem bei Firmensystem die häufig ultra alte System laufen haben. Allerdings auch nur einen halben Punkt den init können so ziemlich alles Distros und init ist zwar nur systemd light aber könnte diese Funktionen auch übernehmen wenn auch nicht so schön wie systemd.

  • Mir ist das gerade noch was aufgefallen. Ich bin nicht sicher ob meine Antwort dahingehen 100% korrekt war.
    Also du sagtest was von mehreren Teamspeak Instanzen. Meinst du damit virtuelle Instanzen in einem Master Prozess oder wirklich mehrere Teamspeak Master Prozesse mit ihren virtuellen Servern?
    Den eigentlich lässt Teamspeak nur einen Masterprozess zu und man ist dann durch die virtuellen Server begrenzt.


    Also nach dem Schema
    TS MAIN PID 1

    • virtueller Server 1
    • virtueller Server 2
    • ...

    TS MAIN PID 2

    • virtueller Server 1
    • virtueller Server 2
    • ...

    Den wenn das wirklich nur virtuelle Server sind dann ist das kein Problem den in Systemd ist nur der Masterprozess relevant. Das der beim Start x Tochterprozesse spawnt ist nebensächlich.
    ich bin auch gerade dabei OnFailure Zeilen in meiner services einzufügen aber ich hänge mit meinem Zeitplan da etwas hinterher :D
    Ich kann aber hier gerne immer mal wieder posten falls ich Neuerungen vornehme die gut funktionieren.


    :) ja cool danke für die nette Begrüßung, Facebook ist nicht so meins Forum ist da schon besser :D

  • Ich meinte natürlich

    mehrere Teamspeak Master Prozesse mit ihren virtuellen Servern


    :)


    Gerne kannst du mir die Änderungen auch per PN inkl. Link hierzu schicken, weil dann kann ich deinen ersten Beitrag einfach aktualisieren. :)